Who is accountable when an AI agent creates downstream identities or assumes scoped tokens?

Why This Matters for Security Teams

When an AI agent can create downstream identities or assume scoped tokens, the real question is not whether the action was automated, but who approved the autonomy and who can prove it later. Static RBAC is often too blunt for this problem because the agent’s behaviour is goal-driven, not pre-scripted. Current guidance suggests treating the control plane owner, the workflow owner, and the identity issuer as part of the accountability chain, especially where OWASP Agentic AI Top 10 risk patterns overlap with NIST AI Risk Management Framework governance expectations.

That matters because auditors do not accept “the agent did it” as an answer. They expect a traceable subject, purpose, approval path, and revocation path. NHI governance is therefore not only about the secret itself, but about who allowed the agent to mint, delegate, or consume that secret. The operational risk rises fast when a token can be reused across systems, when a downstream identity inherits broader privileges than the task required, or when logs cannot reconstruct the chain of delegation.

In practice, many security teams encounter accountability gaps only after a token has already been used outside the intended workflow, rather than through intentional delegation review.

How It Works in Practice

The workable model is to assign accountability in layers. The organisation that owns the control plane remains responsible for the policy, logging, and enforcement mechanics. The workflow owner remains responsible for the use case, including whether the agent should be allowed to request downstream identities at all. The service owner or resource owner remains responsible for the target system’s acceptance of the token or identity. That division is consistent with the direction of CSA MAESTRO agentic AI threat modeling framework and the NHI-focused guidance in OWASP Non-Human Identity Top 10.

Operationally, the strongest pattern is just-in-time credential issuance with workload identity, not long-lived shared secrets. The agent proves what it is at request time, then receives the minimum token needed for the minimum time needed. That token should be bound to a task, a purpose, and a short TTL, with automatic revocation when the task ends. Where possible, use policy-as-code and real-time authorization decisions so the system can check context such as tool, target, data sensitivity, and allowed action before the token is issued.

• Use workload identity as the base primitive, then layer scoped delegation on top.
• Log the originating request, approving policy, issued subject, and downstream resource touched.
• Separate approval for “can the agent act?” from “can the agent mint another identity?”
• Revoke on completion, not on a scheduled batch cycle.

This is the same reason incident write-ups such as the Salesloft OAuth token breach and Guide to the Secret Sprawl Challenge keep pointing back to weak credential lifecycle control, not just weak authentication. These controls tend to break down when agents chain tools across loosely governed SaaS apps because the delegation trail fragments across systems.

Common Variations and Edge Cases

Tighter delegation controls often increase operational overhead, requiring organisations to balance speed against auditability. That tradeoff is real, especially in environments where agents spin up short-lived service accounts, exchange tokens across clouds, or invoke MCP-connected tools with different trust domains. There is no universal standard for this yet, so best practice is evolving around intent-based authorization, short-lived secrets, and cryptographic workload identity rather than permanent entitlements.

One common edge case is the “brokered agent” pattern, where a central service mints identities on behalf of many downstream agents. In that model, accountability does not disappear into the broker. It shifts to the broker operator, the policy author, and the product owner who approved the delegated capability. Another edge case is the human-in-the-loop workflow: human review does not remove agent accountability if the agent prepared the request, selected the target, or executed the follow-on action after approval.

For teams mapping control intent to standards, the most relevant lens is still governance plus identity assurance. OWASP Top 10 for Agentic Applications 2026 and NIST AI Risk Management Framework both support the idea that autonomous systems need traceable decision points, not just access grants. Current guidance suggests that when the chain of delegation cannot be reconstructed, the organisation should treat the control as a governance failure even if the token itself was technically valid.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent exposes credentials or changes identity state?
• Who is accountable when an AI agent accesses the wrong data?
• Who is accountable when an AI agent performs an unauthorized action after injection?
• What is the difference between managed identities and hardcoded secrets for AI agents?