Four layers of AI agent identity still leave authorization unresolved

At a glance

What this is: This analysis breaks AI agent identity into four stacked layers and concludes that identity proof still does not prove whether an agent’s actions were appropriate.

Why it matters: IAM and security teams need to separate identity verification from delegated authority and behavioral control, or they will mistake authentication plumbing for governance.

Context

AI agent identity is the problem of proving which software actor is operating, which workload it belongs to, and what authority it has been delegated. The article argues that enterprises should stop treating this as one blob and instead separate the layers that make identity legible from the controls that make actions acceptable.

The governance gap is that traditional IAM was built for human login flows and predictable application calls. AI agents decide in the moment, act on behalf of a human who may not be watching, and may chain work to other agents, which means identity proof alone does not answer whether the action should be allowed.

The article’s model aligns with AI agent identity discussions that combine workload proof, delegation and service discovery, but it also shows where those discussions stop short: the moment a valid agent token is used to justify the wrong decision.

Key questions

Q: How should security teams govern AI systems that can act without human approval?

A: Security teams should govern autonomous AI the same way they govern other high-risk identities, but with runtime enforcement instead of periodic review. That means tightly scoping tools, data, and actions; logging every material step; and making revocation and containment available while the session is still active. Static policy alone does not control machine-paced execution.

Q: Why is proving an AI agent’s identity not enough to approve its actions?

A: Because identity proof answers who is acting, not whether the action is justified. A signed token and attested workload can confirm the agent’s origin, but they do not assess intent, prompt manipulation or policy fit. Practitioners need a second control layer for authorisation and behavioral review, especially when agents can act without a human watching each step.

Q: What breaks when AI assistants borrow human sessions or tokens?

A: What breaks is attribution. When an assistant operates inside a human session, activity may be legitimate but still hard to separate from the employee’s own actions. That creates audit ambiguity, weakens accountability, and can let sensitive actions disappear inside ordinary user behaviour unless session monitoring and approval rules are explicit.

Q: Why do AI agents need separate governance for workload identity and delegated user access?

A: Because the agent is not the user, and the user is not the process. Workload identity proves which runtime is acting, while delegated credentials represent whose authority it is using. If those are merged, revocation, auditing, and scope control become ambiguous, especially when the agent calls external services on the user's behalf.

Technical breakdown

Layer 1: signed token format and proof of integrity

The lowest layer is the token itself. A tamper-proof signed format, such as a JWT verified against a JWKS, proves that the credential has not been altered in transit and that the issuer’s public key matches the signature. This is necessary, but it is only document integrity, not identity trust in the broader sense. If the token format is forged or unverifiable, every higher layer inherits a broken foundation. In practice, this layer is about making sure the credential can be trusted as an object before anyone trusts the workload or the delegation chain behind it.

Practical implication: treat token integrity as the base requirement, not the control that makes an agent trustworthy.

Layer 2: workload identity proves which process is running

The second layer binds the agent to the workload that is actually executing it. The article points to SPIFFE and SPIRE as the pattern for giving a running workload a short-lived, attested identity so the system does not depend on a shared password or long-lived secret. This matters because it answers a narrower question than many teams assume: not whether the agent is reasoning correctly, but whether the expected software is what is currently running. That distinction is critical for machine identity governance, where the authenticity of the workload is separate from the legitimacy of its decisions. See the Agentic AI Identity Guide.

Practical implication: anchor agent identity in workload attestation, not in reusable secrets stored beside the code.

Layer 3: delegation preserves the human as the subject

The third layer is delegation, not impersonation. The article’s core point is that an agent should act for a human without becoming that human, and each hop in the chain should remain visible as a named actor. OAuth Token Exchange and actor-chain claims are the pattern that keep the subject and the actor distinct across multiple agents and tools. This is where many identity models fail, because the shortcut of borrowing the user’s token collapses accountability into a single credential. Once that happens, the audit trail says the person did the work even when a machine made the decision path. See the AI Agent Authorisation Guide.

