A policy gate is a deterministic check that decides whether an agent's action executes, before it executes.
It evaluates identity, mission scope, tool permission, autonomy budget, suppression and human approval, then returns allow, deny, or requires-approval — and emits a signed receipt either way. Refusals are evidence too. A system that only records its successes has no record at all.
Get an Agent Trust Gap BriefGuardrails filter. Gates authorize.
The distinction decides whether you have a control or a suggestion.
| Guardrail | Policy gate | |
|---|---|---|
| Operates on | Text — prompts and outputs | Actions — the effect about to occur |
| Runs | Around the model | Between the decision and the effect |
| Decides | Whether content looks acceptable | Whether this actor may take this action, now, on this payload |
| Determinism | Often probabilistic | Must be deterministic — same inputs, same verdict, every time |
| Leaves behind | Usually a log line | A signed receipt, including for refusals |
Both are useful. Only one of them survives the question "prove this action was authorized."
What the gate evaluates, in order
- Identity — is this a known agent with a valid, unrevoked passport?
- Mission scope — does this action fall inside what the agent exists to do?
- Tool permission — is this specific tool granted, not merely un-forbidden?
- Autonomy budget — is the agent within its action, rate and spend ceilings?
- Suppression — is this target on a do-not-contact, cooldown or protected-relationship list?
- Human approval — if the action is consequential, is there a valid, unexpired, payload-bound approval?
- Circuit breaker — is this class of action currently halted?
- Idempotency — has this exact action already fired?
Deny by default. Anything not explicitly permitted is refused. The inverse — permitting whatever is not explicitly forbidden — cannot be secured for software that composes its own plans.
Fail closed. If a check cannot evaluate, the action is refused. A governance component that fails open is decorative.
The approval object
"A human approved it" is not a control unless you can say what they approved. An approval that outlives its payload is a rubber stamp with a longer shelf life.
Payload-bound
Bound to the hash of one exact payload. Change a recipient, an amount, a line of text — the approval no longer matches and the gate refuses.
Single-use
Consumed on first allow. Approving one action never silently approves the next one that looks similar.
Expiring
Valid for a window. An approval given on Monday should not authorize a send on Friday against a world that has moved.
Anti-pattern worth naming: rubber-stamp drift. If approval latency collapses and the edit rate goes to zero, the human is clicking rather than reviewing. Measure both, and treat the trend as a control failure rather than a productivity win.
Autonomy levels and the kill switch
Human-led — a person acts, the agent assists. Human-assisted — the agent proposes, a person approves each consequential action. Bounded-autonomous — the agent acts within a hard budget and every action still emits a receipt. There is no fourth level where the agent acts and nobody can reconstruct why.
Underneath all three sits revocation and a kill switch. The only meaningful specification for either is how fast it takes effect and whether it has been tested live — not whether the code exists. An untested kill switch is a claim, and claims are what this whole layer exists to replace.
Where this lands in the standards
| Framework | Mapping |
|---|---|
| OWASP Agentic 2026 | ASI01 Agent Goal Hijack · ASI09 Human–Agent Trust Exploitation · ASI10 Rogue Agents |
| NIST AI RMF | MANAGE 2.1 documented decision authority · MANAGE 2.2 mechanisms to supersede or deactivate · MANAGE 2.4 deactivation |
| ISO/IEC 42001 | A.8.2 system operation controls · A.9.3 human oversight |
| EU AI Act | Art. 9 risk management · Art. 14 human oversight, including 14(4)(e) the stop button |
ApexClaw's interpretation, published to be checked. Last verified 2026-08-06. Not legal advice. Full crosswalk →
Common questions
Where should policy be enforced?
At the effect boundary — the component that sends, pays or writes. Policy enforced in the agent's prompt is a request, not a control.
What is an autonomy budget?
A ceiling on how much an agent may do unattended within a window — action count, value, or both. It bounds the worst case without requiring approval on everything.
Should every action require approval?
No. Requiring approval everywhere destroys the automation and trains people to approve reflexively. Approval belongs on irreversible actions.
What happens when policy blocks an action?
The action is refused and a refusal receipt is produced. Silent blocking is nearly as bad as no blocking, because neither generates evidence.
How do you know policy is actually enforced?
Count refusals. A policy that has never blocked anything is untested, unenforced, or both.
A guardrail filters; a gate authorizes. If enforcement lives in the agent's instructions rather than the component holding the credential, it is not a control.
Sources
Enforcement failures are not abstract: the EU AI Act's three penalty tiers run up to 7%, 3% and 1% of global annual turnover depending on the obligation breached — the same figures cited on the cost-of-audit-failure breakdown. The gap this closes is real: machine identities already outnumber human ones by more than 80x in most enterprises, and Gartner projects more than 40% of agentic AI projects will be cancelled by the end of 2027. Standards this surface maps to:
- Deny-by-default gating and human-in-the-loop approval: OWASP Top 10 for Agentic Applications.
- Policy and risk-management controls: NIST AI RMF.
- Human-oversight and enforcement obligations: EU AI Act.