Human session hijacking has well-known defenses: short sessions, device binding, re-authentication for sensitive actions, MFA. Agent sessions have none of those instincts applied to them, and the exposure is larger. Agent credentials are held by software, embedded in configuration, passed between services, and — uniquely — sometimes present in the same context window as untrusted content.

The core problem is that most agent authentication is bearer-token based. A bearer token authorizes whoever presents it. There is no proof of possession, no binding to a machine, no second factor. If it leaks, it is a working credential until it expires or is revoked.

Where Agent Tokens Actually Leak

Into model context. The highest-risk path and the one with no human equivalent. If a token appears in a system prompt, a tool definition, a tool response, or an error message that lands in context, the model can emit it — into a response, a log line, a tool argument, or a downstream agent's message. An attacker who can prompt the agent can attempt extraction, and this is a documented, repeatable class of failure. Credentials should never enter the context window; the proxy or gateway should attach them out of band, after the model has produced its intent. See system prompt extraction.

Into logs and traces. Authorization headers captured by an over-broad HTTP logger, tokens in URL query strings recorded by an access log, full request bodies in a tracing span. Observability pipelines fan out widely — to a SIEM, a vendor, a dashboard — so one leak has many readers. See observability for AI agents for the scrubbing side.

Into inter-agent messages. An orchestrator passing its own credential to a sub-agent so the sub-agent can "act on its behalf" is credential sharing, and it destroys attribution along with confidentiality. Delegation should mint a narrower token, not forward the broad one.

Into source and configuration. Committed .env files, container images, CI variables printed in build output, Kubernetes manifests in a public repo. Ordinary secret hygiene, but agent deployments proliferate credentials faster than review catches up. See secrets management for AI agents.

Through SSRF. An agent induced to fetch a URL that returns its own credentials, or to reach a cloud metadata endpoint and return instance credentials. See SSRF risks in agent tool calls.

What Replay Buys an Attacker

With a valid token, the attacker inherits the agent's authority — every connection scope it holds, at the volume and speed the agent is permitted. Because the traffic authenticates correctly and comes from an identity that legitimately makes many calls, it blends into normal activity. Anomaly detection tuned to human patterns will not notice; agents already act at machine speed and odd hours.

Two secondary effects matter. Attribution collapses: your audit trail records the agent, which is now indistinguishable from the attacker, so the incident timeline cannot separate legitimate from illegitimate work. And blast radius equals the agent's full scope, which is why over-broad scope and weak token binding compound each other — see threat model: agent credential theft.

The Controls That Actually Break Replay

Audience restriction. A token minted for a specific service is rejected everywhere else. This alone converts a stolen token from a universal key into a key for one door. It requires that every downstream service validate the aud claim, which is the step commonly skipped.

Short lifetimes with refresh. Access tokens measured in minutes, not days, with a refresh mechanism held outside the request path. The refresh credential can be protected more heavily precisely because it is used rarely. Long-running tasks are the usual objection, and the answer is that task continuity should come from a task identity that can refresh, rather than from a token that lives as long as the task.

Sender-constrained tokens. The strongest available control: the token is cryptographically bound to a key the legitimate holder possesses, so presenting it requires proving possession of that key. Two standard mechanisms — mutual TLS with certificate-bound tokens (RFC 8705), and DPoP (RFC 9449), where the client signs each request with a key whose thumbprint is in the token. A stolen sender-constrained token is useless without the private key. DPoP is the more deployable of the two for agents that speak plain HTTPS; mTLS fits service-mesh deployments where workload certificates already exist. See mTLS, SPIFFE, and workload identity for agents.

Per-request nonce and timestamp checks. For high-value operations, a signed request with a nonce the server tracks prevents exact-message replay even if the credential is valid. Adds state, so reserve it for consequential calls.

Token exchange rather than forwarding. When an agent delegates, it exchanges its token for a narrower, differently-audienced one. The sub-agent never holds the broad credential, and delegation depth is bounded. See token exchange for agent-to-tool authorization.

Fast revocation. Short lifetimes make revocation less urgent but do not replace it. You need a control that invalidates a specific agent's active credentials immediately, taking effect on in-flight requests — which for stateless JWT validation means a checked denylist or a per-agent key version incorporated into validation. See rogue AI agents and kill switches.

Detecting Replay

Replay looks like legitimate use, so detection depends on context that a token alone does not carry. Record, per call: the token identifier (jti or key id — never the token itself), the source address, the connection used, the asserted principal, and the client characteristics. Then look for:

  • The same token identifier presented from two distinct sources, especially concurrently.
  • A token used against an audience or connection that this agent has never used before.
  • Call rate or pattern departing sharply from the agent's baseline — agents are far more predictable than humans, which makes baselining unusually effective here.
  • Scope usage widening: an agent that has only ever exercised two of its five scopes suddenly using the rest.
  • Geographic or network-path change for an agent with a fixed deployment footprint.

The last point is worth emphasizing because it is the inverse of the human case. Humans travel; a deployed agent does not. An agent identity whose traffic origin changes is a strong signal, and it is cheap to alert on.

Common questions

Are API keys or short-lived JWTs better for agents?

Short-lived JWTs, provided the audience claim is validated. A long-lived API key is a bearer credential with no expiry, no audience, and usually no binding — everything replay needs. Where API keys are unavoidable for compatibility, compensate: scope each key to one purpose and one destination, rotate on a schedule, restrict source addresses, and record key usage per call so anomalies are visible. See organization API keys and scopes.

How do long-running agent tasks survive short token lifetimes?

Separate the task identity from the access token. The task holds a durable identity and a refresh capability; the access tokens it obtains are short-lived and audience-restricted, refreshed as the task proceeds. This also gives you a clean revocation point: killing the task identity stops future refreshes, so the task cannot continue past its next token expiry even if a current token is in flight.

Does DPoP work when the agent runs in a serverless or ephemeral environment?

Yes, but key management needs thought. The proof key can be generated per instance at startup and never persisted — the token is bound to that instance for its lifetime, which is exactly the property you want. The cost is that tokens do not survive instance replacement, so the agent must re-authenticate on cold start. For most agent workloads that is acceptable and arguably desirable.

Should the model ever see any credential?

No. There is no configuration in which putting a usable credential in a context window is safer than attaching it at the proxy after the model has decided what to do. The model needs to know that a capability exists; it does not need the secret that exercises it. Systems that pass credentials through the prompt are one extraction away from compromise, and extraction techniques improve faster than model refusals do.

How Praesidia approaches session integrity

Praesidia keeps credentials out of the model's context entirely: the agent expresses intent, and the governed connection attaches the credential at the proxy boundary. Tokens are short-lived and audience-restricted per connection, and delegation issues fresh task-scoped credentials, so a sub-agent never holds a broader credential than its task requires.

Every call records the acting agent, the asserted principal, the connection, and the credential identifier — which is what makes the same-token-from-two-sources signal detectable. Revocation takes effect on in-flight requests, and an agent or agent class can be halted immediately. For the surrounding identity model see how to authenticate AI agents, NHI credential lifecycle management, and the Praesidia documentation.