Authority Is Not the Same Thing As Identity
A team builds an agent. They invest heavily in identity: workload identity, federated tokens, signed registration, attested binding. The agent’s identity is unimpeachable. They feel they have nailed the foundation.
The agent gets prompt-injected. It executes an action that violates the user’s intent. The post-mortem reveals: identity worked perfectly. The wrong action was taken by the right agent, with full attestation. The chain of custody is intact and shows the harm.
This is the lesson. Identity verifies who is acting. Authority verifies what they are entitled to do. They are different questions, and one cannot answer for the other.
The framework’s second foundational claim states this directly:
The agent acts under authority, not as authority.
It sounds like a fine distinction. It is not. It is the distinction that determines whether your agent system has a hard ceiling on what can go wrong, or whether the ceiling is the open sky.
The Misalignment
Conventional security thinking conflates the two. If we know who you are, we know what you’re allowed to do — because in conventional systems, authority is bound to identity in a relatively static way. Roles, groups, permissions — all attached to identity.
For agents, this collapses.
An agent’s identity is what we verify cryptographically: workload identity, model provenance, supply-chain attestation. Identity says: this is the agent we deployed, running the model we trained, on the platform we provisioned.
An agent’s authority is something different: the specific scope of action it has been entrusted with for this operation. Authority is bound to a mandate — the specific authorisation to act, signed by the entrusting party, scoped to a specific purpose, valid for a specific duration.
Identity is durable — it persists across operations, attaches to the agent itself.
Authority is transactional — it attaches to a specific action, derives from a specific mandate, expires when the mandate is fulfilled or revoked.
The conflation says: the agent is who it claims to be, therefore the agent can do what it asks to do. The disaggregation says: the agent is who it claims to be, AND the agent has a mandate authorising this specific action, AND the action is within the mandate’s scope. Both clauses must hold. Identity alone is insufficient.
What Goes Wrong When You Conflate Them
Three failure modes follow from treating identity as authority:
1. Prompt injection becomes catastrophic. An adversary inserts content that the agent reads. The content claims to authorise an action the entrusting party never authorised. If the agent treats its identity as sufficient to act, the prompt-injected instruction is treated as legitimate (since the agent is authentically itself). The action executes with full attestation. The witness records that the agent did what it was told to do — but not whether the telling was authorised.
2. Mandate scope creep is invisible. An agent deployed with mandate to “answer customer questions” starts being used for “answer customer questions and process refunds.” The identity hasn’t changed. The agent is the same agent. But the authority has expanded — and unless authority is checked separately from identity, the expansion is invisible. The agent operates outside its original mandate and the system doesn’t know.
3. Cross-context replay attacks succeed. An agent operating in one context, with authority for that context, has its credentials replayed in another context. Identity is the same in both contexts (the cryptographic material is the same). Authority should be different — the mandate was scoped to the first context — but if authority isn’t checked, the second context accepts the agent and its action. The replay succeeds because identity proved to be sufficient.
These failure modes share a structure: identity is preserved; authority is bypassed. The cryptographic chain of custody is intact. The action is wrong. The conflation is what makes this possible.
What Disaggregation Looks Like
Treating identity and authority as separate concerns means engineering them separately:
Identity infrastructure:
- Workload identity (e.g., SPIFFE) — bound to the runtime, not to the action
- Supply chain attestation — model provenance, framework provenance, runtime provenance
- Behavioural baseline — does the agent’s behaviour match the historical pattern of this identity
Authority infrastructure:
- Mandate format — signed, scoped, time-bounded authorisation for specific action
- Mandate validation — at every action, the authority is checked against the mandate
- Scope enforcement — actions outside the mandate’s scope are denied, regardless of identity
- Mandate lifecycle — issuance, validation, expiration, revocation as separate events
When an action is taken, both stacks fire:
- Identity check: is this the agent we deployed, signed by the keys we expect, with the supply chain we attested?
- Authority check: is there a valid mandate authorising this specific action, by this specific agent, in this specific context?
Both must pass. Identity passing without authority is a denied action. Authority asserted without identity is a denied action. Either alone is insufficient.
The Mandate as a First-Class Object
This means the mandate is not a configuration detail. It is a first-class object in the architecture, with its own lifecycle, its own attestation, its own verification machinery.
A mandate is:
- Issued by an entrusting party (a user, a system, an upstream agent acting under its own authority)
- Signed by the issuer with a verifiable key
- Scoped to a specific class of action
- Time-bounded with explicit expiration
- Revocable by the issuer at any point
- Verified at every action against the mandate’s scope and validity
The agent does not have authority intrinsically. The agent carries a mandate that conveys authority. Without the mandate, the agent has identity but no authority — it can prove who it is, but cannot prove it is authorised to act.
This is the architectural shape of acts under authority, not as authority. The agent acts because it has been given a mandate. The agent does not act because of who it is.
Where Conventional Identity Stops
Conventional identity systems were built for a world where authority and identity were bound at the role level: if you are a manager, you can approve refunds. This worked because users were stable, roles were stable, and the action surface was relatively closed.
For agents, none of these hold. Agents are deployed for short-duration mandates. Authority is granted per-operation. The action surface is open. Roles don’t capture the granularity needed.
This is why conventional identity infrastructure is necessary but not sufficient. You still need workload identity, supply chain attestation, runtime verification — all of that is foundation. But you need authority infrastructure on top of it: mandates as first-class objects, validated per-action, scoped to specific operations, with their own lifecycle.
A team that ships strong identity without authority infrastructure has a foundation but no superstructure. A team that ships strong authority without identity has superstructure with no foundation. The architecture needs both, separately engineered, both verified at every action.
The Disposition
The agent acts under authority, not as authority.
The claim is simple. The architectural commitment is large. It says that no agent, however well-identified, has intrinsic permission to act. Permission is granted by an entrusting party, in a signed mandate, scoped to a specific purpose, with explicit expiration. The agent carries the mandate. When the mandate expires, the authority expires with it. The identity remains; the authority does not.
A team that internalises this builds systems where authority is a continuous engineering surface — not a deployment-time configuration. Mandates are issued, validated, monitored, expired, revoked, re-issued. The authority machinery runs alongside the identity machinery. Both are checked, always.
A team that doesn’t internalise this builds systems where authority is implicit in identity, where deployment-time scope is treated as runtime authority, where the absence of an explicit mandate at action time is treated as “the agent is allowed to do what it always does.” The system works most of the time. It fails catastrophically when the implicit becomes explicit — when prompt injection or scope creep or replay reveals that authority was never separately verified.
The discipline is to make authority explicit, separate from identity, validated at every action, scoped to every mandate. The mandate is the architectural object that carries authority. Identity tells you who. The mandate tells you what. Both, together, tell you whether the action proceeds.
