Why Agent Identity Is Not the Same as Agent Authorization

Every serious AI agent platform built in the last eighteen months has solved identity. They can tell you which agent is making a call. They issue credentials, manage sessions, rotate keys, and integrate with your existing IdP. The category has a name now — Non-Human Identity, or NHI — and it has attracted real investment and real engineering.

None of that solves the problem that will actually burn enterprises in production.

The problem is not identity. It is authority. And conflating the two is how you end up with an agent that knows exactly who it is while doing something it was never supposed to be allowed to do.

What Identity Actually Gives You

Identity answers one question: is this agent who it claims to be?

The tools for this are mature. SPIFFE and SPIRE give workloads cryptographically verifiable identities via short-lived SVIDs. OAuth 2.1 gives agents tokens scoped to what a user authorized at login time. Microsoft Entra Agent ID gives agents first-class identity objects in the directory. All of these work. All of them answer the authentication question reliably.

When Agent B calls your database API, identity infrastructure can tell you that the call came from Agent B and not from some other process pretending to be Agent B. The signature checks out. The token is valid. The credential is genuine.

That is genuinely useful. It is also insufficient.

What Identity Does Not Tell You

Identity does not tell you whether Agent B was supposed to make that call in the first place.

It does not tell you who authorized Agent B to access the database. It does not tell you whether the scope of that authorization has been narrowed, expanded, or forgotten somewhere in the chain between the user who started the workflow and the agent that is now touching production data. It does not tell you whether Agent A, which delegated to Agent B, actually had the authority to delegate database access at all.

These are authorization questions. They require a different infrastructure than identity infrastructure.

The distinction matters most in multi-agent systems, because multi-agent systems have delegation chains. A user authorizes a planner agent. The planner agent delegates to a research agent. The research agent spawns a data retrieval agent. The data retrieval agent calls your database. By the time that call happens, you are four hops from the original authorization event. Identity infrastructure tells you each hop is authentic. It does not tell you whether any hop in that chain exceeded the authority the human originally granted.

The Gap the Industry Is Standing In

The current generation of NHI and agent security tools is largely solving identity. They discover agents, inventory credentials, track what tokens each agent holds, and flag when credentials are exposed or over-privileged. This is valuable work. It reduces the credential hygiene problems that have existed since the dawn of service accounts.

What it does not do is enforce transitive authority across a delegation chain.

The phrase "transitive authority" is worth unpacking. When a user authorizes a workflow with a defined scope, that scope should travel with the workflow. Every agent that participates in the workflow should be bounded by it. No agent in the chain should be able to take an action that exceeds what the human originally authorized, regardless of how many hops away from that original event the agent is operating.

Current identity systems do not enforce this. They cannot, by design. OAuth scopes tell you what a token is allowed to do. They do not tell you what the agent holding the token is allowed to delegate to the next agent in the chain. SPIFFE SVIDs prove workload identity. They do not encode what authority that workload can pass downstream. Entra Agent ID gives an agent an identity object with permissions. It does not cryptographically bind those permissions to a delegation chain that can be verified by every downstream participant.

The gap is not a flaw in these systems. They were not designed to solve this problem. But the gap exists, and multi-agent systems in production are going to fall into it.

The Failure Mode That Actually Happens

Here is how the failure manifests in practice. It is not dramatic. It does not announce itself.

A user asks a planning agent to "help with our quarterly finances." The planning agent interprets this broadly and delegates to a data agent with what it believes is a reasonable scope. The data agent, finding its scope underspecified, requests broad database access to avoid making multiple round trips. The authorization system checks that the data agent's identity is valid. It is. The token has not expired. The credential is genuine. The call goes through.

Nobody forged anything. Nobody escalated privilege in the traditional sense. The agent system produced an outcome that no human explicitly authorized through a sequence of individually valid steps, each of which passed every identity check in place.

This is what a Level 2 agentic security failure looks like. Not a hacker. Not a stolen credential. A delegation chain that nobody was watching, where authority expanded at each hop rather than narrowing, until an agent was touching data that the original user never intended to expose.

