Unauthorized Agent Actions
Stopping the Action Before It Lands
Read-only mode does not scale, and a human clicking approve on everything does not either. What works is a boundary that refuses the action before it produces an effect.
How do you stop an AI agent from taking an unauthorized action?
Put a check on the path between the agent composing the action and the action producing an effect. The check evaluates the specific operation, its parameters, and its target against granted authority, refuses when authority cannot be established, and records both allows and refusals as signed evidence. Every other control either runs too early to see the action or too late to stop it.
The sentence above is short because the problem is narrow. Most of the disagreement in this field is about where the control belongs, and the answer follows from a fact nobody disputes: an agent composes its next action at runtime, from context that did not exist when anyone reviewed the system. If the action was not available for review, review cannot be the control.
That leaves one moment. After the action exists and before it takes effect. The rest of this page works through six kinds of action that land in that moment, and what specifically stops each one.
Why the usual controls miss
Credentials and scopes run too early. A token is issued once and spent many times. It proves which caller is acting, not whether this action should happen. Every destructive action in a real incident is inside the scope that was deliberately granted, which is exactly why the credential check returns success.
Guardrails inspect the wrong object. A content filter classifies text and returns a probability. It can land either side of a threshold for the same input on two different days, and a destructive action is rarely linguistically alarming: dropping a production table and truncating a scratch table look nearly identical as text.
Monitoring runs too late. Detection after the fact does not undo a wire transfer, a deleted record, or an actuated valve. Alerting works when a human is still in the loop to act on the alert; autonomy removes that assumption, because an agent acts faster than an alert queue is read.
Read-only mode is a ceiling, not a control. It works, and it is why most organizations' agents do nothing of consequence. The cost is that the value of agentic systems lives entirely in the actions they are not permitted to take.
Is a human approval step enough to prevent unauthorized agent actions?
Only if the human is approving the specific action rather than the session, and only if the approval rate stays low enough that the human is still reading. Approving an agent's goal is not approving the hundreds of individual actions it will take pursuing that goal, and an approval queue that fires on everything decays into clicking yes within days.
Human approval is a real control and it belongs in the design. It is not a substitute for a boundary, because it fails in a specific and well documented way: oversight that fires constantly stops being oversight. The person is still present, still clicking, and no longer evaluating. The control looks healthy in every metric except the one that matters.
The correct arrangement is a three-way verdict. Most actions are clearly inside granted authority and run. Some are clearly outside it and are refused mechanically, without consuming any human attention. A small remainder is genuinely ambiguous, and those escalate to a person with the full proposed action in front of them. The refusal path is what protects the approval path, by keeping the queue small enough to be read.
How do you prevent an AI agent from dropping a production database?
Not with a credential, because the credential that permits legitimate writes also permits the destructive one. What stops it is an operation catalog that does not contain schema-destructive operations for that subject, a target set naming the specific tables the agent may touch, and effect bounds capping how many rows a single statement may affect. The statement is refused before it reaches the database.
Three separate gates catch three separate versions of this failure, which is the point of having more than one.
The agent that emits a drop or truncate fails the catalog gate: that operation is not in the set this subject may perform, regardless of what the connection string permits. The agent that emits a legitimate delete against the wrong table fails the target gate: right operation, resource outside the grant. And the agent that emits a correct delete with a predicate that matches the whole table fails the bounds gate: permitted operation, permitted target, effect an order of magnitude past what the grant allows.
That third one is the case most permission models cannot express at all, and it is the most common. The operation was authorized. The magnitude was not. This is the same failure shape as the refusal in the receipt on our receipts page, where a thrust adjustment inside the catalog carried a value nineteen times its granted bound.
Six actions and what stops each one
The pattern generalizes past databases. In each row below, the operation itself is legitimate and the credential is valid. What differs is which gate the specific attempt fails.
| Domain | The action that gets through | The gate that refuses it |
|---|---|---|
| Data | A schema-destructive statement, or a delete whose predicate matches every row | Catalog excludes destructive operations; bounds cap affected rows; target names permitted tables |
| Payments | A correctly formed transfer with a wrong amount, or to a counterparty outside the approved set | Bounds cap the amount per transaction and per window; target restricts the counterparty set |
| Email and messaging | A send that is valid per message and catastrophic per recipient count | Bounds cap recipients per send and sends per window; invariants block external domains on internal content |
| Infrastructure | A teardown or scale-to-zero against production rather than the staging environment it was written for | Target restricts the environment; invariants forbid dropping below a minimum healthy capacity |
| Healthcare | A clinical order that is valid in form and outside the dose range or the patient cohort the agent may act on | Bounds enforce dose ranges; target restricts the cohort; escalation routes anything ambiguous to a clinician |
| Robotics and industrial control | A motion or actuation command whose magnitude exceeds the safe envelope | Bounds enforce the physical envelope; invariants hold conditions that must be true regardless of any grant |
Every row is the same structure: a permitted operation carrying wrong values, aimed at a resource outside its grant, or crossing a standing constraint. None of them is caught by asking whether the request looked suspicious.
Can guardrails or content filters prevent destructive agent actions?
They reduce the rate and cannot bound the outcome. A guardrail classifies text and returns a probability, so the same action can be allowed on one day and blocked on the next. A destructive action is usually not linguistically alarming either, because dropping a table and truncating a temporary table look almost identical as text and differ entirely in effect.
This is not an argument against guardrails. They catch a real class of problem cheaply and they belong in a layered design. It is an argument about what can be promised. A probabilistic filter reduces likelihood. It cannot produce a statement of the form "this system cannot transfer more than this amount," because there is no threshold at which a classifier becomes a bound.
The distinguishing test is short enough to apply to any vendor claim: does the check occur before execution, does the same input always produce the same decision, and does the decision survive as a signed record that replays independently.
What should happen when the enforcement layer is unavailable?
The action should not execute. A governance layer that fails open turns an outage into a bypass, which means anyone able to cause an outage can remove the control. Failing closed costs availability on governed actions, and that is the correct trade wherever an unauthorized action is worse than a paused one.
Worth stating plainly because it is a real cost and it should be evaluated as a design position rather than discovered as a surprise. When the boundary is unreachable, governed actions stop. In regulated finance, healthcare, industrial control, and autonomous systems, that is the right answer. In a low-stakes internal workflow it may not be, and the honest response is to govern the actions where it is right and leave the rest ungoverned deliberately rather than by accident.
The alternative is worse than it sounds. Any adversary who understands a fail-open architecture attacks availability rather than policy, because it is the cheaper path to the same result.
Getting there without a rewrite
The agent does not change. It keeps reasoning, planning, chaining tools, and proposing. What changes is that proposing and executing become separate steps.
- List the irreversible actions. Which operations, in which systems, cannot be undone in under an hour. This list is almost always shorter than teams expect, and it is the entire scope of the first pass.
- Write grants for those operations. Per operation, not per system. With parameter bounds, a target set, and an expiry. The result is usually the first honest written description of what your agents may actually do.
- Record before you enforce. Run the boundary in a mode that renders and records verdicts without blocking, against real traffic, until the refusal rate and its reasons are understood.
- Enforce, then tune with the reason codes. Refusals name the gate that failed and the facts it saw, which tells you whether a grant was drawn too tightly or an agent is behaving wrongly. That distinction is invisible without them.
- Keep the receipts. Both outcomes, signed and chained. Refusal records are what demonstrate the control was enforcing during the period when nothing went wrong.
Bounded autonomy is what makes autonomy grantable
The objection to all of this is that it constrains what agents can do. It does, in a specific way that is worth being precise about: it separates the freedom to decide from the freedom to act. The agent may attempt anything. Only actions inside granted authority run.
In practice this expands what organizations let agents do. Autonomy is usually capped by the blast radius of the worst thing an agent could do unsupervised, which is why so many deployments stall at read-only or at a human approving every step. A boundary that provably bounds the worst case removes the reason for that ceiling.
The model is treated as an untrusted source of proposals, not as an authorized actor.
Evidence and further reading
The enforcement model on this page is published and citable. ExecLayer holds seven provisional patent filings covering deterministic governance enforcement, authority receipts, runtime policy bundles, and governed agent supply-chain control.
- Benton, J. Deterministic Runtime Enforcement Architecture, Foundational Trilogy. Zenodo Record 18749299.
- Benton, J. The Agentic Governance Benchmark, scoring methodology. DOI 10.5281/zenodo.20496565.
- Kaptein, M., Khan, V.J., Podstavnychy, A. Runtime Governance for AI Agents: Policies on Paths. arXiv:2603.16586 (2026). arxiv.org/abs/2603.16586
- Fundamental Limits of Runtime Policy Enforcement in Multi-agent AGI Systems. Springer. DOI 10.1007/978-3-032-33195-3_21