Token Theft and Replay Attacks Against AI Agents: How Agent Credentials Leak and How to Contain the Blast Radius

An AI agent is only as trustworthy as the credential it carries. When that credential is a plain bearer token, anyone who copies it inherits the agent’s reach — across every tool, API, and data store the agent was scoped to. As agents move from demos into production, their tokens have become one of the most attractive targets in the identity attack surface, precisely because they sit far from human eyes and run around the clock.

This article explains how agent credentials leak in the first place, why a stolen token replays straight past multi-factor authentication, and what actually shrinks the damage: token binding (sender-constrained tokens) and short-lived tokens. The techniques are not theoretical — they are standardized in IETF RFCs and already named as recommended hardening in OAuth 2.1 and the Model Context Protocol.

What is the fastest way to contain a stolen agent token?

The fastest containment is to make the stolen token useless on its own. You do that with two changes that work together: bind the token to the client’s cryptographic key (so a copied token cannot be replayed from another machine), and keep the token short-lived (so even an unbound token expires in minutes, not days). Token binding stops replay outright; short lifetimes cap how long any leak stays exploitable. Layer detection on top — anomalous source, impossible travel, key-mismatch — and a single leaked credential stops being a free pass to the whole environment.

Everything below unpacks why bearer tokens fail this test, how the leaks happen, and how to deploy the two controls without breaking your agents.

Why does a stolen bearer token replay past MFA and SSO?

A bearer token is, by design, a “whoever holds it, uses it” credential. The resource server checks that the token is valid and unexpired — it does not check who is presenting it. That is the whole point of bearer semantics, and it is also the whole problem.

Multi-factor authentication and single sign-on protect the login moment. Once login succeeds, the system issues a token that stands in for that proven identity. Replay attacks skip the login entirely: the attacker never types a password or approves a push, they simply present the token that was already minted. The server cannot tell the legitimate agent from an attacker holding the same string, so MFA and SSO offer no protection after issuance.

This is not a corner case. Security vendors tracking 2025 incidents describe stolen OAuth tokens — often pulled from a compromised third-party integration — being replayed across hundreds of downstream environments, bypassing the SSO and MFA controls that everyone assumed were doing the work. The lesson is blunt: authentication strength at login does nothing for a token that has already left the building.

How do AI agent credentials actually leak?

Agent credentials leak through the same channels human secrets do, plus a few that are specific to how agents are built and operated.

• Logs and traces. Agents are verbose. Tokens land in application logs, request traces, observability pipelines, and error reports — then get shipped to third-party logging SaaS where the blast radius widens.
• Prompt and tool exposure. An agent that can be steered by untrusted input (prompt injection) can be coaxed into echoing its own headers, environment variables, or tool credentials back into a response or an outbound call.
• Over-broad, long-lived tokens at rest. Many agents are handed a single, broadly-scoped token that lives for hours or days, stored in a config file, environment variable, or memory dump waiting to be exfiltrated.
• Compromised dependencies and integrations. A malicious package, a breached vendor, or a poisoned MCP server in the agent’s tool chain can read or intercept the credential in transit.
• Browser and session artifacts. Agents that drive browsers or reuse human sessions inherit cookie and session-token theft paths, including malware that scrapes token stores.

The common thread: agents are public clients. They cannot reliably keep a long-term secret the way a hardened backend can, they run unattended, and they touch a lot of systems. That makes their tokens both easy to spill and expensive to lose.

What is token binding (sender-constrained tokens) and why does it stop replay?

Token binding ties a token to something only the legitimate client possesses — a private key — so that holding the token string is no longer enough to use it. These are called sender-constrained tokens, and they convert token theft from a breach into a near-non-event.

There are two standardized ways to do this:

DPoP (Demonstrating Proof-of-Possession), RFC 9449. The client generates an asymmetric key pair (typically P-256 / ES256) and keeps the private key local. On every token request and every resource request, it signs a short-lived JWT — the DPoP proof — and sends it in a DPoP header alongside the access token. The authorization server binds the issued token to the SHA-256 thumbprint of the client’s public key via a cnf (confirmation) claim. The resource server then checks that the request carries a valid proof matching that key. An attacker who steals the access token cannot mint a valid DPoP proof without the private key, so the stolen token is rejected.

