Agent Identity: Distinguishing Who Is Acting from Who Authorized It#

TL;DR#

Most access-control systems today answer one question well - "which human authorized this action" - and silently collapse a second, distinct question into it: "which specific software process actually performed it." An agent is not the human who deployed it, and once more than one agent can act under the same human's authority, a system that only logs the human's identity cannot tell you which agent misbehaved, cannot revoke one agent without revoking the human's entire access, and cannot bound the blast radius of a single compromised agent to that agent alone. Agent identity is the fix: treating the agent itself as a distinct principal in the access-control model, separate from both the human it acts for and the authority it was delegated.

The idea#

Every prior lesson in this subject has, without saying so, assumed a two-party picture: a human sits behind an agent, the agent has some credential, and when something goes wrong you can trace the credential back to the human who is accountable. agent-security-and-operations/03 scoped what that credential could do (least-privilege tools, scopes, and credentials). model-context-protocol/05 covered how a server verifies a caller's credential without trusting the caller's own claims about identity (OAuth 2.1, audience-bound tokens). multi-agent-orchestration/07 covered what happens to authority as it crosses a delegation hop from one agent to another (attenuation, task-scoped envelopes). None of these three lessons asked the question this one does: independent of what the agent is allowed to do and independent of how authority flows to it, who - or what - actually did this specific thing?

That question has a real, non-academic bite the moment more than one agent can act under a single human's authorization, or an agent can act with no human directly in the loop for a given step. Consider a straightforward, common setup: an engineer has three coding agents running in three worktrees, all authenticated against the same GitHub organization using the engineer's own OAuth grant. A malicious dependency gets pulled into one worktree and its postinstall script convinces that one agent to push a bogus commit. If the audit log only records "authorized by alice@company.com," incident response has three equally plausible suspects and no way to narrow them, no way to revoke just the compromised agent's access without also cutting off the other two and Alice herself, and no way to answer "how many other actions did this agent take before we caught it" without first solving "which log lines even belong to this agent" - a problem that should not exist. The gap is structural: the system tracked authorization (Alice said yes) but never tracked identity (which of Alice's three agents was the actor), and those are not the same fact.

This is exactly the problem the U.S. National Institute of Standards and Technology named as a first-order infrastructure gap when it launched the AI Agent Standards Initiative on 2026-02-17: existing identity and access management frameworks were built for two kinds of principal - human users and static, long-lived software services - and an autonomous agent that queries databases, calls tools, and acts across systems at machine speed and volume fits neither assumption cleanly. The companion NCCoE concept paper, "Accelerating the Adoption of Software and AI Agent Identity and Authorization" (published 2026-02-05), states the same gap concretely: traditional IAM was not designed for an entity that can autonomously perform actions across multiple systems in a single task, continuously, at a speed that makes per-action human authorization impractical - and asks, as its central open question, how to identify, authorize, audit, and hold non-repudiable such an entity at all.

How it works#

Three distinct concepts that get conflated into one#

Before anything else, separate three things this lesson's title deliberately keeps apart, because the standards landscape only makes sense once they are distinct in your head:

Identity - which specific entity is acting right now. Not "an agent," not "Alice's agent" as a category, but this one running instance: this model, this deployment, this process, distinguishable from every other agent that might also be acting under the same human's authority. This is the fact the GitHub worktree example above was missing.
Delegated authority - what that entity is allowed to do, and on whose say-so. This is the territory agent-security-and-operations/03 (scoping) and multi-agent-orchestration/07 (propagation across hops) already covered in depth. Authority answers "can it," identity answers "is it the one that did."
Provenance - what it is made of and where it came from - which model, which version, whose deployment, which vendor's infrastructure it runs on. Provenance is a property of an identity (this agent instance is built on model X, version Y, deployed by organization Z), not a substitute for one. Two agent instances can share identical provenance (same model, same deployment template) and still need to be distinguishable identities, because one of them might be compromised while its identical twin is not.

