Skip to main content
Conditions determine whether a policy matches. A policy can use either a typed native condition tree or Rego, never both.

​
Condition shapes

A condition tree contains exactly one of the following shapes at each node. all and any accept 1–64 children. Trees support at most 16 levels and 512 total nodes. History-aware shapes apply to the current agent session for Content Policies and to the current authenticated connection for Resource Policies.

​
Operators

Operators are type-checked when the policy is saved. Forge does not coerce strings into numbers, booleans, or collections. contains, starts_with, and ends_with ignore case for text fields. matches uses a regular-expression string. eq, neq, in, and not_in remain exact comparisons. exists requires no value and matches only when the field is present and non-null. A missing field causes other comparisons to return false; it is not treated as an empty value. Regular expressions are limited to 1,024 bytes.

​
Regular expression matches

Use matches when a field needs a pattern instead of an exact string. Forge validates regular expressions with RE2-compatible syntax. Lookahead, lookbehind, and backreferences are not supported. In the Console, enter the pattern as the literal value:
In JSON policy definitions, escape backslashes:
Use the field that contains the value being matched:

​
Content fields

Content facts are supplied by the enforcing surface. A field is omitted when that surface cannot observe it. Registered custom Content fields extend tool.input with a field name, label, value type, and source provenance. Forge validates their descriptors and makes them available to the same native condition engine. The response checkpoint depends on the routed API surface and its response adapter.

​
Access fields

The complete enums for account, classification, route, and local-model posture are exposed by the policy schema used by the Console, API, and Terraform provider.

​
Resource fields

Resource Policies use authenticated identity scope plus the following native condition fields. The editor shows protocol fields only when every selected Resource can supply them. They use the same recursive field predicates, All, Any, Not, type-checked operators, size/depth limits, named-exception evaluation, and history-aware predicates as the shared policy engine. Only the available fields and history boundary differ. Resource connection history is retained in Gateway memory for at most ten minutes and 128 events per authenticated connection. History conditions do not aggregate across connections, devices, users, or the organization. | request.postgres.fingerprint | string | Normalized literal-free query pattern | HTTP bodies and PostgreSQL or MySQL row values are transformation targets, not Resource condition fields. A policy may match request or command metadata and transform the selected body or result, but native conditions and Rego cannot inspect the raw values. Redis keys, arguments, values, and replies are not condition fields. Query parameters, authorization values, cookies, raw SQL, comments, bind values, and credentials are also excluded. Database request-aware evaluation fails closed when Forge cannot completely identify the operation and referenced relations.

​
History-aware conditions

Windows use a positive duration such as 5m, 2h, or 7d and cannot exceed 30 days.
Count shapes accept exactly one of eq, gt, gte, lt, or lte, with an integer threshold from 0–1,024. hasEventSequence.ordered controls whether the specified events must appear in the same order. Content Policies evaluate the bounded prior events supplied for the current agent session. Resource Policies evaluate bounded, policy-safe HTTP request or PostgreSQL command facts from the same authenticated Resource connection, in connection order. For example, a Resource Policy can count repeated DELETE commands within one database connection:
These predicates do not query arbitrary historical data and do not currently implement a rate limit across connections, devices, users, or the organization. Backtests reconstruct Resource order from retained evaluations that share the same connection ID.

​
Exceptions

except uses the same native condition grammar as conditions. Forge evaluates it only after the primary condition matches. A matching exception suppresses the policy hit; it cannot independently create an allow decision or override another policy. To add an authored exception in the Console, open the policy, select Add exception, define the narrower condition, and add the reason used for audit. Set an expiration for temporary exceptions. Save the policy and wait until Saved — activating… is no longer shown before testing it. Verify both sides with fresh activity: one request that matches the primary condition and exception must bypass this policy, while a second request that matches only the primary condition must still receive the configured outcome. Confirm the exact policy revision and exception result in the Session, then check Audit log for the policy revision event. An exception does not need a separate allow policy.