TL;DR: Bearer tokens and session-scoped API keys break down when the principal is an autonomous agent, because they create ambient authority and weak auditability across tool calls, according to Stacklok. The practical answer is workload identity plus relationship-based authorization, with per-request enforcement that proves who acted, what they touched, and under which policy.
At a glance
What this is: This article explains why bearer-token patterns fail for AI agents and why SPIFFE plus relationship-based authorisation is the correct identity and control model.
Why it matters: It matters because IAM teams need per-request proof of agent identity, delegated scope and auditability before AI agents are allowed into production systems.
Context
AI agent identity fails when teams assume a session token can safely represent a non-human actor across many tool calls. In practice, that assumption collapses once the agent can query databases, call APIs and delegate work to sub-agents inside the same runtime window.
The article is framed around a governance gap, not a model choice problem. Enterprise architecture reviews now have to answer what the agent may do, how that permission is evaluated at runtime and how the resulting actions are audited in a form compliance teams can use.
Key questions
Q: What breaks when bearer tokens are forwarded between AI agents?
A: Bearer tokens break down because possession alone becomes enough to reuse access. If one agent can forward a token to another component, the original authority can travel far beyond the intended session. That is why token binding matters: it turns a reusable credential into one that is only valid for the intended holder.
Q: Why do per-request checks matter more than session tokens for AI agents?
A: Per-request checks make each tool call the unit of authority, which is necessary when an agent can query databases, invoke APIs and delegate work mid-session. Session tokens assume stable human behaviour over time. Agents do not behave that way, so the control has to evaluate the current action, not the original login.
Q: What are the signs that agent access is too coarse to govern safely?
A: Common warning signs include shared credentials across multiple agents, audit logs that only show a session ID, sub-agents using the root agent's authority and policy checks that happen once at login instead of on each call. Those patterns show that the runtime has more power than the governance model can describe.
Q: How should teams compare SPIFFE-style workload identity with relationship-based authorisation?
A: SPIFFE-style identity answers who the workload is and whether that identity is verifiable at runtime. Relationship-based authorisation answers whether that verified identity may perform the specific action on the specific resource in the current context. Teams need both because identity proof without policy leaves authority too broad, while policy without identity leaves attribution too weak.
Technical breakdown
Why bearer tokens create ambient authority for AI agents
Bearer tokens, OAuth access tokens and session-start JWTs were built for human sessions that begin with authentication and then remain bounded. An autonomous agent changes the security meaning of the token because the same credential can be reused across multiple tool calls, tasks and delegated steps without a fresh policy decision. That produces ambient authority: the token authorises everything in scope regardless of the current reasoning step or business context. The failure is architectural, not cosmetic, because the credential no longer tracks the specific action being taken.
Practical implication: stop treating session tokens as sufficient authority for agent tool calls and move to per-request enforcement.
How SPIFFE binds workload identity to runtime context
SPIFFE provides workload identity through cryptographically verifiable SVIDs, short-lived credentials issued from a trust domain and tied to runtime attestation. That matters for AI agents because the identity becomes a property of the workload instance, not a secret stored in configuration. In an agent stack, each agent or MCP server can present its own identity, which reduces reliance on static secrets and makes delegation chains easier to attribute. SPIFFE solves identity proof, not permissioning, so it must sit alongside an authorisation layer.
Why relationship-based authorisation fits agent delegation chains
Relationship-based authorisation evaluates permissions through a graph of users, agents, delegated tasks and protected resources. That is a better fit than flat RBAC when an agent acts on behalf of a user, spawns a sub-agent or must obey contextual rules such as own-records-only access. The authorisation engine can inspect who delegated the task, which resource is targeted and what constraints apply before allowing the call. This is the control plane that turns agent identity into auditable, task-scoped authority.
Practical implication: encode delegation and resource relationships explicitly so each tool call is authorised in context rather than by coarse role assignment.
Threat narrative
Attacker objective: The objective is to perform actions with authority that exceeds the current task while leaving an audit trail that is too coarse for compliance to trust.
- Entry occurs through a valid bearer token, OAuth access token or API key issued at session start and then reused across agent tool calls.
- Credential abuse happens when the agent reuses that ambient authority across databases, internal APIs and MCP servers without a fresh per-call policy check.
- Impact appears as weak auditability and overbroad access, because the logs show a session rather than a specific authorised action chain.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Bearer-token authorisation is a human-session assumption, not an agent control model. The article correctly exposes the broken premise: a token issued at session start does not describe the next tool call, the next delegated sub-agent or the next policy context. That makes the control look valid while failing at the point where decisions are actually made. Practitioners need to stop mapping agent runtime behaviour onto human login patterns.
SPIFFE changes the identity question from possession to provenance. For workload-driven agents, the important issue is not whether a secret exists but whether the running workload can prove what it is and where it came from. That is the right identity primitive for non-human actors because it shifts authority from reusable credentials to attestable runtime identity. The practitioner conclusion is that AI agent identity should be workload-bound first and session-bound only as a fallback.
Relationship-based authorisation is the missing governance layer for delegated AI action. RBAC can say who belongs to a role, but it cannot naturally express who delegated which task to which sub-agent under which constraint. Agent governance needs relationship graphs because the authority is contextual and often transitive across workflows. The operational conclusion is that enterprise AI access must be modelled as delegated relationships, not static entitlements.
Audit coherence is now a control requirement, not a reporting bonus. The article highlights that compliance teams need to know which authorised principal took action on which resource under which policy. That requirement becomes non-negotiable once agents can touch payments, databases and internal APIs at runtime. The practitioner implication is simple: if the audit trail cannot resolve identity at the tool-call level, the access model is not production-ready.
Per-request enforcement is the named control shift this category now requires. The architecture described moves authorisation from the session boundary to the individual invocation boundary, which is where agent risk actually exists. That is the governance pivot for any organisation running AI agents in regulated environments. Teams should treat each tool call as the unit of authority, review and evidence.
From our research library:
- Half of companies using generative AI will deploy agentic AI by 2027, according to Deloitte's 2025 Technology Predictions.
- Read next: Agentic AI Identity Guide
What this signals
Per-request authority is becoming the baseline for agent governance. Once AI systems can touch databases and internal APIs directly, a session-scoped token is no longer a sufficient control boundary. Enterprise programmes should assume that the security decision has to happen at invocation time, not only at login time.
Delegation chains need identity evidence at every hop. When a root agent hands work to a sub-agent, the governance question is no longer just who started the workflow but which principal exercised authority on the last tool call. That makes delegated relationships and workload identity part of the same control problem, not separate ones.
For practitioners
- Define agent identity at the workload layer Use SPIFFE or an equivalent workload identity pattern so each agent instance can prove its runtime identity without relying on static secrets in configuration.
- Move authorisation to each tool invocation Require a policy decision before every MCP or API call so the agent cannot reuse broad session authority across unrelated tasks.
- Model delegation as relationships, not roles Encode user, agent, sub-agent and resource relationships explicitly so the policy engine can evaluate delegated scope and contextual constraints.
- Make audit trails resolve to the call level Capture the resolved agent identity, resource, tool name and policy decision for each invocation so compliance can reconstruct what happened.
Key takeaways
- AI agents do not fit human-session credential models because the same bearer token can cover many unrelated tool calls without fresh authorisation.
- SPIFFE and relationship-based authorisation address different layers of the problem, with one proving workload identity and the other constraining delegated action.
- Enterprises running agents in regulated systems need per-request identity, relationship-aware policy and call-level audit evidence before scale makes the gap harder to close.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agent identity, delegated authority and tool-call abuse. |
| Recommendation — Apply ASI03 to constrain agent identity scope and prevent privilege reuse across delegated actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Bearer tokens and session-start credentials fail to prove the right workload at runtime. |
| NHI-05 — Overprivileged NHI | The article shows how broad session authority becomes ambient power for agents. | |
| NHI-07 — Long-Lived Secrets | Static credentials in configuration are called out as a persistent risk for agents and MCP servers. | |
| Recommendation — Use NHI-04 controls to bind agent access to verifiable runtime identity rather than static session credentials. Scope NHI entitlements to the minimum tool and resource set each agent actually needs. Replace long-lived agent secrets with short-lived, attestable credentials that rotate automatically. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack pattern relies on reused tokens and broad access across internal resources. |
| Recommendation — Map agent token reuse to TA0006 and chained tool traversal to TA0008 when modelling abuse paths. | ||
Key terms
- Ambient authority: Access that exists because the surrounding environment already has permissions, rather than because the actor was explicitly granted them. In swarm systems, ambient authority hides who is truly acting and makes revocation, attribution, and containment much harder.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Purpose-based Authorisation: A policy model that checks why an action is being taken, not just who is taking it. In identity programmes, this matters when delegated systems or AI agents can act quickly and broadly, because consent and intent must be tied to a specific transaction rather than assumed from account ownership.
- Per-Request Enforcement: Per-request enforcement evaluates the access decision at the moment the action is made, using current context rather than a standing grant. For AI gateways, this matters because routing, delegation, and workflow state can all change between calls.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org