When an AI agent acts on your behalf, the server sees an intermediary. The agent’s IP address, the agent’s TLS fingerprint, the agent’s user-agent string. The server loses visibility into who the actual user is, which breaks per-user authorization, rate limiting, and audit trails.
Cloudflare just published their approach to this identity problem. They call it Trusted Agent Delegation, and it solves the HTTP-layer plumbing required when millions of agents make requests for millions of users without exposing user credentials to the agent or forcing servers to trust a black box.
The Problem Space
Traditional authentication assumes a direct connection between user and server. The user presents credentials (session cookie, bearer token, client certificate), the server validates them, and authorization decisions follow.
Agents break this model. The user grants an agent permission to act on their behalf. The agent makes the HTTP request. The server sees only the agent. Three failure modes emerge:
- Lost identity: The server cannot distinguish requests from different users routed through the same agent.
- Overprivileged agents: The agent holds full user credentials and can act beyond the intended scope.
- No audit trail: Logs show agent activity but not which user authorized each action.
Cloudflare’s solution preserves user identity through the agent intermediary using a delegation token that the agent presents alongside its own identity.
Architecture: Delegation Token Flow
The system uses a three-party trust model: user, agent, and server. The user issues a delegation token that binds their identity to the agent’s identity for a specific scope and duration. The agent presents both its own credentials and the delegation token. The server validates both and enforces policy based on the user identity.
Token Issuance
- User authenticates to Cloudflare (OAuth, SAML, or existing session).
- User authorizes a specific agent to act on their behalf.
- Cloudflare issues a signed delegation token containing:
- User identity (email, user ID, or claims)
- Agent identity (client ID or public key fingerprint)
- Scope (which APIs or resources)
- Expiration timestamp
- Signature from Cloudflare’s private key
The token does not contain user credentials. It is a capability, not a secret.
Request Flow
When the agent makes a request on behalf of the user:
GET /api/documents HTTP/1.1
Host: example.com
Authorization: Bearer <agent_access_token>
X-Cloudflare-Delegation: <delegation_token>The server extracts both tokens. It validates the agent’s access token through normal OAuth or API key flows. It validates the delegation token by checking Cloudflare’s signature and ensuring the agent identity in the delegation token matches the agent identity in the access token.
If both validate, the server sees:
- Agent identity: Which agent made the request (for rate limiting, blocking, or logging).
- User identity: Which user authorized the request (for per-user authorization and audit).
The server applies authorization rules based on the user identity, not the agent identity. The agent cannot escalate privileges beyond what the user granted.
Trust Primitives
The system relies on three trust anchors:
| Primitive | Role | Failure Mode |
|---|---|---|
| Cloudflare signature | Proves delegation token authenticity | Compromised signing key allows forged tokens |
| Agent identity binding | Prevents token reuse by other agents | Weak agent authentication allows impersonation |
| Scope constraints | Limits agent capabilities | Overly broad scopes grant excessive access |
Cloudflare acts as the trusted third party. Servers trust Cloudflare to correctly identify users and issue valid delegation tokens. Agents trust Cloudflare to not leak user credentials. Users trust Cloudflare to enforce the scope they specified.
This introduces a centralization point. If Cloudflare’s signing key leaks, attackers can mint delegation tokens for any user and any agent. If Cloudflare’s user authentication is bypassed, attackers can issue tokens for victims. The system assumes Cloudflare operates a secure identity provider.
Server-Side Policy Configuration
Site operators configure agent access through Cloudflare’s dashboard or API. Policies specify:
- Allowed agents: Whitelist of agent client IDs or public keys.
- Blocked agents: Agents that are denied regardless of user authorization.
- Scope enforcement: Which API endpoints or resources each agent can access.
- Rate limits: Per-agent and per-user request quotas.
Cloudflare enforces these policies at the edge before requests reach the origin server. The origin can also enforce additional policies by inspecting the delegation token claims.
Example policy logic:
// Cloudflare Worker at the edge
export default {
async fetch(request, env) {
const delegation = request.headers.get('X-Cloudflare-Delegation');
if (!delegation) {
return new Response('Missing delegation token', { status: 401 });
}
const claims = await verifyDelegationToken(delegation, env.PUBLIC_KEY);
if (!claims) {
return new Response('Invalid delegation token', { status: 403 });
}
// Check agent allowlist
if (!env.ALLOWED_AGENTS.includes(claims.agent_id)) {
return new Response('Agent not authorized', { status: 403 });
}
// Check scope
const url = new URL(request.url);
if (!claims.scope.includes(url.pathname)) {
return new Response('Scope violation', { status: 403 });
}
// Forward request with user context
const modifiedRequest = new Request(request);
modifiedRequest.headers.set('X-User-ID', claims.user_id);
return fetch(modifiedRequest);
}
};The origin server receives the user ID in a header and applies normal authorization logic. It does not need to understand delegation tokens or agent identity.
Observability and Audit
Cloudflare logs every delegation token issuance and every request that uses a delegation token. Logs include:
- User identity
- Agent identity
- Timestamp
- Scope
- Request outcome (allowed, blocked, rate limited)
Site operators can query logs to answer:
- Which agents are accessing my site?
- Which users have authorized which agents?
- What actions did a specific agent perform on behalf of a specific user?
- Are there anomalous patterns (one agent acting for many users, or one user authorizing many agents)?
Users can view their own delegation history through Cloudflare’s dashboard. They can revoke delegation tokens at any time, which immediately blocks future requests from the agent.
Failure Modes
Token theft: If an attacker steals a delegation token, they cannot use it without also stealing the agent’s credentials (because the token is bound to the agent identity). The attacker would need to compromise both the user’s delegation token and the agent’s access token.
Agent compromise: If an attacker compromises the agent, they gain access to all delegation tokens the agent holds. The attacker can act on behalf of any user who authorized that agent, within the scope granted. Users should revoke delegation when they stop using an agent.
Scope creep: If the user grants overly broad scope, the agent can access more than intended. Cloudflare provides scope templates (read-only, specific endpoints, time-limited) but cannot prevent users from granting excessive access.
Revocation lag: Delegation tokens have an expiration timestamp. If a user revokes a token, the agent can still use it until expiration unless the server checks a revocation list on every request. Cloudflare provides a revocation API but servers must opt in.
Cloudflare dependency: The entire system depends on Cloudflare’s availability and security. If Cloudflare goes down, delegation tokens cannot be issued or validated. If Cloudflare is breached, attackers can issue arbitrary tokens.
Comparison to Existing Patterns
| Approach | Identity Visibility | Credential Exposure | Revocation Granularity |
|---|---|---|---|
| Agent holds user credentials | None (server sees agent) | High (agent has full access) | All-or-nothing (change password) |
| OAuth delegation (RFC 8693) | Good (token contains user claims) | Low (agent gets scoped token) | Per-token (revoke specific grant) |
| Cloudflare Trusted Agent Delegation | Good (delegation token + agent token) | Low (agent never sees user credentials) | Per-token (revoke specific delegation) |
OAuth 2.0 Token Exchange (RFC 8693) solves a similar problem but requires the agent to interact with the user’s identity provider for every user. Cloudflare’s approach centralizes delegation issuance, which simplifies agent implementation but introduces a single point of trust.
Technical Verdict
Use Cloudflare Trusted Agent Delegation when:
- You operate a site that agents will access on behalf of many users.
- You need per-user authorization and audit trails even when requests come through agents.
- You already use Cloudflare for edge routing or security.
- You trust Cloudflare as an identity intermediary.
Avoid it when:
- You need a decentralized trust model (no single party controls delegation).
- Your agents already implement OAuth 2.0 Token Exchange with your identity provider.
- You operate in a regulatory environment that prohibits third-party identity intermediaries.
- Your threat model assumes Cloudflare could be compromised or coerced.
The system solves a real infrastructure problem: how to preserve user identity when agents act as intermediaries. The trade-off is centralization. Every site operator and every agent developer must trust Cloudflare to correctly identify users, issue valid tokens, and protect signing keys. For many use cases, that trade-off is acceptable. For high-security environments or decentralized systems, you need a different approach.