What Authorization for Agent Systems Actually Requires

Solving this requires infrastructure that was not designed for human users or static service accounts. It requires several properties working together.

First, cryptographically verifiable delegation. Not just "Agent B has a valid token" but "Agent B received specific authority from Agent A, which received specific authority from the user, and we can verify that chain cryptographically at every hop." Each delegation must be a signed artifact. Each hop must be able to prove its lineage.

Second, monotonic authority narrowing. Authority must only shrink as it travels down a delegation chain. If a user authorizes read access to invoices, every agent downstream of that authorization is bounded by read access to invoices. No agent in the chain can grant a downstream agent broader access than it holds. This invariant must be enforced, not assumed.

Third, pre-registered action manifests. Before an agent runs, the specific actions it is permitted to take should be declared and registered. When that agent makes a tool call, the call is checked against the registered manifest before any PDP query runs. This separates the question of "is this agent allowed to call this tool" from the question of "is this agent who it claims to be." These are different questions with different answers that require different infrastructure.

Fourth, cross-organizational enforcement. The hardest part. When Agent A at Acme Corp delegates to Agent B at TaxCo, the enforcement of the delegation chain cannot depend on a central authority that both organizations trust equally. The cryptographic binding must work across organizational boundaries without requiring prior trust relationships between the organizations' internal systems.

Why This Is Still Largely Unsolved

The tooling for multi-agent authorization across organizational boundaries does not exist yet in any complete, production-ready form. What exists is a set of emerging standards that are converging on the right architecture without having fully arrived.

IETF WIMSE is defining workload identity primitives. The OAuth working group has drafts for on-behalf-of flows that handle one delegation hop. DIF's Trusted AI Agents Working Group is developing Know Your Agent OS as a DID-anchored identity layer. Google's A2A protocol defines how agents communicate but explicitly leaves authorization out of scope, noting that "identity information is not transmitted within A2A JSON-RPC payloads."

The payments industry has arguably moved fastest. Mastercard's Verifiable Intent and Google's Agent Payments Protocol both implement cryptographic declaration of user intent before agent execution, with constraint-bound authorization that narrows monotonically through a transaction. These systems work because the payment domain is constrained enough that upfront intent declaration is tractable. The general agent case is harder.

The Architecture That Follows From Taking This Seriously

At CapiscIO we have spent the last several months building the infrastructure that closes this gap. The core insight that shaped the design is simple to state and non-trivial to implement: agent identity and agent authorization are separate problems that require separate infrastructure, and conflating them is how you get a system that knows exactly who every agent is while failing to prevent any of them from doing something they should not.

The CapiscIO stack separates these cleanly. RFC-002 and RFC-003 handle agent identity: verifiable identity anchored in DIDs, proof of key ownership, trust badges with short TTLs. RFC-008 handles delegated authority: Authority Envelopes that are signed by each party in the delegation chain, carry monotonically narrowing capability classes and constraints, and can be verified cryptographically by any downstream participant without a round trip to a central authority. RFC-009 handles pre-authorized action manifests: before an agent runs, its permitted action surface is registered and signed. Every tool call is checked against that manifest before any policy query runs.

The enforcement plane sits above whatever communication protocol the agents use. It does not matter whether they are communicating over A2A, MCP, direct HTTP, or something else. The authority chain is verified at each hop regardless of transport.

This is not a complete solution to every problem in multi-agent security. Prompt injection is out of scope. Data exfiltration is out of scope. But the specific problem of an agent in a multi-hop workflow taking an action that no human explicitly authorized is in scope, and it is addressable with the right cryptographic infrastructure.

The key principle we have committed to, and that we believe the industry will converge on: no agent can take an action that exceeds the authority of the human or system identity that triggered the workflow. That invariant must be enforced cryptographically, not assumed organizationally. Identity infrastructure tells you who is asking. Authorization infrastructure tells you what they are allowed to do. You need both. Most deployments today have the first and are missing the second.