AI Agent Identity Crisis

What You'll Learn

• Why a workload identity must be separated from a user login and from a permission decision.
• What the WIMSE drafts propose for agent credentials, trust domains, attestation, and owner binding.
• How SPIFFE SVIDs and OAuth token exchange can fit into an agent identity design.
• How to build delegation, audit, revocation, and approval controls without treating a draft as a finished standard.

Why AI Agent Identity became an architecture issue

An AI agent is software that receives a task, uses context, and takes actions through services or tools. The identity question is not limited to the model. It includes the running workload, the environment that launched it, the organization that approved it, and the user or service on whose behalf it acts.

That distinction matters because an agent can be legitimate while an individual action is not permitted. A valid process may still request a resource outside its assigned scope. A user may approve one task while a downstream agent receives a broader permission. A credential may be authentic but stolen from a runtime and replayed elsewhere. Identity proves a relationship. Authorization decides what that relationship allows.

The existing article treated OAuth and SAML as if they were simply failing. That is too broad. They remain useful parts of enterprise access systems. The more precise issue is that a human login, a bearer token, or a broad service account does not by itself describe an agent’s workload identity, delegation chain, execution context, or current task boundary.

For a practical introduction to surrounding agent systems, see the site’s guide to AI agents in enterprise security governance. Identity should be designed as one control layer in that wider system rather than presented as a single product feature.

What WIMSE actually proposes

The IETF document titled WIMSE Applicability for AI Agents discusses how Workload Identity in Multi System Environments could support independent identities and credential management for agents. It is an active Internet-Draft with an Informational intent. The document itself says that an Internet-Draft is work in progress and has no formal standing in the IETF standards process.

That status is essential. WIMSE AI-agent applicability is a proposal for discussion, not an adopted protocol that every deployment can implement in the same way. Its value is the set of design requirements it makes visible. The document calls for independent identities distinct from users and devices, automated credential management, fine-grained task-oriented access tokens, reduced credential validity, and workflows whose security context remains visible.

The draft defines a trust domain, an identity server, an identity proxy, an agent, an owner, and a dual-identity credential. The dual-identity idea is especially useful for policy design. It describes a credential that binds the agent identifier and the owner identifier with associated public keys. That can help a relying service distinguish the software that acted from the principal that approved or owns it.

The proposal also describes a request and issuance flow. The agent presents a public key and proof of possession. A proxy can forward the request with attestation evidence. An identity server evaluates the evidence and issues a credential. The agent then receives the credential through the proxy. These steps are design patterns. They do not remove the need for local policy, key protection, logging, and revocation.

Identity, authentication, and authorization are different

Security teams often use identity, authentication, and authorization as interchangeable terms. An agent deployment needs them separated. Identity is the name or identifier assigned to the workload. Authentication checks evidence that the claimant controls the relevant credential. Authorization evaluates whether that authenticated principal may access a target resource or perform an action.

Accounting and audit add another layer. A service should be able to record the agent identity, the owner or requesting principal when available, the target service, the requested operation, the policy decision, and the security context that influenced the decision. A single user ID is not enough when several agents act in sequence.

This separation also clarifies the role of an agent framework. A tool protocol can standardize how an agent discovers and calls a tool. It does not automatically create a trustworthy identity or a least-privilege policy. The site’s explainer on Model Context Protocol is useful for that distinction. The protocol path and the identity path should be evaluated together, but they solve different problems.

How SPIFFE and SPIRE fit the workload layer

SPIFFE is a set of open-source standards for identifying software systems in dynamic and heterogeneous environments. Its identity documents are called SVIDs. The official SPIFFE overview says workloads can use an SVID to authenticate to another workload through TLS or by signing and verifying a JWT.

This makes SPIFFE a useful workload identity layer. It can help a service answer, “Which workload is calling me?” without placing a long-lived API key in a source file or a deployment variable. SPIRE is an implementation that can issue SVIDs through attestation-based workflows and expose the Workload API for delivery and rotation. The exact configuration depends on the deployment and its trust domain.

