Agent policy gates: autonomy that proves it stayed in bounds

1. The problem: agents act, logs apologize

A customer-support agent refunds an order it should have escalated. A research agent exfiltrates an internal document into a public summary. A DevOps agent restarts the wrong cluster. In each case the postmortem finds the same gap: the agent had the credentials to act, nothing evaluated the action beforehand, and the log — if one exists — records what happened without proving whether it was allowed.

Teams usually reach for three tools, and all three operate after the fact or beside the point:

• Prompt instructions. “Never refund over $500” in a system prompt is a suggestion the model can misread, forget under context pressure, or be jailbroken out of. It is not a control.
• Model-level filters. Useful for content categories, useless for business rules. No filter knows your refund threshold, your data boundaries, or your approval matrix.
• Observability dashboards. Seeing the bad action in a trace is not preventing it. Detection without enforcement is incident response, not governance.

Regulators and internal risk functions increasingly expect the stronger property: every consequential agent action traceable to the policy that authorized it — or blocked for lack of one. That property cannot be bolted onto logs. It has to sit in the action path.

2. What good looks like on your infrastructure

1. Decision before action. The agent proposes; the gate disposes. No tool call, file write, or external request executes without an evaluation verdict.
2. Policy as signed artifacts. Rules ship as versioned, signed cartridges — built once, distributed to every governor, verified before enforcement. Policy drift and hand-edits are detectable by construction.
3. Three outcomes, one receipt format. Allow, deny, and escalate all emit hash-chained, signed receipts bound to the policy version. Denials are first-class evidence, not missing data.
4. No silent gaps. Unmatched actions hit a configured default — deny or escalate — and the receipt says which default applied.

The gate runs on your infrastructure, between your agents and their tools. No action metadata leaves your network for evaluation.

3. How gating works — evaluate, decide, receipt

Evaluate

The agent's proposed action — tool name, arguments hash, target resource, identity — arrives at the Agent Action Governor with the current signed policy cartridge. The governor matches the action against allow, deny, and escalate rules in version order. Evaluation is deterministic: the same action against the same policy version always yields the same verdict.

Decide

On allow, the action executes and the receipt records permit + policy version. On deny, execution is blocked and the receipt records the matched deny rule. On escalate, the action parks in an approval queue; a human decision — approve with note or reject with reason — becomes part of the same receipt chain. Policy Cartridge Distribution handles the lifecycle behind this: build once, sign, distribute, verify on receipt, revoke instantly when a rule changes.

Receipt

Every decision lands in the AI Decision Audit Trail as a signed, hash-chained entry bound to the policy version that produced it. Months later, a reviewer replays: action, policy version, verdict, evidence — without trusting the agent's own account. The trail is queryable across agents and sessions without centralizing raw logs.

4. The components

Three modules, one control plane. Start with the governor; add distribution and audit as the fleet grows.

5. How to verify it — policy versions, receipts, and denials

• Policy-version binding. Each receipt names the exact cartridge version evaluated. Re-run the action against that version and confirm the same verdict.
• Denial coverage. Ask for the deny log, not just the allow log. A gate with no recorded denials is either misconfigured or never tested adversarially.
• Revocation drill. Revoke a cartridge mid-session: in-flight actions finish under the old version, new actions evaluate against the replacement. The boundary must be visible in receipts.
• Default-behavior proof. Submit an action no rule covers and confirm the configured default fires — with a receipt naming the default.
• Offline replay. Receipts verify without the gate running — re-hash, check signatures, walk the chain on disconnected infrastructure.

6. Buying checklist

• ☐ Gate sits in the action path — unevaluated actions cannot execute
• ☐ Policy ships as signed, versioned cartridges verified before enforcement
• ☐ Allow, deny, and escalate share one receipt format, all hash-chained
• ☐ Unmatched actions hit a configured default — never an implicit allow
• ☐ Revocation is instant and version boundaries are receipt-visible
• ☐ Decisions feed a replayable audit trail queryable across agents
• ☐ Everything runs on your infrastructure — no action metadata to a vendor
• ☐ Studio experiment available without signup — isolated demo host, try before installing
• ☐ No certification claims — receipts are the evidence; your auditors decide

7. Common anti-patterns to avoid

• Prompt-only governance. Instructions to the model are not enforcement. If the control disappears when the model misbehaves, it was never a control.
• Allowlist nobody maintains. A gate with stale policy is a rubber stamp. Version, review, and revoke on a cadence — cartridges make this cheap.
• Escalation queues nobody staffs. Escalate without approvers is deny with extra steps and slower incidents. Staff the queue or narrow what escalates.
• Logs instead of receipts. Mutable logs record claims; signed, chained receipts record proof. Auditors know the difference.
• Vendor-side evaluation. Sending every proposed action to a third party for a verdict leaks your operations and adds a dependency in the critical path. Evaluate locally.

Frequently asked questions