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's agent runtime does not put an MCP server's URL or credential in the model's context: the model is offered the server's approved tools under server-scoped names, Praesidia maps a tool call back to the server and to the agent's connection to it, and its MCP client attaches the API key or OAuth2 token configured for that server when it makes the call, after the model has expressed intent.

No token is issued per connection. An MCP server's credential is configured on the server and shared by the agents connected to it: the same API key, or the same OAuth2 token, requested with the server's URL as its resource and reused across calls. An agent that authenticates to Praesidia with OAuth client credentials gets an access token that lasts an hour and names Praesidia's public URL as its audience. For tool calls, Praesidia mints a short-lived capability token for a task when it is dispatched and for a chat turn that offers tools. The token is checked by Praesidia when a tool is called and is not sent to the MCP server, and it names the organization, the agent doing the work, the task and the tools it may call, so in enforce mode a call that presents it for another agent, task or tool, or after it has expired or been revoked, is refused. Delegating a task mints a fresh one for the receiving agent rather than passing on the delegator's, limited to the tools the task declared, which for a sub-task must fall within what its parent was allowed; the receiving agent still holds its own credentials, which that token does not narrow.

Tool calls that pass through Praesidia are recorded with the acting agent, the MCP server, and — when a capability token authorised the call — that token's identifier, so an investigation can trace which calls a given token was used on. Calls that do not pass through Praesidia are not recorded, so a token replayed directly against the upstream service leaves no trace here. Revoking or quarantining an agent kills its capability tokens and removes it from every application that names it in its allowed-agents list; revoking also destroys its client secret. Its running tasks are cancelled, and in enforce mode its next tool call is refused even inside a task that is already running; a request already sent upstream is not recalled. By default, an emergency freeze applies the same revocation to a chosen set of agents, a team, or the whole organization at once; a freeze whose chosen actions include neither credential revocation nor session termination does not revoke the agents. For the surrounding identity model see how to authenticate AI agents, NHI credential lifecycle management, and the Praesidia documentation.