Practical implication: preserve actor chains so accountability survives multi-agent delegation.

NHI Mgmt Group analysis

Identity proof and authorization are no longer the same control problem: The article’s central insight is that a complete agent identity stack can still leave the wrong action untouched. That is a structural governance issue, not a missing feature. Once the token, workload and delegation chain are sound, the remaining question is behavioral legitimacy, which sits outside identity proof alone. Practitioners should stop treating identity completion as proof of safe action.

Delegation must remain visible all the way down the chain: The article is right to reject impersonation as the default pattern. Borrowed-user tokens may simplify implementation, but they erase the actor chain and collapse accountability into the human subject alone. That creates a false audit trail and a false trust model at the same time. The governance implication is that machine action must stay attributable across every hop, especially when agents hand work to other agents.

Delegation-chain accountability: Identity models that hide intermediate agents create a governance blind spot even when authentication is correct. The chain itself is part of the control surface, because every unseen handoff widens the space where an agent can be redirected without the human subject noticing. Practitioners should treat chained delegation as a first-class governance object, not an implementation detail.

Service discovery solves reachability, not trustworthiness: The top layer in the article is operationally useful, but it only answers how an agent reaches a service and registers itself. It does not decide whether the resulting call fits policy, context or intent. That separation matters because enterprises often conflate onboarding with authorisation. The result is a clean connection path wrapped around weak decision control, which is exactly where agent risk accumulates.

AI agent identity will become a packaging layer unless governance catches up: The article suggests that identity proofing for agents will soon be productised, while the harder problem remains what the agent did after authentication. That is the market signal practitioners should watch. Identity stacks will become easier to buy, but the governance burden shifts to policy, logging, review and decision provenance. The programme implication is clear: buy the plumbing, own the accountability model.

Read next: Agentic AI Identity Guide

What this signals

Agent identity will split into two programme tracks: One track is machine proof, the other is action governance. That split will matter more as vendors package the lower layers of identity into products while the approval problem remains inside the customer’s control plane. Organisations should prepare for a world where authentication looks solved before authorisation is even measurable.

A mature programme will stop asking whether an agent can log in and start asking whether the delegation path, workload attestation and policy boundary still line up at the moment of action. That is where identity governance becomes operational rather than theoretical.

The article’s most useful warning is that a clean agent token can still sit around a bad decision. Teams that build monitoring, review and revocation around the action itself will outpace those that stop at credential issuance.

For practitioners

• Define the agent as a distinct actor in every workflow Keep the human subject, the agent actor and any downstream sub-agent separate in logs, policy and incident review so delegated work remains attributable.
• Require workload attestation before issuing agent credentials Use attested workload identity as the gate for agent authentication so short-lived credentials are issued only to the expected runtime environment.
• Replace borrowed-user-token shortcuts with actor-chain delegation Preserve the full chain of who authorised the action and which agents handled it, rather than collapsing everything into the end user’s identity.
• Separate login success from action approval Treat successful service onboarding as only the entry condition and enforce a second decision point for whether the agent’s requested action matches policy and context.
• Pilot one governed agent lane end to end Choose a single high-value workflow, instrument every hop, remove standing credentials and require human review at the point where the outcome matters most.

Key takeaways

• AI agent identity is best understood as layered proof, but proof of identity still does not equal approval of action.
• The article’s strongest governance point is that delegation chains must remain visible or accountability collapses.
• Enterprises should separate authentication plumbing from behavioural authorisation if they want agent governance that survives real use.

Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · MCP Security Guide

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
• Workload Attestation: Workload attestation is the process of proving that a workload is running in an expected, trusted environment before granting access. It helps stop copied credentials from being treated as universally valid and is a core control for reducing impersonation risk.
• Actor Chain: An actor chain is the end-to-end record of who requested an action, which identity executed it, and which downstream tools or accounts were used. It is essential for attribution, approvals, and incident review when humans, agents, and tools all participate in one workflow.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.