A system that has only ever tracked delegated authority - "Alice authorized this" - has answered the second bullet and never touched the first or third. That is precisely the gap this lesson exists to close: an agent needs to be a first-class principal with its own identity, so that authority and provenance can be attached to that identity rather than the identity being inferred, after the fact and imperfectly, from whichever human's authority the agent happened to be exercising.

Worked example: the GitHub worktree incident, replayed with agent identity#

Return to the three-coding-agents-one-human-token scenario above, now redesigned so each agent instance is a distinct principal.

Before (authority-only model): all three agents authenticate to GitHub using Alice's personal OAuth token. The commit log and GitHub's audit trail record alice@company.com as the actor for every push, regardless of which agent made it. When agent 2 is compromised, the response team's honest first task is reconstructing, from timestamps and commit content alone, which pushes came from which agent - forensic archaeology that a well-designed system should never require.

After (agent-as-principal model): each of the three agents is provisioned its own machine identity - its own short-lived, scoped credential, distinguishable in every log line from the other two and from Alice's own direct human actions. GitHub's audit trail (or an internal proxy layer sitting in front of it) now records agent:coding-agent-worktree-2 (delegate of alice@company.com, deployed 2026-08-01) rather than just alice@company.com. The moment anomalous commits are spotted, the response is immediate and precise: revoke agent 2's credential alone; agents 1 and 3, and Alice's own access, are untouched; every prior action agent 2 ever took is already segregated in the log by identity, not reconstructed after the fact.

