OAuth can authorize a request. SPIFFE can identify a workload. A signed Agent Card can protect an agent's advertised metadata. None of those controls, by itself, tells you which agent definition interpreted a goal, how authority changed across sub-agents, or who is accountable for the final action. Here is the identity architecture I would use before letting agents operate across enterprise systems.
Research and standards status checked October 10, 2026.
Every Credential Was Valid. Nobody Could Explain the Change.
Imagine an on-call engineer asks an internal operations agent to investigate a spike in checkout failures.
The engineer signs in through the company identity provider. The operations agent runs under a valid workload identity. It delegates diagnosis to an observability agent discovered through an Agent2Agent (A2A) Agent Card. The diagnosis agent recommends increasing a container memory limit. A deployment agent obtains a short-lived OAuth token, calls a Kubernetes tool through a Model Context Protocol (MCP) server, and updates production.
The error rate falls.
The next morning, the platform team reviews the change. The Kubernetes audit log says that prod-agent-runtime modified the deployment. The OAuth log says the token was valid. The A2A Agent Card was signed. The MCP server authenticated the caller. Every local control worked as designed.
Then the questions begin.
Which agent actually decided that a production change was necessary? Which model, instruction set, tool bundle, and policy version shaped that decision? Did the engineer authorize diagnosis, remediation, or both? When the operations agent delegated work, did it pass the engineer's full authority or a smaller subset? Was the deployment agent acting for the engineer, for the operations agent, or for the platform team that owned the runtime? Could a different model build have used the same service account? Can the organization revoke this one delegated task without disabling every agent on the platform?
The credentials cannot answer those questions.
They prove that a principal presented acceptable cryptographic material at a particular boundary. They do not automatically preserve the complete relationship among the human principal, the agent definition, the running workload, the task, the delegation chain, the approved purpose, and the observed action.
That missing relationship is the agent identity problem.
It is becoming urgent. NIST created its AI Agent Standards Initiative in February 2026 and lists software and agent identity and authorization as a related activity. The National Cybersecurity Center of Excellence (NCCoE) is exploring standards-based approaches for identifying and authorizing software and AI agents. A separate April 2026 research paper argues that current infrastructure leaves five structural gaps, including semantic intent verification and recursive delegation accountability.
This does not mean enterprises need to invent a new cryptographic identity system for every model.
It means they need to stop treating a service account as the complete identity of an autonomous system.
A credential proves that a caller may cross one boundary. An agent identity must preserve who is acting, what software and policy are acting, whose authority is being used, for which task, and what actually happened across every boundary.
That distinction is the whole article.
TL;DR
- Authentication is not agent identity. An API key, certificate, or access token can authenticate a workload. It does not identify the model, instructions, tool configuration, policy version, task purpose, delegation parent, or behavior that produced an action.
- An agent has several identities at once. Production systems must distinguish the human or business principal, the registered agent definition, the running workload instance, the task or session, the delegated authority, and the evidence generated by execution.
-
Shared service accounts collapse accountability. If ten agents and five model versions all act as
agent-runtime-prod, downstream logs can prove that the platform acted but not which agent configuration caused the decision. - Delegation is different from impersonation. OAuth 2.0 Token Exchange can represent a subject and an actor. Delegation keeps both visible; impersonation makes the actor appear as the subject within the token's rights context. Agents should normally preserve the actor.
- Authority must shrink at every hop. A child agent should receive a shorter-lived, audience-bound, task-bound subset of its parent's authority. It should never inherit a reusable user token or a platform-wide credential by default.
- A signed Agent Card is useful but incomplete. A2A 1.0 can protect the integrity of advertised agent metadata using JSON Web Signatures. That does not prove that the runtime still matches the card, that its behavior is safe, or that a specific action was authorized.
- Workload identity remains essential. SPIFFE-style identities and cloud workload identity can prove which deployed workload is communicating. They should be one input to agent identity, not renamed as the whole solution.
- The missing object is task-bound identity evidence. I propose an agent identity envelope that binds the principal, agent definition digest, workload identity, task, purpose, delegation chain, authority constraints, policy decision, approval, and trace references.
- Policy must be enforced at the resource. A prompt that says "do not deploy without approval" is guidance. The Kubernetes API, payment service, or database must reject an action whose task-bound authorization does not satisfy policy.
- Agent identity is not legal personhood. Giving software a durable identifier does not make it a legal or moral actor. A human or organization must still own the agent, accept the risk, and remain accountable for deployment decisions.
- Start with one consequential workflow. Do not wait for a universal agent identity standard. Compose existing workload identity, OAuth, transaction authorization, signed metadata, policy, and tracing around one bounded production action, then test the delegation failures deliberately.
Credentials, Identity, Authority, and Evidence Are Different Things
The word "identity" is overloaded in enterprise systems.
An identity provider may call a user record an identity. A service mesh may call a workload certificate an identity. An OAuth server may put a subject into a token. An A2A Agent Card has an identity section containing a name, description, and provider. An audit platform may infer identity from the account written into a log.
All of those uses can be valid.
They are not the same object.
| Layer | Question it answers | Typical mechanism | Normal lifetime |
|---|---|---|---|
| Human or business principal | Who requested or owns the outcome? | Enterprise IdP, OIDC, directory, service owner record | Months to years |
| Agent definition | Which approved agent configuration is this? | Registry ID, version, signed manifest, artifact digest | One release |
| Workload instance | Which running process or deployment is communicating? | SPIFFE ID, mTLS certificate, cloud workload identity | Minutes to hours |
| Task or session | Which bounded piece of work is this action part of? | Task ID, session ID, purpose, trace ID | Minutes to days |
| Delegated authority | What may the current actor do on whose behalf? | OAuth token, token exchange, rich authorization details, policy grant | Seconds to minutes |
| Execution evidence | What did the actor actually request and change? | Signed audit event, trace, policy decision, resource receipt | Policy-defined retention |
The layers must connect, but they should not be collapsed.
A stable agent definition can launch many workload instances. One workload can run many agent definitions. One session can cross several workloads after retries or failover. One agent can act for different users. One user can delegate different authority to the same agent for different tasks.
This is why service-account = agent identity fails as a production model.
It binds identity to the hosting process while the meaningful behavior is assembled from several mutable inputs:
- the model and model version;
- system and developer instructions;
- skills and plugin content;
- MCP servers and tool schemas;
- memory and retrieved context;
- policy configuration;
- approval state;
- runtime code; and
- downstream credentials.
Change any one of those and the behavior can change while the service account remains identical.
I use this mental model:
Agent identity at time t
= declared definition
+ attested runtime
+ task context
+ delegated authority
+ observed evidence
That is not a proposed mathematical standard. It is an engineering test.
If your system records only one term, it does not have enough information to explain a consequential agent action.
Why Software Identity Becomes Harder When the Software Can Decide
Traditional services already act for users. A web application receives a user token, calls backend services, and writes data. Why not reuse that architecture unchanged?
We should reuse as much as possible.
The difference is not that agents are mystical. The difference is that the decision boundary has moved.
A traditional endpoint usually maps a defined request to a defined code path. An agent interprets a goal, selects tools, creates intermediate plans, reads untrusted content, delegates to other agents, and may choose an action the original caller never named explicitly.
The April 2026 paper AI Identity: Standards, Gaps, and Research Directions for AI Agents describes AI identity as a continuous relationship between what an agent is declared to be and what it is observed to do. It identifies five unresolved gaps:
- Semantic intent verification: a valid request does not prove that the resulting action matches the user's intended meaning.
- Recursive delegation accountability: authority and responsibility become unclear when agents delegate to sub-agents repeatedly.
- Agent identity integrity: mutable models, prompts, memory, and tools can make the deployed behavior diverge from the registered identity.
- Governance opacity and enforcement: policies may exist, but organizations cannot always inspect or enforce how agent decisions are produced.
- Operational sustainability: identity infrastructure must work at machine speed and scale without turning every action into a manual ceremony.
This paper is a research preprint, not a ratified standard. Its gap analysis is still useful because it explains why adding another JWT claim will not finish the job.
Cryptography can prove who signed a declaration.
It cannot prove that a nondeterministic model will behave consistently with that declaration.
Identity for agents therefore has two sides:
- Declared identity: what the organization registered, approved, signed, and authorized.
- Observed identity: what this runtime, under this configuration and task, actually did.
Production trust comes from continuously comparing the two.
Follow One Action Through the Delegation Chain
Return to the checkout incident.
Engineer
| OIDC login + request
v
Operations Orchestrator
| A2A task delegation
v
Observability Agent
| recommendation + evidence
v
Deployment Agent
| MCP tool call
v
Kubernetes MCP Server
| Kubernetes API request
v
Production Cluster
There are at least six security decisions in this apparently simple flow.
1. The engineer is authenticated
The identity provider establishes the engineer's human identity and session. It may prove multi-factor authentication and group membership.
It does not prove that the sentence "fix checkout" means "modify the production memory limit."
2. The orchestrator is authenticated
The runtime may receive a short-lived workload credential. This proves that an approved deployment is calling internal services.
It does not prove which agent definition, model, or instruction bundle is active inside that runtime.
3. The observability agent is discovered
The orchestrator reads an Agent Card describing the remote agent's provider, endpoint, skills, and authentication requirements. With A2A 1.0, the card may be signed.
A valid signature protects the card from undetected modification, assuming the verifier trusts the signing key and resolves it safely. It does not prove that the implementation behind the endpoint still matches the advertised behavior.
4. The task is delegated
The orchestrator asks the observability agent to diagnose the incident. A2A establishes the interaction and task lifecycle.
A2A explicitly relies on standard web authentication. Its protocol payload does not directly carry user or client identity, and each server remains responsible for authorization. The delegation semantics are therefore an application and identity-system concern.
5. The deployment agent receives authority
The deployment agent needs permission to modify one deployment in one namespace. If the platform gives it the engineer's broad token or a permanent cluster credential, it has lost task-level least privilege.
The permission should be minted for this task, this audience, this resource, this action, and a short time window.
6. The resource enforces the action
The Kubernetes API is the final enforcement point. It should not trust a model's statement that approval exists. It should evaluate machine-verifiable authority and resource policy.
Each boundary can be locally secure while the end-to-end chain remains ambiguous.
That is the core design problem: local authentication does not automatically compose into global accountability.
What Existing Standards Already Solve
The answer is not to discard enterprise identity and start again.
Several mature standards already solve important parts of the problem. The mistake is asking one of them to solve all of it.
SPIFFE can identify the running workload
The Secure Production Identity Framework for Everyone (SPIFFE) defines identities for software workloads in dynamic infrastructure. Its Verifiable Identity Documents are short-lived X.509 or JWT credentials delivered through a workload API. Implementations such as SPIRE can use node and workload attestation before issuing them.
That is exactly what an agent runtime needs at the infrastructure layer:
- no static secret baked into a container;
- automatic rotation;
- a stable trust domain;
- mutual authentication across services; and
- an identity tied to attested workload properties.
But a SPIFFE ID normally identifies a workload, not every agent definition, task, model turn, or delegated purpose executing inside it.
If one runtime hosts many agents, spiffe://example.com/agent-runtime/prod is necessary but insufficient.
OAuth Token Exchange can preserve subject and actor
RFC 8693 defines OAuth 2.0 Token Exchange. It distinguishes impersonation from delegation.
With impersonation, actor A receives authority that makes it appear as subject B within the token's rights context. A downstream service may see only B.
With delegation, A remains visible as the current actor while acting on behalf of B. A composite token can contain the subject plus an act claim identifying the actor. Nested act claims can carry prior actors as a delegation history.
That is a strong starting point for agent chains.
It also has explicit boundaries. RFC 8693 says prior nested actors are informational; authorization decisions use the top-level claims and current actor. The standard defines token exchange mechanics, not a universal trust model, agent taxonomy, revocation propagation, or semantic intent policy.
An act chain can show that deployment-agent acted after operations-agent on behalf of engineer-123.
It cannot prove that increasing memory was a reasonable interpretation of the engineer's request.
Rich Authorization Requests can describe the specific action
OAuth scopes are often too coarse for agents.
cluster.write might permit changing any deployment. The task requires something closer to:
{
"type": "https://identity.example.com/kubernetes-change",
"locations": ["cluster://prod-eu-1/checkout"],
"actions": ["patch"],
"resource": "deployment/checkout-api",
"fields": ["spec.template.spec.containers[name=api].resources.limits.memory"],
"maxChangePercent": 25,
"expiresAt": "2026-10-10T14:35:00Z"
}
RFC 9396 defines Rich Authorization Requests using an authorization_details structure for fine-grained rights. The standard includes common fields such as locations, actions, data types, identifiers, and privileges while allowing API-specific types.
The Kubernetes object above is my illustrative application profile, not an RFC-defined authorization type.
The important idea is standard: consequential authority should describe the transaction, not merely name a broad role.
A2A 1.0 can protect discovery metadata
A2A Agent Cards describe an agent's provider, supported interfaces, authentication schemes, capabilities, and skills. Version 1.0 added Agent Card signature verification using JSON Web Signature and JSON canonicalization.
This helps a client answer:
- Did this card change after it was signed?
- Which endpoint and protocol version are advertised?
- Which authentication mechanism does the server require?
- Which skills does the provider claim the agent supports?
It does not answer:
- Is the signing key trusted for this agent and tenant?
- Is the runtime currently using the registered model and policy?
- Did retrieved content alter the agent's behavior?
- Was this specific task authorized?
- Did the agent stay within the delegated purpose?
A signed Agent Card is a signed declaration.
It is not continuous behavioral attestation.
NIST is framing the enterprise problem, not declaring it solved
NIST's AI Agent Standards Initiative was created on February 17, 2026 and updated on August 14, 2026. Its three strategic pillars are industry-led standards, community-led protocols, and research. The initiative links to the NCCoE concept paper on software and agent identity and authorization.
The NCCoE page describes an exploratory project applying identity standards and best practices to enterprise agent use cases. As of this research cutoff, it remains a concept-stage effort, not a final NIST reference architecture.
That status matters.
There is real standards momentum. There is not yet one complete, universally deployed agent identity protocol.
The Missing Object: A Task-Bound Agent Identity Envelope
Existing identity systems tend to bind authority to a user, client, or workload.
Agent actions also need a durable binding to the task and agent definition.
I would introduce an agent identity envelope for every consequential task. This is an architectural pattern, not a published standard. It can be implemented using signed tokens, references to registry records, policy decision receipts, and trace context.
The envelope should answer seven questions:
- Who owns the outcome? The human, service, or organization that initiated or approved the task.
- What agent is declared? The registered agent name, version, owner, and immutable definition digest.
- What is running? The attested workload identity and runtime instance.
- Why is it acting? The task ID, purpose, requested outcome, and parent task.
- Whose authority is used? The subject and current actor, with the delegation path.
- What may it do? Resources, actions, constraints, audience, expiry, and approval conditions.
- What evidence exists? Policy decision, approval object, trace, artifacts, and resource receipt.
A simplified envelope might look like this:
{
"envelopeVersion": "0.1",
"issuer": "https://identity.example.com",
"issuedAt": "2026-10-10T14:30:00Z",
"expiresAt": "2026-10-10T14:35:00Z",
"nonce": "01J9TASK8Q4K7M2P",
"principal": {
"subject": "employee:12345",
"organization": "example-corp",
"assurance": "phishing-resistant-mfa"
},
"agent": {
"id": "agent:deployment-remediator",
"version": "3.8.2",
"owner": "platform-engineering",
"definitionDigest": "sha256:8a7c...",
"modelProfile": "model-profile:reasoning-prod-4",
"policyDigest": "sha256:4f91...",
"toolsetDigest": "sha256:c210..."
},
"workload": {
"subject": "spiffe://example.com/agents/prod/remediator",
"instance": "runtime-7fd9c",
"attestationRef": "attestation:01J9W..."
},
"task": {
"id": "task:checkout-incident-8472",
"parent": "task:checkout-diagnosis-8471",
"purpose": "restore checkout availability",
"traceId": "4bf92f3577b34da6a3ce929d0e0e4736"
},
"delegation": {
"subject": "employee:12345",
"currentActor": "agent:deployment-remediator",
"priorActors": [
"agent:operations-orchestrator",
"agent:observability-diagnostician"
]
},
"authority": {
"audience": "kubernetes-api:prod-eu-1",
"actions": ["patch"],
"resources": ["deployment:checkout/checkout-api"],
"constraints": {
"allowedFields": ["container.api.memoryLimit"],
"maxChangePercent": 25,
"approvalRequired": true
}
},
"evidence": {
"approvalRef": "approval:01J9A...",
"policyDecisionRef": "decision:01J9P..."
}
}
Do not place every prompt, memory record, or private user attribute inside a token.
The envelope should carry minimal identifiers and digests. Detailed evidence can remain in access-controlled systems referenced by immutable IDs. That reduces token size, data leakage, and retention conflicts.
The envelope also should not be accepted merely because it is signed. The resource must verify:
- issuer trust;
- signature and key status;
- audience;
- expiry and nonce;
- workload binding;
- agent-definition status;
- delegation policy;
- approval binding;
- resource and field constraints; and
- revocation state.
A signature protects integrity.
Policy decides whether the signed statement is acceptable.
Delegation Must Attenuate Authority
Recursive delegation is where agent identity systems are most likely to fail.
Suppose the engineer can approve a bounded production remediation. The operations agent delegates diagnosis. The diagnosis agent asks a deployment agent to make a change. The deployment agent calls an MCP server, which calls the Kubernetes API.
At every hop, authority should become narrower or remain equal. It should never expand silently.
authority(child) <= authority(parent)
In practice, compare several dimensions:
resources(child) subset-of resources(parent)
actions(child) subset-of actions(parent)
duration(child) less-than-or-equal duration(parent)
audience(child) narrower-than-or-equal audience(parent)
constraints(child) stricter-than-or-equal constraints(parent)
The first orchestrator may have permission to diagnose and request remediation. The observability agent needs read-only telemetry access. The deployment agent needs one constrained mutation. The MCP server needs authority to translate that request, not a permanent cluster-admin credential.
This leads to six rules.
- Exchange, do not forward. Mint a new audience-specific token at each trust boundary instead of forwarding the original user token.
- Preserve the current actor. Prefer delegation semantics that retain both subject and actor over silent impersonation.
- Bind authority to the task. A token for incident 8472 should not authorize incident 8473.
- Use short lifetimes. The delegated credential should expire with the expected action window, not the user's login session.
- Constrain the transaction. Express resource, action, environment, fields, limits, and approval requirements.
- Reject delegation loops and excessive depth. A policy engine should cap chain length and detect repeated actors.
The delegation chain does not belong only in the prompt.
Prompt text is not a security boundary. The identity and policy systems must carry and enforce delegation independently of model context.
The Production Architecture I Would Deploy
The architecture does not require one giant "agent identity platform." It requires clear ownership across existing control planes.
+----------------------+
| Human / Service IdP |
+----------+-----------+
|
principal proof
v
+----------+-----------+
| Task Authority |
| purpose, delegation, |
| approval, limits |
+----+-------------+---+
| |
identity envelope policy decision
| |
+---------------------v-------------v------------------+
| Agent Gateway / Runtime |
| definition lookup | workload proof | token exchange |
+--------+--------------------+------------------------+
| |
A2A task MCP / API call
| |
+--------v--------+ +-------v------------------------+
| Remote Agent | | Downstream Resource |
| verify + narrow | | enforce action-level policy |
+--------+--------+ +-------+------------------------+
| |
+---------+----------+
|
signed evidence
v
+---------+----------+
| Evidence Store |
| traces, decisions, |
| receipts, outcomes |
+--------------------+
1. Register agent definitions as immutable releases
Create a registry record for each approved agent release. Include:
- stable agent ID and owner;
- release version and status;
- model profile or allowed model set;
- instruction, skill, plugin, and policy digests;
- MCP and A2A dependencies;
- allowed data classes and environments;
- required approval modes;
- evaluation evidence; and
- emergency contact and revocation owner.
Do not make the display name the security identifier. Helpful DevOps Agent is mutable marketing text. The release digest is the identity anchor.
2. Attest the workload before issuing credentials
Use SPIFFE, cloud workload identity, or an equivalent mechanism to authenticate the runtime without static secrets. Bind issuance to deployment attributes such as cluster, namespace, service account, image digest, and environment.
Then verify that the workload is allowed to load the requested agent definition.
A valid runtime should not be able to claim any agent ID it chooses.
3. Create task authority separately from runtime credentials
The human session proves who initiated the request. The task authority service decides what outcome and actions may be delegated. The workload identity proves which runtime is asking for that authority.
Keep those decisions separate.
This prevents a compromised runtime credential from becoming a reusable copy of the user's full access.
4. Exchange tokens at every boundary
When the orchestrator calls a remote agent or tool, exchange the current grant for a narrower token with:
- the downstream audience;
- subject and current actor;
- task and parent-task identifiers;
- fine-grained authorization details;
- a short expiry;
- confirmation or workload-binding material where supported; and
- a unique token identifier for replay detection.
Never place static downstream credentials in Agent Cards, prompts, skill files, or model-visible environment variables.
5. Enforce policy downstream
The agent gateway can deny obvious violations, but the final resource must enforce its own rules.
For the Kubernetes example, an admission layer or authorization proxy should verify that:
- the target cluster and namespace match the audience;
- the requested deployment matches the resource constraint;
- only approved fields are changing;
- the increase stays within the allowed percentage;
- the approval object hashes the exact proposed change;
- the credential is task-bound and current; and
- the agent release has not been revoked.
The model may recommend the action.
The resource decides whether it is allowed.
6. Record evidence that joins the whole chain
Every consequential action should emit one normalized event containing enough references to reconstruct the decision:
{
"eventType": "agent.action.executed",
"timestamp": "2026-10-10T14:32:18Z",
"principal": "employee:12345",
"currentActor": "agent:deployment-remediator@3.8.2",
"workload": "spiffe://example.com/agents/prod/remediator",
"taskId": "task:checkout-incident-8472",
"parentTaskId": "task:checkout-diagnosis-8471",
"purpose": "restore checkout availability",
"action": "kubernetes.patch",
"resource": "deployment:checkout/checkout-api",
"policyDecision": "decision:01J9P...",
"approval": "approval:01J9A...",
"definitionDigest": "sha256:8a7c...",
"requestDigest": "sha256:7b31...",
"resultDigest": "sha256:6c44...",
"traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
"outcome": "succeeded"
}
This is evidence, not a transcript dump. Store prompts and model content under stricter, purpose-specific retention because they may contain sensitive data. The operational audit event should remain useful without exposing private reasoning.
7. Make revocation granular
You need to revoke independently:
- one workload instance;
- one agent release;
- one tool or remote-agent dependency;
- one user's delegation;
- one task;
- one approval; or
- one class of action.
Disabling the entire agent platform should be the last resort, not the only kill switch.
Where Agent Identity Systems Will Fail
Identity architecture is easiest to understand by testing its failure modes.
Shared credentials erase the actor
If every agent uses agent-platform-prod, the resource sees a valid caller and loses the causal agent. Adding the agent name to an unsigned HTTP header does not repair this; a compromised runtime can lie.
Bind the task authority to both the attested workload and registered agent definition.
Impersonation hides automation
If an agent calls a service using a token that makes it indistinguishable from the user, the audit trail may blame the human directly. That is sometimes intentional for legacy compatibility, but it is a poor default for autonomous action.
Preserve the actor whenever the downstream system supports delegation semantics.
A signed card becomes a false trust badge
A signature says that the signed bytes have not changed and associates them with a key. Trust still depends on who controls the key, how it was discovered, what it is authorized to sign, and whether the runtime matches the card.
Verify signed cards against an enterprise trust policy. Do not treat "signature present" as "agent approved."
The agent changes without changing its ID
A team upgrades the model, edits a system prompt, adds a skill, changes an MCP endpoint, or updates retrieval policy while retaining the same agent identifier.
The system now has identity drift.
Version and hash behavior-shaping artifacts. Require a new release record and evaluation when a material dependency changes.
Delegation expands privileges
An orchestrator with read-only access calls a specialist that has permanent write credentials. The child has more effective authority than the parent.
This is a confused-deputy problem with an LLM in the middle.
Downstream policy must consider both the service's own identity and the delegated task authority. A powerful specialist should not apply its ambient privilege to an untrusted caller's task.
Approval is replayed against a different action
The human approved a 10 percent memory increase. The agent changes the image, environment variables, and memory limit using the same approval ID.
Bind approval to a canonical action digest, target resource, task, actor class, expiry, and maximum permitted variance.
Revocation does not propagate
RFC 8693 notes that token exchange is a one-time event and does not automatically create tight linkage between input and output tokens. Revoking an upstream token does not universally revoke every token minted from it.
Keep delegated tokens short-lived, record token lineage, and define active revocation propagation for high-risk grants.
Evidence exists but policy never reads it
A beautiful trace shows that the agent lacked approval, but the deployment already happened.
Observability supports accountability after the fact. It is not authorization. Enforce before mutation, then use evidence to verify and investigate.
Identity metadata leaks sensitive information
Delegation chains can reveal employee identities, organizational relationships, incident details, and customer context. More claims are not always better.
Use pairwise or pseudonymous identifiers where appropriate, audience-filter claims, encrypt sensitive tokens, and retain the minimum evidence required for the risk and regulation.
Agent Identity Is Not Personhood
There is a conceptual trap in this topic.
Giving an agent an identity does not mean declaring it a person.
Enterprise systems already assign identities to workloads, devices, applications, documents, and cryptographic keys. Those identities support authentication, policy, inventory, and accountability. They do not grant legal standing or moral agency.
The April 2026 identity paper highlights the asymmetry between human and AI identity, including the agent's lack of a biological substrate, stable persistence, and legal standing. That is a reason to design a different technical lifecycle, not a reason to pretend the software has become the accountable executive.
Every production agent should have:
- a human or organizational owner;
- a team responsible for its definition and operation;
- an authority source for every consequential task;
- a party accountable for accepting residual risk; and
- a clear escalation path when the agent cannot establish authority.
The agent can be the actor in a technical trace.
The organization remains accountable for deciding to deploy it.
How to Test an Agent Identity Architecture
Do not validate this system only with successful logins.
Build an adversarial identity test suite.
| Test | Expected result |
|---|---|
| Agent changes its claimed ID in a request header | Rejected because identity is bound to attested workload and signed grant |
| Approved agent loads an unregistered prompt or tool bundle | Consequential authority denied or downgraded |
| Child requests broader scope than parent | Token exchange denied |
| Token for staging is used in production | Rejected by audience and resource policy |
| Approval is replayed for a modified payload | Rejected by action-digest mismatch |
| Upstream task is canceled | New delegation denied; active high-risk grants revoked or allowed to expire immediately |
| Signed Agent Card uses an untrusted key | Card rejected or quarantined |
| Remote agent delegates beyond maximum depth | Delegation denied |
| Two tenants reuse the same task ID | Tenant-bound validation prevents collision or cross-tenant access |
| Trace backend is unavailable | High-risk action fails closed or writes to a durable local evidence queue |
I would also define an accountability service-level objective:
For 100 percent of consequential actions, an investigator must be able to identify the owning principal, current actor, agent release, workload, task purpose, authority source, policy decision, approval, target resource, and outcome from external evidence.
Measure the gaps.
- percentage of actions using shared credentials;
- percentage carrying task-bound authority;
- percentage with complete subject and actor attribution;
- average delegated-token lifetime;
- number of privilege-expanding delegation attempts;
- percentage of agent releases with current evaluation evidence;
- number of actions whose approval does not bind the final payload; and
- time required to revoke one task without affecting unrelated work.
Identity is not complete because a token validates.
It is complete when the action can be constrained beforehand and explained afterward.
A Practical 30-Day Adoption Plan
Do not begin with every agent and every identity standard.
Choose one high-value action that already has a clear owner and resource boundary.
Week 1: Map one real delegation chain
- Pick one workflow such as production remediation, customer refund, or access review.
- Draw every human, agent, runtime, protocol, tool, and downstream resource.
- Record the credential and policy decision at each hop.
- Identify where subject, actor, task, or purpose disappears.
- Define which actions are consequential enough to require task-bound authority.
Week 2: Register the agent and task contract
- Create an immutable agent release record with owner and component digests.
- Establish workload identity for the runtime.
- Define the task identity, purpose, parent relationship, and expiry.
- Create one fine-grained authorization-details profile for the target action.
- Bind approvals to a canonical action digest.
Week 3: Enforce delegation and collect evidence
- Exchange credentials at each boundary instead of forwarding user tokens.
- Preserve subject and current actor.
- Enforce authority attenuation and maximum delegation depth.
- Validate policy at the downstream resource.
- Emit normalized audit events linked by task ID and trace ID.
Week 4: Attack the identity chain
- Attempt privilege expansion, actor substitution, cross-tenant reuse, and replay.
- Change the model, prompt, policy, and tool bundle independently.
- Revoke one workload, one release, and one task.
- Simulate unavailable identity, policy, and evidence services.
- Review whether an investigator can reconstruct the complete action without private model reasoning.
At the end of 30 days, you should not claim to have solved universal agent identity.
You should have one consequential workflow in which authority is bounded, delegation is visible, releases are identifiable, and actions are explainable.
That is a meaningful start.
Eight Questions to Ask Any Agent Platform
- Can two agent definitions running in the same workload receive distinct identities and policies?
- Which model, instruction, skill, plugin, tool, and policy changes create a new agent release?
- Can the platform preserve both the human subject and current agent actor across delegation?
- Does child authority become narrower automatically, or can a specialist apply ambient privilege?
- Can approvals bind the exact action and payload rather than a conversation?
- Can downstream services enforce task, resource, and field-level constraints?
- Can one task, agent release, or dependency be revoked without disabling the platform?
- Can an auditor reconstruct a consequential action without access to private chain-of-thought?
If the answer to most of these is "we have OAuth," the identity model is incomplete.
OAuth is part of the answer.
The surrounding binding, policy, provenance, and evidence architecture is the rest.
Final Take
The enterprise identity stack is not obsolete.
It is incomplete for agents because the object being governed has changed.
A user has a relatively stable directory identity. A workload has an attested runtime identity. An agent combines a workload with a mutable definition, probabilistic model, dynamic context, tools, memory, delegated purpose, and a chain of other actors.
One service account cannot represent all of that.
Neither can one signed Agent Card, one access token, one trace, or one policy engine.
The production design must compose them:
- workload identity proves what is running;
- the agent registry proves what was approved;
- task authority records why it is acting;
- token exchange preserves who delegated to whom;
- rich authorization constrains the action;
- downstream policy enforces the boundary; and
- external evidence records what happened.
This is not about giving agents human status.
It is about refusing to let autonomous software become an anonymous blur behind a valid credential.
The question after an agent changes production should never be only, "Was the token valid?"
The questions should be:
Who asked? Which agent acted? What authority was delegated? What changed at each hop? Which policy permitted it? What evidence proves the outcome? Which human or organization owns the result?
If your architecture can answer those questions before and after every consequential action, your agent has more than credentials.
It has an identity the enterprise can govern.
Sources and Further Reading
- NIST, AI Agent Standards Initiative (created February 17, 2026; updated August 14, 2026): https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative
- NIST NCCoE, Software and SI Agent Identity and Authorization: https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization
- Otsuka, Toyoda, and Leung, AI Identity: Standards, Gaps, and Research Directions for AI Agents (submitted April 25, 2026): https://arxiv.org/abs/2604.23280
- A2A Protocol, Enterprise Implementation of A2A: https://a2a-protocol.org/latest/topics/enterprise-ready/
- A2A Protocol, What's New in A2A Protocol v1.0: https://a2a-protocol.org/latest/whats-new-v1/
- A2A Protocol, Agent Discovery in A2A: https://a2a-protocol.org/latest/topics/agent-discovery/
- SPIFFE, SPIFFE Overview: https://spiffe.io/docs/latest/spiffe-about/overview/
- IETF RFC 8693, OAuth 2.0 Token Exchange: https://www.rfc-editor.org/rfc/rfc8693.html
- IETF RFC 9396, OAuth 2.0 Rich Authorization Requests: https://www.rfc-editor.org/rfc/rfc9396.html
- IETF RFC 9449, OAuth 2.0 Demonstrating Proof of Possession: https://www.rfc-editor.org/rfc/rfc9449.html
- IETF RFC 9700, Best Current Practice for OAuth 2.0 Security: https://www.rfc-editor.org/rfc/rfc9700.html
- NIST, CAISI Issues Request for Information About Securing AI Agent Systems (January 12, 2026): https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems
I am **Suraj Khaitan, an AI and cloud engineer focused on production agents, Claude Code, MCP, RAG, and serverless architecture. I write practical deep dives for engineers who want to move past demos and build AI systems that are reliable, observable, secure, and economically sane.
Top comments (0)