Policy JSON & Extension

Audience: IT admins who edit policies in JSON (e.g. file-based policies or advanced mode) or need to understand the Extension section.

---

Overview

Policies can be managed from the Keeper dashboard (typical) or, for advanced or airgapped scenarios, as JSON. Policy JSON includes core fields (id, name, type, status, controls, rules, filters) and an optional Extension object for extra options such as folders, allow-lists, or configuration push.

---

Basic Policy Structure (JSON)

A minimal policy in JSON looks like this:

{
  "PolicyId": "policy-123",
  "PolicyName": "Block PowerShell Execution",
  "PolicyType": "CommandLine",
  "Status": "enabled",
  "Controls": ["DENY"],
  "Rules": [
    {
      "Operator": "And",
      "Expressions": [
        {
          "Type": "Contains",
          "Value": "powershell.exe"
        }
      ]
    }
  ],
  "Filters": {
    "UserCheck": { "Users": ["*"] },
    "MachineCheck": { "Machines": ["*"] },
    "ApplicationCheck": { "Applications": ["powershell.exe"] }
  }
}

Core Fields:

Field	Required	Description
PolicyId	Yes	Unique ID for the policy.
PolicyName	Yes	Human-readable name.
PolicyType	Yes	One of: PrivilegeElevation, FileAccess, CommandLine, LeastPrivilege, HttpAccess; or for config push: SettingsUpdate, etc.
Status	Yes	enabled / enforce, disabled / off, monitor, monitor_and_notify (or product-equivalents).
Controls	Yes	Array of control types: ALLOW, DENY, MFA, JUSTIFY, APPROVAL, AUDIT, etc.
Rules	Yes (typically)	Logical rules (And/Or and expressions) that must match for the policy to apply.
Filters	Yes	UserCheck, MachineCheck, ApplicationCheck (and optionally time/date) to scope who and what the policy applies to.

---

The Extension Section

Extension is an optional object on the policy that holds extra configuration used by the policy engine or by configuration processors. Common uses:

Extension.Folders

Used with application or file-access policies to scope patterns to specific folders. The product can combine ApplicationCheck (e.g. *.exe) with Extension.Folders (e.g. ["{desktop}"]) to get full path patterns like {desktop}\*.exe. See Reference: Wildcards.

Example:

"Extension": {
  "Folders": ["{desktop}", "{downloads}"]
}

Extension.AllowCommands

Used in some deployments to define an allow list of commands (or command fragments) for privilege elevation or similar. If the product is configured to use an allow-list model, only commands in this list are allowed unless another policy explicitly allows them.

Example:

"Extension": {
  "AllowCommands": [
    "ForceTimeSync",
    "1"
  ]
}

(For “Sync now” time sync, the elevated command might be something like ForceTimeSync 1; including both the command name and argument ensures that flow is allowed.)

Use AllowCommands when your documentation or admin console indicates it’s supported; exact behavior depends on policy type and product version.

Extension for SettingsUpdate / Configuration Policies

Policies that push configuration (e.g. plugin settings, Redirect rules) use Extension to say what to update and how:

• PluginName — Which plugin to update (e.g. KeeperPolicy, RedirectEvaluator). The processor writes to that plugin’s JSON file under Plugins/.

• TargetFile — Optional; path (relative to app root) to the file to update instead of using PluginName.

• Action — e.g. Update or Add.

• SettingsJson — The full JSON to write (for plugin configs, the entire plugin JSON is often replaced, so include all required fields).

Example (conceptual) for RedirectEvaluator:

"Extension": {
  "PluginName": "RedirectEvaluator",
  "Action": "Update",
  "SettingsJson": "{ \"id\": \"RedirectEvaluator\", \"metadata\": { \"redirect\": { \"enabled\": true, \"rules\": [ ... ] } }, ... }"
}

For SettingsUpdate policies, the Extension structure is defined by the product’s configuration processor; follow the admin or deployment docs for the exact schema.

Extension.CustomFilterJobId

Some policies support a custom filter implemented by a job. Extension.CustomFilterJobId would identify that job; the policy engine calls it during evaluation (e.g. via an HTTP task) and uses the result to include or exclude the request. Check the policy type and product docs for support and format.

---

Where Policy JSON Comes From

• Dashboard: Policies are usually created/edited in the Keeper Admin Console and synced to agents. The backend may expose or export JSON for reference.

