Identity Is Not Permission
This chapter examines the identity stack around enterprise AI agents: what an agent identity should make visible, what authentication can prove, and what still has to be decided before an agent acts. The practical goal is to separate a genuine, attributable actor from the authority that actor may receive. Without that separation, a valid credential can look like unlimited permission.
An agent needs an identity that survives the task
An identity is useful only if it gives a policy and an audit record a stable answer to the question, “Which actor was this?” For an AI agent, that answer may involve more than a name. NIST’s concept paper asks what metadata is essential, whether identity metadata should be fixed or task-dependent, and whether an agent identity should be tied to hardware, software, or an organizational boundary. Those questions are deliberately open, but they reveal what an identity must do: distinguish an actor in the environment where decisions and records are made.
The distinction is important because an agent can be involved in an action without being the human who initiated the task. A person might ask an assistant to prepare a recommendation. The assistant may retrieve documents, call a service, or hand part of the work to another agent. If every operation is recorded under the person’s identity, the record loses the difference between the human request, the primary agent’s execution, and a delegated subtask. The organization may know that the person was involved, but not which non-human actor crossed a boundary or which component should be stopped.
The research framework therefore treats agents as first-class principals. They should not impersonate users or be flattened into ordinary deterministic services. In its relational model, human and agent principals are represented as distinct types even if an external identity provider stores them in a common system. That typed separation is not a universal identity standard; it is a modeling choice that preserves a policy-relevant distinction. A resource can then be governed by a rule that refers to the agent as the acting subject while separately asking whose authority the agent inherited.
This does not mean that every detail of an agent must become permanent identity metadata. A deployment may need an identity for the workload, a task or session may add context, and organizational boundaries may determine which policies apply. The supplied sources do not settle the correct schema. They do establish the design problem: if identity disappears whenever the task changes, or if many materially different actors share one opaque principal, later authorization and audit decisions lose the information they need.
A useful distinction is between the identity of the actor and the attributes of an execution. The actor might be a named document assistant operated by an organization. The current session might say that it is working on a particular project, inside a particular tenant, for a limited period, with a particular set of tools. Keeping those facts separate gives policy somewhere to attach conditions without creating a new permanent identity for every prompt. It also makes changes legible. If the same agent starts a new session in a different project, the system can evaluate the new context rather than assuming that yesterday’s access follows automatically.
The opposite design has two failure modes. A single broad identity can hide meaningful differences between a planning agent, a document reader, and a deployment agent. At the other extreme, an identity scheme that encodes every task detail into a new principal can make lifecycle management and audit harder, because the organization must provision, update, and revoke a large population of short-lived names. The sources do not prescribe where to draw that boundary. They do show why the boundary must be deliberate: identity should be stable enough to support attribution and lifecycle control, while task and context information should remain available for the authorization decision that changes from request to request.
Authentication answers a narrower question: is this actor genuine, or is it operating in an expected environment? NIST asks what strong authentication should mean for an AI agent and how its keys should be issued, updated, and revoked. The paper does not prescribe one credential format. Its point is that agents require a lifecycle. A key that was valid yesterday may need to be replaced; an identity may need to be disabled; and a deployment or workload may need to prove its relationship to an organizational boundary before it is admitted to a protected system.
That lifecycle is the difference between a label and a control. A label can be attached to a request after the fact. A control determines whether the actor is recognized before the request proceeds, whether its authentication material is current, and whether the identity can be associated with later sessions and actions. It also creates a place to record failure. If authentication fails, the system should not silently treat the request as the user’s request simply because a human started the conversation.
Authentication still does not answer whether an action is allowed. A genuine agent may be correctly identified and still be outside the authority delegated to it. Conversely, an agent may have a valid relationship with a user but be operating in the wrong context or against a resource that the user cannot access. Keeping these decisions separate prevents a common design error: treating proof that an actor is real as proof that every action from that actor is legitimate.
The separation also clarifies ownership when something goes wrong. The identity system owns the question of whether the presented actor is recognized and whether its authentication material is current. The authorization system owns the question of whether that actor may perform the requested operation. The resource owner or policy administrator owns the underlying permission and its conditions. An audit system records the facts needed to reconstruct the decision. Those responsibilities can be implemented by integrated services, but they should not be confused merely because a single request crosses all of them.
That matters for failure handling. A revoked key should cause authentication to fail or the identity to be rejected; it should not be silently converted into the user’s authority. A validly authenticated agent requesting a resource outside its permission should receive an authorization denial; it should not be reclassified as a human request to make the workflow succeed. And an allowed request should still produce a record that identifies the actor and the relevant decision context. These paths preserve the difference between “the system recognized you” and “the system permitted this action.”
From proof of identity to permission
The request-time sequence is easiest to understand when the layers are kept in order. An agent presents or establishes its identity. An authentication service verifies the relevant evidence. The request identifies a resource and an intended operation, and the authorization system evaluates the actor, the applicable human or organizational permission, the current context, and any delegation or scope constraints. The result is an allow or deny decision that can be linked to an audit record. A later revocation or lifecycle event must be able to change the result of a future request.
The diagram separates two failure paths that are often hidden in a single credential exchange. The identity service can reject an actor that cannot authenticate. The policy engine can reject an authenticated actor that lacks authority for the requested operation. A resource call should occur only after the second decision. The audit and lifecycle function then preserves the decision context and can supply a change—such as revocation—that affects later checks.
NIST’s proposed project is considering standards that can support different parts of this sequence. Model Context Protocol, or MCP, provides a structured way for models and agentic systems to discover and interact with external tools, data sources, and services. That makes it relevant to the action boundary, but a tool protocol does not by itself decide which agent may use which tool.
OAuth 2.0 and its extensions can carry authorization tokens and support rights delegation. OpenID Connect builds on OAuth to express authentication, consent, and authorization information. These protocols can help a system establish and transport trusted facts without sharing a human password. They are valuable integration points, but the research paper argues that static token contents do not fully express recursive delegation, changing context, or an authority envelope that must be reevaluated as the agent works.
SPIFFE and SPIRE represent another layer. SPIFFE provides a framework for issuing and managing cryptographic workload identities, while SPIRE supplies an implementation with APIs for workload attestation. Their role is to help establish which workload is running and what identity it should receive. They do not, by themselves, determine whether that workload may edit a particular document or deploy a particular change.
SCIM addresses a different lifecycle problem. It defines APIs and schemas for provisioning, deprovisioning, and managing identities across systems. For agents, that can help create, update, and revoke identities consistently. Again, lifecycle management is necessary but not equivalent to authorization. Removing an identity from directories does not explain how authority was delegated during its active period, and creating one does not grant permission to every resource.
NGAC, which NIST also names as a possible component, represents access-control policy in a graph of users, objects, attributes, and policy classes. Its support for fine-grained control, event-driven policy updates, delegation, and least privilege makes it relevant to the dynamic part of the problem. The broader lesson is not that one of these technologies wins. It is that identity, authentication, provisioning, tool interaction, and authorization are related layers with different owners and failure conditions.
Thinking in layers also prevents a misleading standards checklist. MCP can standardize how an agent discovers and calls a tool, but the tool still needs a way to distinguish the caller and evaluate the requested operation. OAuth can let a resource owner delegate access without sharing a password, but a dynamic agent system may need to evaluate more than the scope written into a token. OIDC can express identity and consent information, while workload identity can help establish the software actor that presents it. SCIM can propagate lifecycle changes across systems, but propagation does not by itself describe the authority chain that existed before a revocation. A policy system can express relationships and conditions, but it depends on trustworthy identity and runtime facts.
This division of labor is useful during design review. For every control, an organization can ask what fact it produces, who verifies that fact, where it is stored, how long it remains valid, and which later decision consumes it. That exposes gaps that a protocol inventory can conceal. For example, a system may have excellent workload attestation but no way to express that the attested agent may read project documents only while acting for a particular user. Or it may issue narrowly scoped tokens but fail to preserve which agent actually used them. The missing piece is not always a new protocol; it may be the connection between existing facts and the request-time authorization decision.
The research framework uses authentication services as sources of trusted relational facts, then evaluates those facts in a runtime authorization graph. That arrangement preserves a useful role for tokens and workload identity while refusing to let a token stand in for the entire policy. The named agent remains visible; the authority it inherits can be represented separately; and the current request can be checked against both.
A complete decision also needs more than the identity of the caller. NIST asks how to track user prompts and data inputs, how an agent should convey intent, how human-in-the-loop authorization should work, and how actions can be logged in a tamper-proof and verifiable way. These questions arise because an agent may combine information from several sources before producing a result. The system may need to know not only who called a tool, but what data entered the decision and whether the resulting action was within the approved purpose.
The sources do not provide a universal language for intent or aggregated-data sensitivity. That is an important limit. A policy can identify the actor and constrain access, but it may still need domain-specific rules or human review to decide whether a proposed action matches the user’s purpose. Likewise, audit can make a decision visible without proving that the agent reasoned correctly.
The difference can be seen in a simple sequence. A user asks an agent to prepare a report. The agent retrieves information from several sources and proposes an output that combines them. Identification can say which agent assembled the report. Authentication can establish that the agent is an accepted workload. Authorization can decide whether the agent may read each source and write the result to a destination. But those checks may not settle whether the combined output has a higher sensitivity than any individual input, whether the user was allowed to receive that combination, or whether the agent’s proposed action matches the original purpose. NIST raises these as open authorization and data-flow questions rather than pretending that a caller identity solves them.
That is why provenance and intent belong beside the access decision. Provenance records where prompts and data came from. Intent expresses what the action is meant to accomplish. Human-in-the-loop approval can supply a decision when policy cannot safely infer that purpose. None of these replaces an agent identity. They become more useful because the system can attach them to a known actor and a particular request instead of attributing an opaque chain of actions to a borrowed user credential.
The useful boundary is therefore clear. Authentication establishes a trustworthy subject; lifecycle controls determine whether that subject remains valid; authorization decides what the subject may do now; and logging preserves why the decision was made. The next problem is how authority can move from a human to an agent, and from that agent to another, without turning every hop into a copy of the original user.