Guide · Security
Approval gates for AI agents: what actually counts as control
Why “always ask first” in a system prompt is not a control — and what a real approval gate looks like: default-deny policy, a proposal lifecycle, fail-closed unknown tools, and audit chains.
An approval gate is the mechanism that makes an autonomous agent safe to trust with real capability: a point in the infrastructure where an agent’s intended action is held, shown to a human with its exact arguments, and executed only on approval. The key word is infrastructure. A gate lives outside the model, where the model’s failures — and its attackers — cannot reach it.
Most “human in the loop” in the wild is not that. It is a system-prompt instruction to ask before acting, which holds right up until it matters. This guide explains why prompt-level control fails, then walks the anatomy of a real gate: default-deny policy, a proposal lifecycle, fail-closed handling of unknown tools, and a tamper-evident audit chain. monopea’s implementation is the worked example, but the pattern is the point — apply it to any agent you run.
Why is “always ask first” not a control?
Because it is enforced by the thing being controlled. A system-prompt rule is one more piece of text competing for the model’s attention, and it loses in predictable ways: a long session buries it, a model update reweights it, and — decisively — prompt injection argues against it with equal standing. Text in an email or a web page the agent reads is, to the model, instruction-shaped input just like yours.
Security people have a name for this failure: policy and mechanism in the same trust domain. The model is the component most exposed to attacker-controlled input, so it is exactly the wrong place to host the safety policy. The test for any oversight claim is simple and adversarial — if a sufficiently persuasive input could cause the action to ship without a human decision, there is no control, only a well-behaved default. A gate passes that test because the dispatch path physically requires an approval record; the model can want whatever the injection says, and the action still does not happen.
What does default-deny mean for an agent?
Default-deny means the starting policy for every mutation-capable tool call — anything that changes state outside the agent — is “blocked pending review,” and permissiveness is added explicitly rather than subtracted from. The alternative, default-allow with a blocklist of risky actions, protects only the actions someone anticipated; the incidents that actually hurt come from the ones nobody did.
Two corollaries complete the policy. Unknown tools fail closed: a tool the policy has never seen routes to review instead of executing, so a new integration or renamed capability cannot slip through an old rule set. And autonomy is granted, not assumed: where standing permission makes sense — the agent posts its weekly summary without asking — the grant is explicit, scoped per tool and per agent, and recorded, so the widening of the agent’s freedom is itself a reviewable decision. Read-only work — searching, retrieving, drafting, planning — flows freely; a gate that reviews everything reviews nothing, because approval fatigue is how humans get trained to click yes.
- Mutations are blocked as proposals by default; reads and drafts flow freely
- Unknown tools fail closed to review — new capability never inherits old permission
- Autonomy grants are explicit, scoped per tool, and recorded as decisions
How does a proposal lifecycle work?
A real gate gives every intended action a first-class lifecycle. The agent plans, reaches a mutation, and instead of executing, emits a proposal: the tool, the exact arguments, and the context that led there. The run enters a blocked state — in monopea it is literally called blocked_on_user — and waits. A human approves or rejects; only an approved proposal is dispatched, and the result flows back into the agent’s context so work continues.
The lifecycle framing matters because each transition is an auditable event with an actor and a timestamp: proposed by the agent, decided by a named human, dispatched by the runtime. It also makes oversight programmable — proposals can be listed, filtered, and decided over an API, which is what lets approval fit real operations (clear the queue from your phone, auto-expire stale proposals, route high-value ones differently) instead of interrupting a chat. And it preserves autonomy: the agent is not stopped, it is paused at exactly the consequential step, with everything else it can usefully do still available.
Why do approvals need an audit chain?
Because a gate you cannot verify afterwards is a gate you are taking on faith. Every proposal, approval, rejection, dispatch, and autonomy grant should land in an append-only log — and the log itself should be tamper-evident, so “the record says so” means something. monopea checkpoints its audit chain with Ed25519 signatures for exactly this reason: the history of what the agent asked and what humans allowed can be verified, not just displayed.
The audit chain is what turns an approval gate from a UX feature into a governance instrument. It answers the questions that follow any incident or review — what did the agent try, who allowed what, when, and did anything ship without a decision? It is also, not coincidentally, the shape regulators are converging on: the EU AI Act pairs human oversight (Article 14) with record-keeping (Article 12). One caveat for honest architecture: fail-closed applies to the tool-policy gate; other subsystems, like spend metering, may reasonably fail open to preserve availability — know which of your controls is which, and never let a marketing page blur them.
How Monopea implements the gate
The gate is monopea’s core mechanism. Mutation-capable tool calls are never dispatched inline: they become pending proposals with their exact arguments — secrets shown only as {{secret:NAME}} placeholders, never values — and the run blocks until you decide. Unknown tools fail closed to review; per-tool, per-agent autonomy grants are explicit and auditable; running agents can be stopped and steered from outside the loop.
The lifecycle is fully exposed: proposals can be listed and decided from the dashboard or over the REST /v1 API, and every transition is logged with Ed25519-signed audit checkpoints. Every tool arrives through the MCP catalog under the same default-deny onboarding, and every sub-agent a run delegates to inherits the same gate — so the control surface does not thin out as the agent’s reach grows.
What to take away
Put policy outside the model
The model is the component attackers can talk to, so it cannot host the safety policy. A gate on the dispatch path means injected instructions change what the agent wants — never what happens.
Default-deny, fail closed
Blocklists protect the actions someone anticipated. Default-deny with fail-closed unknown tools protects the rest — including the integration you add next year under rules you wrote today.
Make approvals a verifiable record
Proposals, decisions, dispatches, and grants belong in a tamper-evident chain. That record is what lets you demonstrate oversight after the fact — to yourself, a client, or a regulator.
FAQ
Approval gates, in short
- What is an approval gate for an AI agent?
- An infrastructure control that holds an agent’s mutation-capable tool calls as pending proposals — exact arguments visible — and dispatches them only on human approval. It sits outside the model, so prompt injection or model drift can change what the agent proposes but not what executes.
- Why isn’t a system-prompt instruction to ask first enough?
- Because the model enforces it, and the model is exposed to attacker-controlled text. Long contexts, model updates, and prompt injection all defeat instructions. A control has to hold even when the model misbehaves — which means the dispatch path, not the prompt, must require the approval.
- Doesn’t approving everything defeat the point of autonomy?
- You don’t approve everything. Reads, drafts, and planning flow freely; only mutations cross the gate, and recurring safe actions get explicit, scoped, recorded autonomy grants. The agent keeps working around the clock — it pauses at exactly the consequential steps.
- What happens when the agent calls a tool the policy doesn’t know?
- In a fail-closed design, it routes to review instead of executing. This is the property that keeps new integrations from inheriting old permissions — and it is worth testing on any platform: add a new tool and see whether its first mutation waits for you.
Keep exploring
EU AI Act Article 14
What the EU AI Act’s human-oversight requirement means for AI agents — oversight as an external control, not a prompt instruction — and how to architect for it.
Secrets management
Why an AI agent must never see your credentials, how prompt injection turns context into an exfiltration channel, and the write-only vault pattern that fixes the class.
What is MCP?
The Model Context Protocol — the open standard connecting tools and data to AI agents, and the layer where governance either happens or doesn’t.