Authority-only model                    Agent-as-principal model
-------------------------------         -------------------------------
Log: "alice@company.com pushed          Log: "agent:worktree-2 (delegate
      commit abc123"                          of alice@company.com)
                                                pushed commit abc123"

Compromise detected in one agent   ->   Compromise detected in one agent
  Revoke Alice's token                    Revoke agent:worktree-2's
  -> all 3 agents AND Alice lose            credential only
     access simultaneously                -> agents 1, 3, and Alice
  Reconstruct "which agent did what"          keep working uninterrupted
     from commit content/timestamps        Prior actions already
                                              attributable per-agent

Worked example: two agents, identical delegated authority, different identity#

Delegated authority and identity are genuinely independent axes, not two views of the same fact - this example makes that independence concrete. A finance organization grants a "read Q3 expense reports" scope to an autonomous reconciliation agent every Monday morning. In week one, that scope is exercised by agent:reconciler-v1 running on the finance team's own infrastructure. In week six, after a vendor migration, the identical scope is exercised by agent:reconciler-v2, a newer deployment running on a different vendor's managed agent platform, provisioned by the same person, for the same recurring task. The delegated authority is unchanged - same scope, same grantor, same recurring purpose - but the identity is different, and that difference matters: if week six's data export pattern looks anomalous, an auditor needs to know it was v2, running on new infrastructure, not v1, before concluding anything about whether the authority itself was misused versus whether the new deployment introduced a bug or was compromised. A system that records only "reconciliation scope was exercised, grantor: finance-team" cannot make that distinction; a system that records the agent identity alongside the authority can.

The emerging standards landscape, as evidence the gap is real infrastructure work, not a hypothetical#

None of the following has "won" as of August 2026 - this landscape is presented as dated evidence that agent identity is being treated as real, infrastructure-backed engineering work by standards bodies and industry, not as a settled architecture to adopt wholesale. Multiple competing and complementary efforts are active simultaneously:

Example (Aug 2026): several standards efforts are underway to formalize agent-as-distinct-principal identity - NIST's NCCoE concept paper (published 2026-02-05, comment period closed 2026-04-02) frames the identification/authorization/auditing/non-repudiation problem and proposes a lab demonstration rather than a finished standard; OIDC-A extends OpenID Connect Core with new claims specifically for representing agent type, underlying model, version, provider, and instance identifier, plus delegation-chain and attestation claims, so a relying party can authenticate an agent's identity the way it already authenticates a human's; KYA-OS (formerly MCP-I, donated by Vouched to the Decentralized Identity Foundation in March 2026, formally named 2026-04-22) takes a different technical approach - decentralized identifiers and verifiable credentials binding "which agent, authorized by whom, scoped to what" into a tamper-evident, cryptographically verifiable credential that can be checked across organizational boundaries, with three conformance levels for different assurance needs. See agentic-engineering/README.md's landscape-snapshot for what remains current by the time you are reading this.

The three efforts are not solving identical problems: the NCCoE paper is a government-convened framing exercise aimed at producing implementation guidance; OIDC-A extends an existing, widely deployed human-identity standard so agent identity slots into infrastructure that already speaks OIDC; KYA-OS builds a purpose-specific credential format from decentralized-identity primitives rather than extending OIDC. A team building this today is choosing among genuinely different technical bets, not picking a skin for one agreed architecture - which is itself the honest state of the field in August 2026, not a gap in this lesson's research.

Why this is architecturally durable regardless of which standard wins#

The reason to learn this now, before any one standard has consolidated, is that the underlying requirement is independent of the standard: any system where more than one agent can act under a single human's authority, or where an agent can act without a human directly present for a given step, needs some way to answer "which specific agent did this" that is distinct from "who authorized it." That requirement does not go away if OIDC-A loses to KYA-OS, or if NIST's eventual guidance favors a third approach entirely - it is the same shape of problem distributed systems solved decades ago by giving services their own identities (service accounts, workload identity) distinct from the humans who deployed them, now applied to a caller whose behavior is driven by a model rather than fixed code.

Pros#

Precise revocation: a compromised or misbehaving agent's access can be cut off without touching the human's own access or any other agent acting under the same authority - directly closing the gap the worktree example demonstrates.
Accurate auditing and non-repudiation: every action is attributable to the specific agent instance that performed it, not reconstructed after the fact from timestamps or content, and not falsely attributed to "the human" when the human never issued that specific instruction.
Bounded blast radius: because identity, authority, and provenance are tracked as separate facts, a compromise of one agent's identity does not automatically imply compromise of the authority it was delegated or of every other agent sharing that provenance - each axis can be reasoned about and contained independently.

Cons#

Real provisioning overhead: giving every agent instance its own credential, and maintaining a directory of agent identities distinct from human and service identities, is genuine infrastructure work most organizations have not built yet - it does not come for free from an OAuth setup designed for humans.
No consolidated standard to adopt as of August 2026: teams building this today are choosing between actively evolving, only-partly-interoperable approaches (OIDC-A, KYA-OS, whatever the NCCoE demonstration eventually recommends), with real risk of migration cost if the field converges elsewhere later - the same immaturity multi-agent-orchestration/07 already flagged for authorization propagation applies here too, for the adjacent identity question.
Identity without corresponding authority discipline is hollow: knowing precisely which agent did something is much less useful if that agent's delegated authority was never scoped in the first place (agent-security-and-operations/03) - agent identity is necessary infrastructure, not sufficient security on its own.

Alternatives#

Authority-only tracking (the status quo default) — log only which human authorized an action, treat every agent acting under that human's grant as indistinguishable; the simplest thing to implement and the default most systems fall into unless someone deliberately builds agent identity, but it is exactly the gap this lesson exists to close, and the cost shows up precisely when you need precise revocation or audit.
One shared service account per team or system, not per agent — a step better than pure human-authority tracking (at least agent-driven traffic is distinguishable from direct human traffic), but still collapses multiple distinct agent instances into one identity, so it cannot answer "which of our five agents on this shared account did this" any better than the pure authority-only model can distinguish agents from the human.
Provenance-only tracking (model/version tagging without a distinct principal) — logging "this action came from model X version Y" tells you what the agent is built from, but two different deployments of the identical model/version are still indistinguishable, which is precisely the failure the reconciler-v1/v2 worked example shows; provenance is useful metadata attached to an identity, not a replacement for one.

When to use it#

Provision a distinct identity for every agent that can act with real-world effect, whenever more than one agent instance might act under the same human's or organization's authority, or whenever an agent can take an action without a human directly present at that specific step - which, per agent-security-and-operations/01's framing of which agents carry real risk, describes essentially every production agent with side-effecting tools. Build this in from the start the same way you would provision separate service-account identities for separate backend services, rather than retrofitting it after an incident makes the gap painful.

When NOT to use it#

A single, fixed automation script running under one human's account, with no possibility of a second instance ever running concurrently and no autonomous multi-step action a human doesn't directly trigger, gains little from a dedicated agent-identity layer - it is functionally a service account already, and treating it as a distinct "agent principal" is ceremony without payoff. Be cautious, though, about assuming this describes your system permanently: the moment a second agent instance, a second worktree, or a second deployment of the same automation is added, the "only one caller could possibly have done this" assumption that made authority-only tracking adequate silently breaks, and revisiting the identity question after that point costs more than building it in from the start.

Key takeaways / mental model#

Ask three separate questions about every agent action, and notice that most systems today only ever answer the second one: which specific entity did this (identity), what was it allowed to do and on whose say-so (delegated authority - agent-security-and-operations/03, multi-agent-orchestration/07), and what is it built from and who deployed it (provenance). A system that only tracks delegated authority has, in effect, decided that every agent acting under one human's authorization is interchangeable - fine until you need to revoke one without revoking all, or attribute one incident to one actor rather than a set of equally plausible suspects. The durable fix, independent of which named standard (OIDC-A, KYA-OS, or whatever the NCCoE's eventual guidance favors) eventually consolidates, is architectural: give the agent its own identity as a first-class principal, and attach authority and provenance to that identity rather than inferring identity from authority after the fact.