SPIFFE does not decide every business permission. An SVID may authenticate a research agent, a billing agent, and a gateway. The receiving service still needs policy that distinguishes what each workload may do. The credential must also be protected from misuse. A valid identity is not a license for broad access.

For a security architecture, SPIFFE can identify the workload while another policy system evaluates the operation. This is more accurate than saying SPIFFE makes an agent safe. It gives a service a stronger basis for authentication and audit, while authorization, input handling, and runtime controls remain necessary.

Delegation without impersonation

Delegation is the normal relationship when an agent acts for a user or organization. The agent should keep its own identity while the request carries evidence that authority was delegated. Impersonation is different. In an impersonation model, the acting party may appear as the represented principal within the rights granted by a token. That can make accountability harder if the receiving service records only the represented user.

RFC 8693 OAuth 2.0 Token Exchange defines a protocol for obtaining security tokens from an authorization server. It covers delegation and impersonation semantics. In a delegation flow, a subject token can represent the party on whose behalf the request is made and an actor token can represent the party acting for that subject. The authorization server decides whether a new token is issued and which policy applies.

That gives an agent system a standard building block for passing security context to a downstream service. It is not a complete task authorization model. RFC 8693 leaves token syntax details, trust models, proof of possession, and deployment policy to the implementation or to an additional profile. Token exchange should therefore be treated as a controlled boundary, not as permission inheritance by default.

A useful rule is that every delegation hop should preserve the actor, the represented principal, the target, the task boundary, and the expiry decision. If a downstream agent cannot present those facts, the receiving service should deny the call or request a fresh approval.

Why token exchange does not solve policy

A token exchange service can transform one credential into another. It cannot know whether a requested combination of data is appropriate unless the deployment supplies a policy model. This matters in multi-agent workflows because each individual retrieval may be permitted while the combined result exposes information that the user or downstream agent should not receive.

The research paper Authorization Propagation in Multi-Agent AI Systems describes this as an authorization propagation problem. Its analysis separates prompt injection from structural questions about transitive delegation, aggregation inference, and time-sensitive validity. The paper is research work rather than a standards document, but it provides a helpful way to test an architecture.

For each tool call, the policy decision should be evaluated at the retrieval boundary. For each delegation, the new agent should receive no more authority than the approved task requires. For each synthesis step, the system should consider data labels, purpose, audience, and whether the combination creates a new disclosure. For each long workflow, revocation and expiry should be checked again rather than assumed from the first approval.

This is where the site’s guide to AI compliance tools can provide governance context. A compliance checklist does not replace authorization policy, but it helps identify the evidence that should exist when a high-impact system is reviewed.

Attestation and owner binding

Credential issuance should consider more than an agent’s requested name. The WIMSE AI-agent draft discusses attestation evidence from the operating system and hardware as an input to the identity server’s issuance or renewal decision. Attestation can describe the environment and the operational status that a verifier expects. It does not prove that the model will always make a correct decision.

Owner binding addresses a different question. It links an agent to an individual, team, or organization that can approve its use. The draft describes an agent-mediated model, an owner-mediated model, and a server-mediated challenge and response model. Each has a different operational path and attack surface. A local approval flow may suit a developer tool. A gateway approval flow may suit a central enterprise platform. An out-of-band challenge may suit a service provider workflow.

Owner binding should include a clear statement of what is being approved. “Use the system” is too broad. A useful record identifies the agent class, the task, the target services, the data categories, the required human confirmation, and the conditions for expiry or revocation. The signature proves approval of the record. It does not turn an unsafe instruction into a safe one.

The authorization propagation problem

Consider a workflow in which a coordinator agent asks a search agent for documents, asks a reporting agent to combine them, and sends the result to a user. The coordinator may be allowed to start the task. That does not automatically mean the search agent may access every document, the reporting agent may see every field, or the final user may receive every combination.

Authorization propagation is the discipline of preserving the relevant authority and limits across the whole workflow. The system should retain enough context to answer which principal initiated the request, which agent acted, which policy approved each retrieval, which data was included, and whether the output was transformed or combined.

