Intelligence cannot mint permission
There is a category error at the base of enterprise agent deployment. Capability is being treated as authority. A system that can do something is being permitted to do it, and the permission is a credential rather than a decision.
Why does giving an agent an API key create ambient authority?
Because the key authorises the caller, not the decision. Everything the agent can reach, it can reach for any reason — a user's instruction, an injected one from a document it read, a hallucination, or an ordinary bug. Nothing between the model and the API distinguishes them.
- An API key is a bearer credential. Handed to an agent, it conveys everything the key can do, with no relationship to what anyone intended the agent to do.
- The Model Context Protocol standardises tool discovery and invocation, including human-in-the-loop prompts. It does not define a signature, a receipt, or a non-repudiable record of the human's decision.
- The separating principle is simple: the human signs the rendered effect, not the prompt and not the plan.
Part of Agent tool-call gating
The proposition, stated flatly
Intelligence cannot mint permission. A model's competence at a task is not evidence that anyone authorised the task, and no amount of reasoning quality substitutes for a decision by a principal.
That sounds obvious written down. It is violated by the default architecture of nearly every agent deployment in production, because the mechanism that conveys capability — a credential — is also the mechanism that conveys authority. They are the same object.
Ambient authority, and why it is the default
An agent needs to act, so it gets credentials. The credentials carry whatever permissions the account holds. From that moment the agent's authority is not what a human decided; it is the union of everything its credentials can reach.
| What the human intended | What the agent can do |
|---|---|
| Summarise this quarter's invoices | Everything the finance API key permits, including creating payment orders |
| Triage this ticket queue | Everything the service account permits, including closing incidents and modifying records |
| Draft a reply to this customer | Everything the mail credential permits, including sending to any recipient |
| Check whether the migration ran | Everything the database role permits, including DDL |
The right column is not a security failure. It is the credential working exactly as designed, and it is why every incident in this class reads the same way afterwards: the agent did something nobody wanted, using access nobody had deliberately granted for that purpose.
Three ways the gap gets exercised
- Indirect prompt injection. The agent reads content it was asked to process, and that content contains instructions. The agent follows them faithfully, because from its perspective they are part of the input.
- Reasoning failure. No adversary. The model concludes that a destructive action is the right next step — dropping a table to resolve a schema conflict, sending a communication to resolve an ambiguity.
- Scope drift. The agent chains tools legitimately and arrives, several hops from its starting point, at an action nobody considered when the credentials were issued.
Defences against the first are an active research area and they are probabilistic. The second and third have no detection story at all, because nothing anomalous occurs.
What MCP provides and what it does not
The Model Context Protocol has been valuable precisely because it standardised the thing that most needed standardising: how a client discovers what tools a server offers, how it invokes them, and how a server can request human input during an interaction.
It is worth being accurate about the boundary of that contribution.
| Capability | In the protocol? |
|---|---|
| Tool discovery and schema description | Yes |
| Tool invocation and result handling | Yes |
| Requesting human input mid-interaction | Yes |
| A signature over what the human approved | No |
| A receipt verifiable outside the client | No |
| Binding an approval to a specific tool call's arguments | No |
That is not a criticism. A wire protocol for tool calling is not obliged to solve non-repudiation, and protocols that try to solve everything tend to solve nothing. The point is that the last three rows are where enterprise deployments need an answer, and the answer has to come from somewhere.
Sign the effect, not the intent
This is the design rule that does the most work, and it is counterintuitive enough to state carefully.
An agent system contains three distinct things: the user's prompt, the model's plan, and the concrete action about to execute. It is tempting to have the human approve the first or the second, because that is where the conversation happens.
Both are wrong. The prompt is ambiguous — pay the outstanding invoices covers a range of outcomes. The plan is a model artefact that may not correspond to what executes. Only the third is a fact.
prompt "settle what we owe Acme" ← ambiguous, do not sign
plan "1. list invoices 2. pay each" ← model output, do not sign
effect "Transfer 48,200 GBP to Acme Ltd,
account 58473920, sort 20-00-00,
value date 2026-09-18" ← sign thisSigning the effect makes injection irrelevant. A poisoned webpage can cause the agent to construct any action it likes; it cannot cause a human to sign a rendered statement of that action.
Which effects warrant a signature
Not all of them, and a design that gates everything produces approval fatigue, which is its own failure mode with its own article. The test is consequence and reversibility.
- Irreversible: money movement, data deletion, external communication, production infrastructure change, contractual commitment.
- Expensive to reverse: record modification affecting downstream systems, permission changes, published content.
- Everything else: read operations, internal drafts, reversible state changes — no gate.
In a typical agent workload the first two categories are a small minority of tool calls and nearly all of the risk, which is what makes this affordable.
What this does not claim
It does not prevent prompt injection, detect it, or make models more reliable. Those are separate and important problems being worked on by people better placed to solve them.
It makes the outcome of those failures bounded. An injected agent can attempt anything and can complete only what a human signed for, which converts an unbounded failure mode into a bounded one.
What bounds the blast radius
| Measure | Soundness |
|---|---|
| Instruct the model not to | Heuristic — the constrained party enforces it |
| Classify inputs for injection | Probabilistic — an arms race |
| Narrow the credential | Sound — reduces what any cause can reach |
| Require a human signature on irreversible effects | Sound — no cause can produce it |
Objections and honest limits
“Better models will not hallucinate destructive calls.” Possibly, and injection and bugs remain. A control that depends on the model being reliable is a control that fails in exactly the cases it exists for.
“A signature per tool call is unworkable.” It would be. Gate the irreversible subset — payments, permission changes, bulk export, destructive operations — which in most deployments is a handful of tools.
Bounding agent authority
- Separate the reading identity from the acting credential. Different identities, narrowly scoped.
- Enumerate irreversible tools. Usually a handful.
- Render the effect from the tool arguments. Not from the model's description of its intent.
- Verify at the point of effect. Recompute the digest immediately before executing.
Terms used here
- Ambient authority
- Permission a component holds by virtue of its credentials, available to anything that can influence it.
- Indirect prompt injection
- Instructions embedded in content the agent reads rather than in the user's message.
- Effect rendering
- Producing the approval display from the arguments that will execute rather than from a model-written summary.
Frequently asked questions
Does this stop prompt injection? No. It makes injection unable to produce a consequential action, because the human signature over the rendered effect is not something the injected content can generate.
Is this a criticism of MCP? No. MCP standardises tool discovery and invocation and does that well. Non-repudiation is out of its scope, and the point is that enterprises need it from somewhere.
Why not have the human approve the plan? A plan is model output that may not match what executes. The effect is the only artefact that is a fact rather than a proposal.
Does gating slow agents down? Only on the small minority of tool calls that are irreversible or expensive to reverse. Read operations and reversible actions are untouched.
Can prompt engineering solve this? No. An instruction is enforced by the party being instructed, which is the definition of not being a control.
Why render from tool arguments? Because an injected instruction can also write a reassuring summary. The arguments are what executes.
Does every tool call need a signature? No. Gate the irreversible subset — payments, permission changes, bulk export, destructive operations.
Where this fits in Manav
Manav binds a named human to an agent's consequential actions through a signed delegation with scope and expiry, and a per-action receipt where the effect is irreversible.
Sources and further reading
- Model Context Protocol specification
- OWASP — Top 10 for LLM Applications
- Reported incidents involving autonomous agent actions against production systems.
- W3C Web Authentication Level 2
- RFC 8785 — JSON Canonicalization Scheme
- OWASP Top 10 for Large Language Model Applications