Bearer tokens fail at agent scale without proof of possession

At a glance

What this is: This is an analysis of why bearer tokens break down in autonomous agent chains, with replay, logging, and token reuse identified as the core failure pattern.

Why it matters: It matters because IAM and PAM teams need access controls that survive machine-speed delegation, rather than assuming a bearer token is safe simply because it was issued legitimately.

Context

Bearer tokens are reusable credentials that confer access to whoever presents them, which makes them easy to forward, log, and replay once they move through agent chains. The article’s central governance gap is that possession-based access assumes a stable bearer, while autonomous agents can hand off credentials thousands of times per second.

In practice, that means the control problem is not just token theft. It is token propagation across multiple runtime entities with little or no accountability, where a single exposed token can remain valid long after the original agent has disappeared. That is an NHI governance failure, not just an application bug.

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 replayed bearer tokens create such a large security impact in agent systems?

A: Replay matters because an exposed bearer token can still satisfy server-side authentication even after the original handoff is over. In agent systems, that lets an attacker turn one leaked credential into repeated API calls, which can rapidly amplify access and abuse. The impact is multiplied because the token survives longer than the agent that used it.

Q: How should teams stop agents from reusing the same token across multiple hops?

A: The safest pattern is to exchange credentials at each hop and reduce scope every time. That means no forwarding of the original bearer token, no privilege carryover from one agent to the next, and no task that depends on a single reusable credential across the chain.

Q: What should IAM teams do when agent credentials can be logged or replayed?

A: They should treat logs, traces, and memory dumps as potential credential exfiltration points and remove bearer tokens from those paths. They should also validate that revocation, token binding, and delegation controls actually stop reuse after exposure, rather than assuming short-lived agents solve the problem on their own.

Technical breakdown

Why bearer tokens collapse in agent handoffs

Bearer tokens authenticate by possession alone. In human workflows that can be workable because the bearer is usually stable, visible, and accountable. In agent chains, the same token can move from one runtime entity to another, then into logs, memory dumps, or external services. Once that happens, the token becomes a reusable access artifact detached from the original execution context. Replay is then trivial because the server only checks whether the string is valid, not whether the requester is the original holder or the intended delegate.

Practical implication: treat any bearer token that can cross agent boundaries as replayable until proven otherwise.

How DPoP changes token validation

Demonstration of Proof-of-Possession binds a token to a cryptographic key held by the client, so the token alone is not enough. The server expects a proof tied to that key at request time, which means a stolen token without the private key should fail. That shifts the security model from simple bearer semantics to a bound credential model. For agent systems, this matters because the token can no longer be treated as a transferable asset that survives every hop unchanged.

Practical implication: use token binding where tokens may traverse automated or delegated runtime paths.

Why token exchange is safer than forwarding

Token exchange limits delegation by issuing a new token at each hop with reduced scope and a lifetime aligned to the task. Instead of forwarding the original credential, each agent receives only the permissions it needs for the next step. That creates a downhill permission flow, where privilege should shrink rather than persist. In agentic systems, this is the difference between carrying an admin-capable credential through the workflow and constraining each step to a narrower, task-specific entitlement.

Practical implication: replace forwarded bearer tokens with exchange-based delegation so privilege narrows at each agent boundary.

Threat narrative

Attacker objective: The attacker wants to reuse a single exposed token to impersonate the agent chain and extract repeated API access at scale.

1. Entry occurs when a bearer token is passed from one agent to another and then exposed through logs, memory, or an external service.
2. Credential access occurs when an attacker retrieves the exposed token from debugging output, indexed logs, or public paste and code repositories.
3. Lateral movement follows when the same token is replayed across APIs and chained agents, allowing repeated authorized calls at machine speed.
4. Impact appears as large-scale API abuse, with the attacker making thousands of requests before the compromise is detected.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 semantics are the wrong trust model for agentic delegation: bearer tokens assume the credential can travel without losing accountability, but agent chains turn that assumption into a liability. The token is no longer a proof of trusted possession when it can be copied through logs, memory, and service handoffs. The implication is that delegated access in agentic systems needs cryptographic binding, not portable trust.

Token forwarding creates an accountability void: when one credential is reused across multiple entities, no single actor owns the resulting access trail. That matters because incident analysis and governance both depend on being able to answer who had the credential, when it moved, and which hop expanded exposure. Practitioners should treat the shared-token chain as a governance anti-pattern, not just a technical convenience.

Ephemeral agents expose a longevity mismatch in access design: the article’s most important point is that the agent may die in milliseconds while the bearer token survives for much longer. Access review, offboarding, and revocation logic were designed for identities that persist long enough to be governed after issuance. When the credential outlives the actor, the lifecycle assumption has already failed.

DPoP and token exchange address two different failure modes: proof of possession prevents the token from being enough on its own, while exchange reduces what any hop can do if it is compromised. Those are not interchangeable controls. In agent scale systems, the right governance model combines binding with scope reduction, because either control alone leaves a gap in the delegation chain.

Identity blast radius becomes the key design variable: the article shows that one compromised handoff can multiply into thousands of calls because the same credential keeps traveling. That is the practical definition of blast radius in agentic identity. Security teams should judge delegation patterns by how far a stolen token can propagate, not by whether the initial issuance was legitimate.

What this signals

Identity blast radius is now a primary design concern: in agentic workflows, the security question is not whether a token was issued correctly, but how far it can travel before it is constrained or destroyed. Delegation chains that preserve the same credential across hops make compromise propagation the default outcome, not the exception.

Proof of possession changes the meaning of “valid access”: when a token must be paired with cryptographic proof, stolen strings stop being usable assets. That shifts governance away from assuming a bearer can be trusted and toward validating that the requester still controls the bound identity at request time.

For practitioners

• Bind delegated tokens to proof of possession Require cryptographic proof at request time for any token that may move across agent boundaries. Do not allow a bearer token to remain valid solely because it was copied intact.
• Replace token forwarding with exchange-based delegation Issue a fresh token at each hop with reduced scope and a lifetime that matches the task, so an upstream compromise cannot preserve broader access downstream.
• Stop logging live credentials in agent pipelines Strip bearer tokens from debug output, traces, memory dumps, and service logs before they can be indexed or replayed by an attacker.
• Test replay paths in a sandbox Simulate token theft, log exposure, and cross-agent reuse so teams can see where a stolen credential remains accepted and where binding or exchange blocks it.

Key takeaways

• Bearer tokens become materially weaker in autonomous agent chains because they can be forwarded, logged, and replayed across multiple runtime entities.
• A single exposed token can scale into repeated API abuse, which makes replay resistance a governance issue as much as a technical one.
• Token binding and scope reduction change the risk profile by preventing a copied credential from behaving like reusable access.

Key terms

• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• Proof-of-Possession: Proof-of-possession binds a token or credential to a specific key so possession of the token alone is not enough to use it. For AI agents, it reduces replay risk and helps ensure that an intercepted credential cannot be reused by a different actor.
• Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.