AI agents can now mutate your production systems. Where's the authorisation boundary?

[rossbuckley1990-hash]

Pre-submission Checklist

• This post follows the MCP community guidelines

What would you like to share?

An agent refunds a customer $5. Fine.

The same agent, same credentials, same MCP connection, same tools, then:

drops a production table to "clean up old data"
force-pushes to main to "fix a typo"
deletes 10,000 user records because a support ticket said "remove this user"
sends a 50k-recipient email blast to "notify everyone of the update"
terminates the production cluster at 3am because the logs looked noisy
What stopped each one?

For most agent stacks shipping today: the model. Maybe a guardrail prompt. Maybe a per-tool rate limit. None of which is a security boundary, it's a suggestion. The credentials were already in the agent's context. The LLM was the last line of defence between a misread ticket and a deleted database.

The gap nobody has closed
MCP gave agents tool-calling. OAuth gave the agent a token. Both are necessary. Neither is sufficient.

MCP is transport auth, not action auth. It authenticates the agent to the tool. It does not authorise the specific action the agent is about to take.
OAuth scopes are coarse and minted at connection time. "Can write to the database" is a scope. "Can run exactly this query, on this table, affecting at most 1 row, once, in the next 60 seconds" is not, and it can't be, because the scope was decided when the agent connected, not when it acted.
The credential lives in the agent's context. Which means a prompt injection, a misconfigured grant, or a model that simply misjudges the situation is one step away from an irreversible mutation. There is no boundary between the agent and the destructive action, only the agent's judgement.
In human systems we would never accept this architecture. We don't hand the on-call engineer the production DB credentials and trust their good judgement at 3am. We have change windows, approval workflows, blast-radius limits, segregation of duties, break-glass procedures, and immutable audit logs. The engineer requests. The boundary decides. The credential never leaves the vault.

Agents deserve the same boundary. Right now, almost none of them have it, and the blast radius is growing every week as we wire agents into more consequential systems.

The pattern we landed on (and open-sourced)
After building this for our own use across payments, infrastructure, and data-mutation tools, the pattern that works is the same regardless of action class:

The agent never holds the secret. The credential lives in a broker. The agent can only ask the broker to act on its behalf.
Every action is bound to a proof. A signed, single-use artifact (we call it a PCCB, Proof of Constrained Capability Bound) that says: this exact action type, these exact parameters (amount / target / table / query hash / recipient list hash), this exact nonce, expires in 60s. Signed Ed25519 by an independent verifier. The proof is bound to the parameters, not just the capability, so a proof for "refund $5 to customer X" cannot be replayed as "refund $99,999 to customer Y".
The boundary checks the proof at the edge before the credential is released. Deterministic, fail-closed checks: signature valid, grant not revoked, not expired, scope allowed, parameters within the authorised bound, budget/rate not exceeded, not a replay. Any single failure > deny. No partial execution.
Every decision, allow OR deny, is written to a tamper-evident hash-chained ledger. Mutation attempts (authorised $20, attempted $99,999, or authorised DELETE FROM users WHERE id = X, attempted DELETE FROM users) are refused before execution and recorded with a structured failure code: ACTION_MISMATCH, SCOPE_DENIED, BUDGET_EXCEEDED, REVOKED, EXPIRED, DUPLICATE_REPLAY.
The agent asks. The protected boundary decides. The agent never sees the key. The same spine works whether the action is a $5 refund, a deploy, a DB migration, or a mass email, because the problem is the same shape every time: a non-deterministic actor requesting an irreversible action.

We built this as three repos, kernel (open verifier), permit (gateway + credential broker), cloud (managed control plane with human approvals and audit), and the mutation-refused scenario above is a real canned incident you can replay: https://github.com/Actenon

But the real question is broader
I'm not here to pitch our implementation. I'm here because I think this is a category gap the industry is about to hit hard, and I'd rather we have the conversation now than after the first public incident where an agent drops a production table or wipes a customer account.

So, genuinely:

Is anyone else treating agent authorization as a first-class problem, separate from MCP transport auth and separate from "prompt the model to be careful"?
What's your current pattern for destructive actions? Credential in the agent context? Per-tool OAuth with coarse scopes? A human-in-the-loop on every call (and does that scale)? Read-only tools only? Nothing yet, you're shipping and hoping?
Has anyone been burned by an agent taking an action it shouldn't have? I'd genuinely like to hear the post-mortems, what failed, what would have caught it, what the blast radius was. Near-misses count too.
Where should this layer live? In the agent runtime (LangChain / Claude Code / etc.)? In the tool gateway (MCP server)? In a separate service the gateway calls? My bias is "separate service, independent verifier", the boundary shouldn't be inside the thing it's bounding, but I want to hear objections.
What's the right primitive? We went with proof-bound execution (PCCB) where the proof binds the parameters, not just the capability. Is there a better one? Capability tokens? UCANs? Re-scoped OAuth with action-time consent? Just make every destructive tool call require a human approval and accept the latency?
What even counts as "destructive"? My current list: any state mutation that's expensive, irreversible, or affects more than one entity, payments, DB writes, deploys, infra changes, data deletion, mass communication. But the line is fuzzy. Where do you draw it?
My prediction: 2026 is the year an agent takes a destructive action it shouldn't have, publicly, and the industry suddenly cares. The agent stacks that survive will be the ones that treated the boundary as a first-class concern, not a prompt-engineering afterthought.

Curious where other people are landing.

Relevant Links

https://github.com/Actenon/actenon-permit
https://github.com/Actenon/actenon-kernel