In practice, this calls for a workflow record or signed context that travels with the request. The record should be checked at every sensitive boundary. It should not be treated as a permanent pass. A task can expire. A user can lose access. A service can change its policy. A downstream agent can receive a narrower token while keeping its own identity.

These controls also reduce the impact of indirect prompt injection. Content can still influence an agent, but it should not be able to grant a new credential or widen a policy scope. The authority decision belongs to a service or policy engine that can inspect the workload identity and the signed security context.

A reference architecture for AI Agent Identity

A workable design separates the control plane from the agent runtime. The control plane maintains trust domains, issuer keys, workload registration, owner records, policy rules, approval events, and revocation state. The runtime requests a credential, presents it to the receiving service, and carries the approved context through the workflow.

An identity proxy can mediate credentials and context between an external gateway and internal workloads. The WIMSE architecture draft describes this kind of proxy as an intermediary that may inspect, replace, or augment workload identity and security context. That function should be narrow and observable. A proxy that silently rewrites authority becomes a hidden policy engine.

At the edge, a user or client may authenticate with an existing identity provider. The gateway can then exchange or transform that context for an internal token that is meaningful to downstream services. Each workload authenticates the next workload with its own credential. Each receiver makes its own authorization decision and records the actor and represented principal.

For operational context, teams can compare this pattern with the site’s AI tool comparison guide. Different runtimes may need different controls, but the identity record should remain portable across the tool layer.

Deployment checklist for security teams

The following checklist is a design sequence rather than a product recommendation. It starts with inventory and ends with continuous review. A team should document where an agent receives identity, where it receives authority, and where the receiving service verifies both.

• Do not share a human password or long-lived API key with an agent process.
• Give each workload a distinct identity and record how it is issued.
• Use a bounded credential lifetime and an automated renewal path.
• Keep the actor identity separate from the user or organization represented.
• Limit token audience and scope to the downstream service and current task.
• Require a fresh policy decision for high-impact actions and changed context.
• Make revocation visible to the issuer, proxy, receiving service, and audit system.

When the workflow also depends on stored context, review the site’s AI agent memory systems guide alongside the identity controls. A memory store can carry instructions and data across sessions, so its read and write permissions belong in the same authority map.

Common design errors to avoid

The first error is treating identity as authorization. A certificate can identify a workload while granting no permission at all. The second is treating a user token as an agent identity. A user token may be valid at an edge service while being unsuitable for internal workload authentication. The third is forwarding a bearer token to every downstream service without checking its audience or replay risk.

The fourth error is hiding delegation. If an agent calls another agent, the log should not collapse both actions into one user event. The fifth is assuming that a protocol draft is a stable standard. WIMSE drafts can change, expire, or be replaced. Production teams should record the version and profile they implement, monitor the relevant working group, and plan for migration.

The sixth is using an approval screen as the only control. A human may approve a task without seeing the data paths, downstream agents, or effective scope. Approval should be paired with machine-enforced limits, key protection, attestation where appropriate, and service-side authorization.

Finally, do not claim that a single framework prevents every attack. Prompt injection, stolen credentials, incorrect policy, compromised dependencies, and unsafe outputs require different controls. Identity makes accountability and access decisions more precise. It does not replace secure software development or runtime monitoring.

Conclusion: from shared secrets to accountable agents

The AI Agent Identity problem is best understood as a workload and authorization architecture issue. WIMSE proposals show how independent agent credentials, owner binding, attestation, and visible context could fit together. SPIFFE supplies open workload identity primitives. OAuth token exchange supplies a standard way to request a new token and carry delegation semantics. NIST’s AI Risk Management Framework supplies a governance reference for identifying, measuring, managing, and governing AI risk.

None of these pieces is a complete answer on its own. A service still needs a policy model that limits the task, keeps the actor visible, protects keys, checks context at each boundary, and records decisions for review. The safer direction is therefore not to discard human identity systems. It is to add a separate workload identity and authorization layer that reflects how agent workflows actually run.

Teams adopting agentic software should begin with an inventory of identities and authority paths. Then they can choose credentials, define trust domains, bind owners, enforce narrow delegation, and test revocation. That sequence turns an unclear identity crisis into a set of engineering decisions that can be inspected and improved.