Skip to content

Policy Variables

Policy Variables reuse expression fragments across rules and policies.

For example, define package_registries as:

{registry.npmjs.org,files.pythonhosted.org,proxy.golang.org}

Then reference it in a policy rule:

{
  "ip": {
    "connect": [
      "all|%package_registries%|443"
    ]
  }
}

Inspect expansion in Preview. Authored content and history retain custom references; distributed content expands them, leaving runtime placeholders for each job.

Variable Scopes

ScopeWhere to manage itAvailabilityWho can change it
SystemAdministration > Policy VariablesEvery Team Server policyAdministrators
PolicyA policy’s Variables tabOnly that policyPolicy owners and Administrators
RuntimeShown on a policy’s Variables tabSupplied separately for every jobRuntime Sensor only

Policy values override same-named system values case-insensitively. Original spelling is retained; prefer lowercase snake_case.

Runtime Variables

These names are reserved and cannot be defined as custom variables:

VariableRuntime value
%workspace%Job workspace directory
%home%Job user’s home directory, or <undefined> when the UID has no account entry
%hostname%Runtime Sensor host name
%uid%Numeric UID of the user that started the job
%user%Job user’s account name, or <undefined> when the UID has no account entry

The Runtime Sensor binds these values at job start. See the Specification for failure behavior when a variable cannot be resolved.

Create a System Variable

  1. Open Administration > Policy Variables.
  2. Select New Variable.
  3. Enter a name and expression value.
  4. Review the preview, including every affected policy and any validation errors.
  5. Save the variable.

Changes that invalidate any saved policy are rejected.

Create or Override a Policy Variable

  1. Open Policies and select a policy you own.
  2. Open the Variables tab.
  3. Select New Variable, or view the system variables and choose Override.
  4. Enter the policy-specific value and review the preview.
  5. Save the change.

New policies and their variables save atomically; invalid variables prevent creation.

Deleting an override restores any inherited system value. Changes leaving unresolved references are rejected.

Names and Values

FieldRequirement
Name1 to 128 ASCII letters, digits, or underscores; must start with a letter or underscore
Value1 to 8192 bytes and a valid policy-expression fragment

A value can represent part of a component, a complete component, brace alternatives, or multiple pipe-delimited components:

/usr/bin/{curl,wget}
{/opt/cache,/var/cache/app}
all|all

Values cannot reference other variables, including runtime variables.

The expanded shape must fit the operation: all|all supplies two components. Preview and validation check the expanded policy before saving.

Operational Guidance

  • Use system variables for centrally maintained service addresses, tool paths, and organization-wide allowlists.
  • Use policy variables for application-specific values or intentional overrides.
  • Keep security-sensitive values narrow. A variable can broaden many rules and policies at once.
  • Review every affected policy shown in the preview before changing a shared variable.
  • Treat variable values as current configuration, not versioned policy content. Reverting a policy restores its authored content and resolves its references using the current system and policy variables.
  • Do not store secrets in variables. Compiled policy content is distributed to Runtime Sensors.
Policy DefaultsSpecification