A Common Language for Agent Identity

When a person signs in, decades of machinery quietly agree on who they are: an identity provider vouches for them, a token carries the claim, and every system downstream knows how to read it. AI agents have no such agreement. An agent is a piece of software that decides and acts, often on someone else's behalf, sometimes by calling other agents — yet each platform invents its own way to name that agent, describe what it is allowed to do, and prove it is genuine. The result is that an agent trusted inside one system becomes a stranger the moment it crosses a boundary. Before we can govern agents, hold them accountable, or safely let them work together, we need something we do not yet have: a common language for agent identity.

The identity gap for agents

Identity is the foundation every other security control stands on. Authentication answers 'who is this?', authorization answers 'what may they do?', and audit answers 'who did what?'. All three depend on a stable, agreed way to name the actor. For people we have that: an identity provider (the service that verifies who you are and issues proof) hands out a token, and applications everywhere know how to check it. For ordinary software we have workload or service identities that play the same role for a program.

An AI agent breaks the assumptions those systems were built on. It is not a person sitting at a keyboard, and it is not a fixed program that always does the same thing. It reasons about a goal, chooses actions, calls tools and other agents, and — crucially — usually acts on behalf of a human or an organization rather than on its own account. Existing identity models can describe a user, or a service, but they have no clean way to say 'this is agent X, acting for person Y, currently allowed to do Z.' That missing sentence is the identity gap, and every unverifiable delegation, over-broad permission, and unaccountable action downstream flows from it.

⚠️

Why it matters. If you cannot name an agent and describe its authority in a way other systems can verify, you cannot apply least privilege, accountability, or governance to it once it leaves your platform.

An agent is a new kind of actor

It helps to place agents alongside the actors our identity systems already understand. Two questions separate them cleanly. First, how autonomous is the actor — does it follow a fixed script, or does it decide its own next step? Second, whose authority does it use — its own, or authority delegated from someone else? Plot those two questions as axes and the familiar actors fall into place, and one quadrant lights up as genuinely new.

A batch job is scripted and uses its own service authority. A person at a keyboard is autonomous and uses their own authority. A traditional service account is scripted but often acts with authority granted for a task. The AI agent sits in the quadrant that older identity systems were never designed for: highly autonomous and acting on authority borrowed from a human or organization. That combination — free to choose, yet spending someone else's trust — is exactly what makes agent identity a distinct problem rather than a relabeling of what we already have.

AI agents occupy the quadrant classic identity models never targeted: highly autonomous while acting on someone else's authority.

What existing models miss

Because agents fall outside the old categories, teams tend to force them into whichever slot is nearest — and each choice fails in its own way. Give an agent a plain user identity and it inherits a human's broad standing access, with no record that a machine is now wielding it. Give it a service identity and you lose the human it acts for, so accountability evaporates: the logs show 'the service did it,' not 'the service did it for Priya, who approved this goal.'

The deeper failure is the classic confused deputy: a trusted intermediary is tricked into misusing authority it legitimately holds. An agent is a deputy by design — it holds delegated authority and acts with it — so without a way to bind each action to the specific person and specific purpose behind it, an agent that is misled or manipulated will spend real authority on the wrong thing, and nothing in the identity layer will notice. Patching this per-platform, with bespoke tokens and ad hoc rules, produces exactly the fragmentation we are trying to escape.

⚠️

The confused deputy. An agent holds delegated authority by design; if its identity cannot bind each action to a person and a purpose, misdirected authority looks identical to legitimate use.

An agent identity, layer by layer

If a single user or service identity is not enough, what exactly must an agent identity carry? Think of it as layers built out from a stable core. At the center is a durable identifier — a name that stays the same agent across restarts, updates, and scaling, so history and revocation actually stick to something. Around that sits the on-behalf-of chain: whose authority this agent is currently carrying, and through which other agents that authority passed.

Outside that are the scoped capabilities — not 'this agent is trusted,' but 'this agent may read these records and call these two tools, and nothing else.' Then comes attestation and provenance: verifiable proof that the agent is the software it claims to be and came from where it claims, so a verifier is not taking its word for it. The outermost layer is lifecycle: the ability to issue, rotate, and — above all — revoke the identity the instant something goes wrong. A common language for agent identity is really an agreement on what each of these layers means and how to express it so anyone can read it.

An agent identity is a stack of claims, from a stable core identifier out to lifecycle controls — each layer something a verifier must be able to read.

Why it must be a common language

Everything so far could be built inside a single platform — and that is precisely the trap. If each vendor expresses agent identity in its own private format, an agent is only legible where it was born. The moment it calls a tool in another system, hands work to an agent from a partner organization, or is audited by a third party, its carefully expressed identity becomes an opaque blob that the other side cannot verify. Trust then defaults to one of two bad options: block everything, or wave it through on faith.

