The model can request an action. The authorization system decides.

There is a tempting architecture for AI agents: give the model a set of tools, a set of credentials and a system prompt that says be careful, then trust it to be careful. Every serious incident class we know of for agents — prompt injection, indirect prompt injection, tool poisoning, goal hijacking, confused-deputy delegation — exists because that architecture places the security boundary inside a component that reads untrusted text for a living.

Why the model cannot be the boundary

A language model’s job is to follow instructions found in its context. Its context includes documents, web pages, tool outputs, emails and messages from other agents. Anyone who can get text into that context can, with enough effort, get instructions into it. Defences inside the model — better prompts, classifiers, fine-tuning — raise the cost of an attack. They do not create a boundary, because the attacker and the defender are using the same channel.

A boundary has to be made of something the attacker’s text cannot reach: identity, policy and evidence evaluated outside the model.

An agent is not just another service account

Service accounts have fixed code paths. Agents assemble their behaviour at runtime from:

• the credentials they inherit (often a developer’s, often broad),
• the tools they can call (local, remote, MCP servers discovered at runtime),
• the data they read (which may contain instructions),
• the agents they can delegate to (which may have more authority than they do),
• the actions they take (which may be irreversible).

That is why a credential-centric or permission-centric view is incomplete. The unit of control for an agent is the action: this identity, on this resource, for this purpose, in this context, with this authority.

The authorization question

Every high-impact action should pass through the same evaluation, regardless of which model asked for it:

Action request
  → Principal      resolved from the credential presented, never from the request body
  → Credential     live, unexpired, not revoked
  → Tool           entitled to this agent by an operator
  → Effect         does the call read, or does it mutate
  → Resource       the impact an operator assigned it
  → Autonomy       supervised, or running unattended
  → Grant          an access grant standing behind this action, or none
  → Decision       ALLOW · CHALLENGE · DENY

Three details matter. First, CHALLENGE is a verdict, not an error. It is handed back to the caller, and the agent runtime is what stops; an access grant — requested, approved by someone other than the requester, and bounded to at most seven days — is what lets a later administrative attempt through. Second, the rule set is deny by default: an empty one denies rather than permits, and a rule returning allow is only declining to object, never widening access. Third, the decision carries evidence. When an engineer asks why their agent was stopped, the answer is the rule keys that fired, in a record a database trigger makes immutable.

One input is deliberately absent. The gate records the intent a caller declares, but no rule decides on it: a stated purpose is exactly what an attacker writes freely, so it is kept for the investigator reading the refusal rather than used to justify the action.

Threats this architecture addresses

• Prompt injection and indirect prompt injection — the injected instruction can make the model request anything; it cannot make the authorization layer allow it.
• Agent impersonation — the acting principal comes from the presented credential, so an agent claiming to be another agent is not expressible in the API.
• Tool poisoning and tool impersonation — tools have provenance, and a tool outside the agent’s declared entitlements, or one never discovered, is answered with DENY.
• Excessive autonomy and high-impact actions — a mutating call against a high-impact resource is challenged, so is an unattended one, and so is an administrative action with no grant behind it.

Two more are architecture rather than shipped behaviour, and we label them as such. Privilege escalation via delegation would need effective authority evaluated across a delegation chain; no agent-to-agent edge exists today, so nothing evaluates one. Credential replay and chaining would need credentials brokered per action; today a runtime credential is minted by a person, bounded to at most ninety days, revocable, and stored only as a digest.

What this does not mean

It does not mean the model’s own safeguards are useless; defence in depth is still defence. It does not mean every action needs a human; most actions are low impact and are allowed instantly with the decision recorded. And it does not mean the whole architecture is finished. The gate, its thirteen rules, its verdicts and its immutable decision records are implemented. What it decides over is partly declared rather than found: an operator entitles the agent’s tools and classifies the resource. No connector discovers an agent, and no screen registers one.