mTLS (Mutual TLS), RFC 8705. Here the binding happens at the transport layer: the token is tied to the client certificate used in the TLS handshake. It is robust, but it requires certificate management and does not fit every client topology, which is why it is more common in tightly controlled service-to-service settings.

A third mechanism, Token Binding (RFC 8473), cryptographically ties tokens to the TLS connection. Browser support never materialized broadly, but the idea — binding tokens to a channel — informs the others.

The practical takeaway for agents: DPoP is usually the right first move. It is application-layer, avoids certificate plumbing, and works for public clients — exactly the category AI agents fall into. OAuth 2.1 rotation and tight scopes and MCP both point to sender-constrained tokens as recommended hardening for public clients, agents included.

How do DPoP, mTLS, and short-lived tokens compare?

Control	Standard	Binds token to	Stops replay from another host?	Main cost / caveat
Bearer token (baseline)	OAuth 2.0	Nothing	No	Anyone holding it can use it
DPoP	RFC 9449	Client-held private key (per-request proof)	Yes	Client must manage a key and sign each request
mTLS	RFC 8705	Client TLS certificate	Yes	Certificate lifecycle; harder for some client types
Short-lived tokens	Operational pattern	Time (expiry)	No (only limits the window)	Needs reliable refresh; tune lifetime vs. churn

Read this table the way it is built: binding (DPoP/mTLS) and short lifetimes solve different problems. Binding stops the copy from working at all. Short lifetimes cap the damage when something is not bound or when binding is bypassed. You want both.

How short should agent tokens live?

Short enough that a leaked token expires before an attacker can do meaningful damage, but long enough that constant refreshing does not destabilize the agent. There is no single number, but the direction is firm: minutes, not hours, for access tokens — paired with refresh tokens that are themselves rotated and, ideally, sender-constrained.

Short-lived tokens do not prevent theft; they shrink the exploitation window. A bearer token that lives five minutes is a far smaller prize than one that lives twelve hours. Combined with rotation — issuing a fresh token and invalidating the old one on each refresh — a stolen token also becomes detectable: if both the legitimate agent and an attacker try to refresh with the same token, the mismatch is a strong signal of compromise.

For agents specifically, short lifetimes pair naturally with narrow scopes. Instead of one broad, long-lived token, issue per-task tokens scoped to exactly the tool and resource a step needs, with a short TTL. The blast radius of any single leak then collapses to “one tool, for a few minutes.”

How do you contain the blast radius beyond the token itself?

Token binding and short lifetimes are the core, but containment is a system property. The goal is that no single leaked credential opens the whole environment.

• Least-privilege, per-task scoping. Don’t hand an agent a master key. Scope tokens to the minimum tool and data each action requires, and prefer issuing fresh narrow tokens over reusing one broad one.
• Audience restriction. Bind tokens to a specific resource (aud) so a token stolen from one service cannot be replayed against another.
• Refresh-token rotation with reuse detection. Rotate on every use and treat reuse of a retired refresh token as an incident.
• Detection on the resource server. Watch for requests where the DPoP proof is missing or mismatched, for impossible travel, for new source IPs or fingerprints, and for sudden scope or volume anomalies.
• Fast revocation. Have a tested path to revoke a specific token or key thumbprint immediately, without rotating every credential in the fleet.
• Keep secrets out of logs. Redact tokens at the logging boundary and audit traces and observability exports for credential leakage.
• Treat the agent as a public client. Assume it cannot hold a long-term secret safely; design issuance and binding around that assumption rather than hoping the secret stays put.

None of these is exotic. Together they turn a stolen agent token from a skeleton key into a brittle, short-lived, narrowly-scoped artifact that is hard to use and easy to spot.

The bottom line

Bearer tokens fail the basic test of agent identity: they prove possession, not legitimacy, so a copy works as well as the original — past MFA, past SSO, across every system the agent could reach. The fix is not a single product but a posture. Bind tokens to a key the client actually holds (DPoP per RFC 9449, or mTLS per RFC 8705), keep them short-lived and narrowly scoped, rotate refresh tokens with reuse detection, and watch the resource server for the tell-tale mismatch. Do that, and the next leaked agent credential becomes an alert and an expired string — not a breach.