A common language solves the boundary problem the same way HTTP solved communication between machines that had never met: not by making everyone use the same product, but by agreeing on a shared, checkable format. When 'who the agent is, who it acts for, and what it may do' is expressed in a way any verifier can read, least privilege and accountability survive the crossing between systems. Interoperability is not a nicety here — it is the whole point, because an agent that cannot be verified outside its home is an agent you cannot safely let out of it.

Per-platform identities are opaque across boundaries; a shared model stays verifiable wherever the agent goes.

A standards effort, not a single product

A common language only works if it is genuinely shared, which is why this belongs with a neutral standards body rather than any one vendor. In the United States, that work is taking shape at the National Cybersecurity Center of Excellence (NCCoE), part of the National Institute of Standards and Technology (NIST) — the federal body that publishes widely used, vendor-neutral security guidance. Its 'Software and AI Agent Identity and Authorization' effort brings industry together to define how software and AI agents should be identified and authorized in an interoperable way.

The value of a standards effort is not that it invents something no vendor could build; it is that it produces an agreement everyone can build to. A shared model lets a Microsoft Foundry agent, a partner's agent, and an independent auditor all read the same identity claims and reach the same conclusion. That is what turns agent identity from a pile of incompatible per-platform schemes into a language — and a language is the prerequisite for governing agents that increasingly work across organizational lines.

📌

Neutral by design. NCCoE (the National Cybersecurity Center of Excellence, part of NIST) convenes industry to define interoperable identity and authorization for software and AI agents — a shared agreement, not a product.

Turning identity into a decision

The payoff of a common language is that a receiving system can turn an agent's identity into an actual allow-or-deny decision, using claims it can verify rather than trust it cannot check. The check runs in order, and any failure stops it cold. First: is the agent's identity valid — a known agent, with genuine attestation, not revoked? If not, reject and log. Next: is the on-behalf-of chain intact — is the delegated authority it presents real and unbroken back to the human or organization it names? A missing or forged link means the authority is not actually there.

Only then does the specific action matter: is what the agent is asking to do inside its scoped capabilities for this purpose? If yes, allow it — and record the whole basis of the decision. If any gate fails, deny and log with a clear reason. Notice that none of these gates is possible without the layers from earlier: identity needs the identifier and attestation, the chain needs the on-behalf-of claim, and scope needs the capability descriptor. A common language is what lets every verifier run this same check and get the same answer, which is the practical meaning of governing agents at all.

With verifiable identity claims, any system can run the same ordered check — identity, then delegation, then scope — before allowing an agent action.

The language before the governance

It is tempting to jump straight to the exciting parts of agent security — clever authorization, delegation across organizations, rich audit trails. But every one of those depends on a foundation we are still building: a shared, verifiable way to say who an agent is and what it may do. Without it, each capability has to be reinvented per platform and breaks at every boundary; with it, the same claims travel with the agent and every system can reason about them consistently.

That is why 'a common language for agent identity' is the right place to begin this series. The rest — binding authority to intent, delegating safely between agents, authorizing across time, budgeting the evidence, and triaging when an agent deviates — are all sentences you can only write once the language exists. An agent you cannot name, whose authority you cannot trace, and whose permissions you cannot read is an agent you can neither trust nor govern. Everything downstream starts here.

Key takeaways

Identity is the base of authentication, authorization, and audit; agents break existing models because they are autonomous AND act on delegated authority.
An agent identity must carry more than a name: a stable identifier, an on-behalf-of chain, scoped capabilities, attestation/provenance, and lifecycle (especially revocation).
Forcing agents into user or service identities loses either the machine or the human behind an action — and invites the confused-deputy failure.
Identity only helps across boundaries if it is a COMMON, verifiable language, not a per-platform format that turns opaque the moment an agent leaves home.
A neutral standards effort (NIST's NCCoE work on software and AI agent identity and authorization) exists to make that language interoperable, not vendor-specific.
With verifiable claims, any system can run the same ordered check — identity, delegation, scope — turning identity into a real allow-or-deny decision.

Glossary

Identity provider: A service that verifies who an actor is and issues proof (a token) that other systems can check.
On-behalf-of chain: The traceable record of whose authority an agent is carrying, and through which other agents that authority passed.
Scoped capability: An explicit statement of exactly what an identity may do, rather than a blanket grant of trust.
Attestation: Verifiable evidence that a piece of software is genuinely what it claims to be and came from where it claims.
Confused deputy: A security failure in which a trusted intermediary is tricked into misusing authority it legitimately holds.
NCCoE: The National Cybersecurity Center of Excellence, part of NIST, which convenes industry to build interoperable, vendor-neutral security guidance.