• File-based: For airgapped or testing, JSON files can be placed in the KeeperPolicy policies folder (e.g. under the plugin directory). File-based policies are loaded by the agent and often take precedence over cloud-synced policies for that agent.

• Preprocessing: After load, policies are preprocessed (e.g. resolving collections, path variables, and building combined application patterns from Extension.Folders). What you see in “current policies” or debug export may already be preprocessed.

---

currentPolicies.json

currentPolicies.json is a debug snapshot of the policies currently loaded and preprocessed by the KeeperPolicy plugin. It is created automatically and can be used to see exactly which policies are active and what filters (users, machines, applications, folders) each policy uses after resolution.

Where it is

The file is written to the KeeperPolicy plugin directory—the folder that contains the KeeperPolicy executable. The exact path depends on your install; it is often one of:

• {approot}\Plugins\KeeperPolicy\currentPolicies.json

• or, if the plugin runs from a subfolder (e.g. bin\Release\net8.0), that subfolder’s currentPolicies.json

• or, in some deployments, under a policies subfolder: ...\KeeperPolicy\policies\currentPolicies.json

Check your KeeperPolicy install location; the file appears alongside (or under) the plugin binary.

How it is created

KeeperPolicy creates or updates currentPolicies.json automatically in these situations:

• After preprocessing — When the policy registry is preprocessed (collections resolved to user/machine UIDs, application and folder patterns built from Filters and Extension.Folders).

• At startup — If the registry already has policies when the plugin starts, an initial export is written. If the registry is empty at startup, the file is written after the first preprocessing completes (e.g. after policies are received from the backend or loaded from the policies folder).

• After policy updates — When policies are updated from storage (e.g. synced from the dashboard) or from the policies folder (file-based policies), the updated snapshot is exported.

• After file watcher merges — When the plugin’s file watcher detects changes in the policies folder and merges new or changed policy files, the merged snapshot is exported.

You do not create or edit this file by hand; it is read-only output from the plugin for debugging and inspection.

What it contains

The file is a preprocessed policy registry snapshot. It typically includes:

• All policies currently in the registry (enabled, disabled, and monitor).

• Resolved filters — e.g. UserUids, MachineUids, GroupUids (collections expanded to concrete UIDs where applicable), ApplicationPatterns, FolderPatterns (paths and patterns used for matching, including combined application + folder patterns).

• Policy metadata — PolicyId, PolicyName, event type, policy state (enabled/disabled/monitor), controls (e.g. HasAllow, HasDeny, HasMfa).

So you see the effective filters the engine uses for matching, not the raw dashboard or file JSON.

How to use it to understand what policies apply to a set of filters

You can use currentPolicies.json to:

1. See which policies are active — Open the file and list all policies; note which are enabled vs monitor vs disabled.

2. See resolved scope — For each policy, inspect UserUids, MachineUids, and ApplicationPatterns (and FolderPatterns if present). That shows exactly which users, machines, and application/path patterns the policy targets after collection resolution and path/pattern building.

3. Reason about a specific request — For a given “user + machine + application (and path)”, compare:

   • the request’s user UID, machine UID, and application path

   • to each policy’s UserUids, MachineUids, ApplicationPatterns, FolderPatterns. Policies whose filters match that user, machine, and path are the ones that can apply to that request (rules and other checks still apply at evaluation time).

4. Debug “policy doesn’t match” — If a policy doesn’t apply when you expect it to, check in currentPolicies.json that the policy is present and enabled, and that its resolved filters (users, machines, application/folder patterns) actually include the user, machine, and path you’re testing. If a collection wasn’t resolved or a pattern is missing, that will be visible in the snapshot.

5. Back up or compare — Copy the file for backup or to compare snapshots between machines or before/after a policy change.

Note: The exact JSON structure (property names, nesting) may vary by product version. Use it as a debugging aid; for authoritative schema, refer to the product or admin documentation.

---

Editing Policy JSON Safely

• Validate JSON (syntax and, if available, schema) before deploying.

• Back up existing policy files before changing them.

• For SettingsUpdate or plugin JSON in Extension: SettingsJson often replaces the whole target file; include all required fields (id, name, executablePath, Subscription, metadata, etc.) or the plugin may fail to start.

• After changing file-based policies or pushed config, restart the KeeperPolicy plugin (or the service) if the product doc says so, so changes are picked up.

Return to Reference Index