Policy language

Policies and versions

• A policy has a key, a name, a description and a list of versions. Its rules are stored as data; you never deploy code to change a decision.
• A version is either draft, published or superseded. It records the author, a change note and a content hash. Drafts never affect live decisions.
• Publishing is four-eyes: the publisher must be a different person from the version's author. Publishing makes the version active and supersedes the previous one. To roll back, create a new draft with the earlier rules and publish it; history is never rewritten.
• Changes use optimistic concurrency: creating a version, publishing and changing status need If-Match: <policy version> (missing: 428, stale: 409).
• Every active policy contributes its published rules to one rule set; they are evaluated together. The baseline pack cannot be deactivated, and containment rules are managed through containment actions, not edited directly.

Rule documents

{
  "id": "FIN-001",
  "description": "Payments of £1,000 or more need approval",
  "effect": "require_approval",
  "priority": 100,
  "reason_code": "PAYMENT_ABOVE_THRESHOLD",
  "conditions": [
    {"field": "tool.privilege_class", "op": "eq",  "value": "financial"},
    {"field": "action.amount",        "op": "gte", "value": 1000}
  ],
  "obligations": {"approvals_required": 1},
  "enabled": true
}

A condition is {"field", "op", "value"}: field is a dotted path into the decision input (for example tool.privilege_class). For an or, write two rules with the same effect.

Operators

Decision input

The gateway builds the decision input from the authenticated agent, the registry, inspection and the request. It never takes these values from the agent's own claims. The rule builder lists these fields:

Decision precedence

Every rule from every active policy is evaluated. The decision is then the earliest of these that applies:

1. Platform invariants deny. These cannot be overridden by any rule: agent not active (AGENT_NOT_ACTIVE), gateway access disabled (GATEWAY_ACCESS_DISABLED), unknown tool (UNKNOWN_TOOL), blocked tool (TOOL_BLOCKED) and identity not active (IDENTITY_NOT_ACTIVE).
2. Any matching deny rule denies. Deny outranks approval and allow.
3. Any matching approval rule requires approval, unless the request carries a valid approval token for this exact request. The number of approvers is the highest approvals_required among the matching approval rules.
4. A matching allow rule, or a verified approval, allows. With a verified approval the reasons also include APPROVAL_VERIFIED.
5. Nothing matched: deny with NO_MATCHING_ALLOW. The platform is default-deny.

The decision reports its reason codes (from the deciding rules), the IDs of every matching rule and of the deciding rules, the obligations, and the engine used. All of it is recorded in the evidence chain. If the policy engine fails, the decision fails closed (PDP_UNAVAILABLE_FAIL_CLOSED).

Baseline pack

Every organisation starts with the CydraGateway baseline pack. It can be changed by publishing a new version (four-eyes) but not deactivated.

Examples

Dual approval for large payments in production

{
  "id": "FIN-002",
  "effect": "require_approval",
  "reason_code": "HIGH_VALUE_PAYMENT",
  "conditions": [
    {"field": "tool.privilege_class", "op": "eq",  "value": "financial"},
    {"field": "action.environment",   "op": "eq",  "value": "production"},
    {"field": "action.amount",        "op": "gte", "value": 25000}
  ],
  "obligations": {"approvals_required": 2}
}

No personal data to email tools

{
  "id": "DLP-001",
  "effect": "deny",
  "reason_code": "PERSONAL_DATA_TO_EMAIL",
  "conditions": [
    {"field": "tool.key",       "op": "prefix", "value": "email."},
    {"field": "inspection.pii", "op": "eq",     "value": true}
  ]
}

Freeze destructive actions for one high-risk agent

{
  "id": "OPS-001",
  "effect": "deny",
  "reason_code": "CHANGE_FREEZE",
  "conditions": [
    {"field": "agent.risk_band",      "op": "in", "value": ["high", "critical"]},
    {"field": "tool.privilege_class", "op": "eq", "value": "destructive"}
  ]
}

Testing

• Test this draft on a policy page runs a decision with the draft rules added to your active rule set (POST /api/v1/policies/simulate with draft_rules). Nothing is stored or executed.
• The Gateway console simulates or submits an action as one of your agents against the active rules, with the full decision, inspection results and timeline.
• Saving a version validates it: unique rule IDs, a known effect and operator, a reason code, at least one condition, and list values for in and not_in.

Golden decision cases

Decisions are made by one of two evaluators with identical semantics: Open Policy Agent (Rego) and an embedded evaluator. Both run against the same set of golden decision cases in every build, so they cannot drift apart. A selection:

See the architecture for where the decision sits in the ten-step workflow, and the quick start to write and test a rule of your own.

Applies to the CydraLabs proof-of-concept platform. Last updated 4 October 2026. Questions or corrections: contact us.