Self-check questions#

Using the GitHub worktree worked example, explain concretely what "revoke the compromised agent's access" means under the authority-only model versus the agent-as-principal model, and why the difference matters for incident response time.
This lesson names three distinct concepts - identity, delegated authority, and provenance. Construct a scenario, different from this lesson's examples, where two agents have identical provenance (same model, same deployment template) but need to be tracked as distinct identities. What goes wrong if they are not?
A colleague says "we already solved this - our audit log records which OAuth token was used for every action, and each agent has its own token." Using model-context-protocol/05's audience-binding mechanics, explain whether a distinct, audience-bound token per agent is the same thing as agent identity, or a necessary-but-different building block toward it.
Compare OIDC-A and KYA-OS as this lesson describes them: what different technical starting point does each take (extending an existing human-identity standard versus building a purpose-specific decentralized-identity credential), and what does that difference suggest about the kind of infrastructure each fits most naturally into?
multi-agent-orchestration/07 covered authorization propagation across a delegation chain (A delegates to B delegates to C). Explain why solving that lesson's attenuation problem completely - authority correctly narrowing at every hop - still would not, by itself, answer "which specific agent instance performed this action," and what this lesson's identity layer adds on top.
A startup founder argues: "we're a five-person team, one engineer runs all our agents under her own account - agent identity is enterprise overkill for us." Using this lesson's "When NOT to use it" section, evaluate that argument, and identify the specific change in the team's setup that would flip the answer.

References#

NIST, Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation, 2026-02-17
NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization - Concept Paper, published 2026-02-05 (comment period closed 2026-04-02)
NIST CSRC, Accelerating the Adoption of Software and AI Agent Identity and Authorization (initial public draft)
OpenID Connect for Agents (OIDC-A) 1.0: A Standard Extension for LLM-Based Agent Identity and Authorization, arXiv:2509.25974, 2025-09, revised 2026
Decentralized Identity Foundation, DIF and Vouched Advance Agentic Identity with KYA-OS, donation 2026-03, naming 2026-04-22
Cloud Security Alliance Labs, NIST AI Agent Standards: What It Means for Enterprise Security, 2026
agent-security-and-operations/03, Least-Privilege Tool Permissions and Scoped Credentials (companion lesson on scoping what an agent can do, distinct from who is doing it)
model-context-protocol/05, Authorization and Statelessness in Agent Protocols (companion lesson on the MCP server's OAuth 2.1 resource-server model; this lesson is about the agent's own identity as a principal, not the server verifying it)
multi-agent-orchestration/07, Governance in Multi-Agent Systems: Authorization Propagation (companion lesson on how delegated authority attenuates across hops; this lesson is the more general question of distinguishing the acting agent from the authority it exercises)