In February 2026, Meta alignment director Summer Yue connected an OpenClaw agent to her email, and gave it one instruction: suggest what to archive or delete, but take no action without approval. For weeks, the test runs were clean.
\nThen she pointed it at her real inbox. During that run, a routine step known as context-window compaction that summarizes older context to free up tokens, kicked in and quietly summarized the safety instruction away. Without that constraint in place, the agent started deleting emails, and by the time Yue noticed, it had already removed over 200. She typed “STOP OPENCLAW.” But the agent simply acknowledged the message and kept deleting anyway. So she ran to her Mac Mini and physically killed the process.
Nothing was compromised. No token stolen, no prompt injection, no credential leak. Authentication succeeded. API-level authorization succeeded. The identity layer had no mechanism to intervene, because there was no third check. That gap, and the architecture that closes it, is what this post covers.
\nOAuth was designed around a present human. A user clicks approve, a token is issued, an application spends it while the user waits. AI agent authentication breaks three of those assumptions.
\nThe architectural consequence: any constraint that matters must live outside the agent’s context window. Scopes in a signed token and policy evaluated at a tool server survive compaction, prompt injection, and model rationalization, because the agent does not get a vote.
\nEvery agentic system has four distinct principals, and every boundary between them is a place where identity must be re-established rather than assumed.
\n| Actor | \nIdentity | \nResponsibility | \n
|---|---|---|
| End user | \nHuman, authenticated via OIDC | \nInitiates the task, grants consent | \n
| Application backend | \nService identity | \nAuthenticates the user, spawns the agent, mints agent tokens | \n
| Agent runtime | \nAgent identity, derived per task | \nPlans and executes steps, requests capability tokens | \n
| Tool or resource server | \nService identity | \nExecutes actions, enforces scope and policy | \n
The agent runtime is most often modeled wrong. Handing the agent the user’s own token makes every action indistinguishable from the user’s in logs. Giving it a long-lived service account detaches it from user consent. The correct model gives the agent its own agentic identity, derived from the user’s session at task start, scoped to that task, and expiring with it. Every token should answer: which user authorized this, which agent is acting, and which task is it acting for.
\nEach hop in the token chain is an RFC 8693 token exchange. A user token carrying repo:read and repo:write exchanges for a narrower agent token carrying repo:read. That agent token exchanges for an even narrower per-tool capability token carrying a single action. At no exchange can a token acquire a permission its parent lacked.
The rule needs to be code, not documentation:
\ndef narrow(parent_scopes, requested_scopes):\n \"\"\"Return only requested scopes the parent actually holds. An attempt to\n widen is a signal worth failing on, not silently dropping.\"\"\"\n parent = set(parent_scopes)\n requested = set(requested_scopes)\n escalation = requested - parent\n if escalation:\n raise PermissionError(f\"scope escalation attempt: {sorted(escalation)}\")\n return sorted(requested)Raising rather than silently intersecting surfaces misconfiguration at the point it happens, since a well-formed agent should never request a scope it was not derived with.
\nA capability token at the narrowest tier:
\n{\n \"sub\": \"agent:triage-01\",\n \"act\": { \"sub\": \"user:u123\" },\n \"tenant\": \"acme\",\n \"aud\": \"https://tools.example.com/github\",\n \"scopes\": [\"github.issues.label\"],\n \"task_id\": \"task:t789\",\n \"cnf\": { \"jkt\": \"0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I\" },\n \"exp\": 1774000120\n}aud restricts the token to one tool server. act records the delegating user (the RFC 8693 delegation claim). cnf.jkt binds it to a key. Two-minute expiry: capability tokens should survive one tool call, not a session.
If you are building a remote MCP server, MCP authentication now requires OAuth 2.1, and several requirements are routinely missed.
\n/.well-known/oauth-protected-resource (RFC 9728). Authorization server metadata follows RFC 8414. Dynamic Client Registration (RFC 7591) is now formally deprecated in the MCP spec in favor of Client ID Metadata Documents (CIMD). DCR remains available only for backward compatibility, with a twelve-month minimum deprecation window.This runs before DPoP proof verification. Reject wrong-audience tokens without spending a signature check:
\nCANONICAL_URI = \"https://tools.example.com/mcp\"\n\ndef validate_audience(token_claims: dict, canonical_uri: str = CANONICAL_URI) -> None:\n \"\"\"RFC 8707: the token must name this server, and only this server.\"\"\"\n aud = token_claims.get(\"aud\")\n if aud is None:\n # Some IdPs still emit the non-standard `audience` claim.\n aud = token_claims.get(\"audience\")\n if aud is None:\n raise PermissionError(\"token carries no audience\")\n\n audiences = [aud] if isinstance(aud, str) else list(aud)\n if canonical_uri not in audiences:\n raise PermissionError(f\"token not issued for this server: {audiences}\")Bearer tokens are passwords: whoever holds one can spend it. Sender-constrained tokens bind a token to a key. mutual TLS (mTLS) does this at the transport layer and requires certificate infrastructure at every hop. Demonstrating Proof-of-Possession (DPoP), defined in RFC 9449, does it by signing a short JWT per request over ordinary HTTPS, usually the right choice for OAuth for AI agents where tool servers are third-party.
\nThe agent generates a keypair; the token carries a cnf.jkt thumbprint. Each request includes a fresh DPoP proof:
import base64, hashlib, json, time, uuid\nimport jwt\nfrom cryptography.hazmat.primitives.asymmetric import ec\n\n\ndef b64url(data: bytes) -> str:\n return base64.urlsafe_b64encode(data).decode().rstrip(\"=\")\n\n\nprivate_key = ec.generate_private_key(ec.SECP256R1())\nnums = private_key.public_key().public_numbers()\njwk = {\n \"kty\": \"EC\",\n \"crv\": \"P-256\",\n \"x\": b64url(nums.x.to_bytes(32, \"big\")),\n \"y\": b64url(nums.y.to_bytes(32, \"big\")),\n}\n\n\ndef create_dpop_proof(method: str, url: str, access_token: str) -> str:\n # ath binds this proof to one specific access token\n ath = b64url(hashlib.sha256(access_token.encode()).digest())\n return jwt.encode(\n {\n \"jti\": str(uuid.uuid4()),\n \"htm\": method,\n \"htu\": url,\n \"iat\": int(time.time()),\n \"ath\": ath,\n },\n private_key,\n algorithm=\"ES256\",\n headers={\"typ\": \"dpop+jwt\", \"alg\": \"ES256\", \"jwk\": jwk},\n )Verification at the tool server has to check five things, and skipping any one of them removes most of the value:
\ndef jwk_thumbprint(jwk_dict: dict) -> str:\n # RFC 7638: required members only, lexicographic order, no whitespace\n canonical = json.dumps(\n {\"crv\": jwk_dict[\"crv\"], \"kty\": jwk_dict[\"kty\"],\n \"x\": jwk_dict[\"x\"], \"y\": jwk_dict[\"y\"]},\n separators=(\",\", \":\"), sort_keys=True,\n )\n return b64url(hashlib.sha256(canonical.encode()).digest())\n\n\n_seen_jti = set() # use Redis with a TTL in production\n\n\ndef verify_dpop_proof(proof, method, url, access_token, token_cnf_jkt):\n header = jwt.get_unverified_header(proof)\n if header.get(\"typ\") != \"dpop+jwt\":\n raise ValueError(\"bad typ\")\n\n\n proof_jwk = header[\"jwk\"]\n pub = jwt.algorithms.ECAlgorithm.from_jwk(json.dumps(proof_jwk))\n claims = jwt.decode(proof, pub, algorithms=[\"ES256\"])\n\n\n # 1. the proof covers this exact request\n assert claims[\"htm\"] == method, \"method mismatch\"\n assert claims[\"htu\"] == url, \"url mismatch\"\n # 2. the proof is fresh\n assert abs(time.time() - claims[\"iat\"]) < 60, \"proof too old\"\n # 3. the proof is tied to this access token\n expected_ath = b64url(hashlib.sha256(access_token.encode()).digest())\n assert claims[\"ath\"] == expected_ath, \"access token hash mismatch\"\n # 4. the token was issued to this key\n assert jwk_thumbprint(proof_jwk) == token_cnf_jkt, \"token not bound to this key\"\n # 5. the proof has not been replayed\n if claims[\"jti\"] in _seen_jti:\n raise ValueError(\"replay detected\")\n _seen_jti.add(claims[\"jti\"])\n\n\n return claimsMost AI agent authorization architectures stop after two layers. Authentication establishes who is calling. API-level authorization confirms the token carries the right scope. Both passed in the Yue incident, and 200 emails still vanished.
\nA scope is a statement about a category of action. The dangerous thing is a specific action with specific arguments. email.delete says the agent may delete email. It says nothing about whether this agent should delete these 200 messages in a single burst after the user asked it to suggest rather than act.
That question belongs to a policy decision point. The pattern: a policy enforcement point (PEP) at the tool server calls a policy decision point (PDP) before execution. The OpenID AuthZEN working group is standardizing this around Subject/Action/Resource/Context, and its COAZ profile maps it specifically to MCP tool authorization, requiring that context carry the agent’s agentic identity so policy can distinguish an agent acting for a user from the user acting directly.
Two design rules worth adopting from AuthZEN regardless of PDP implementation: a deny is a successful evaluation returning a negative decision, not an HTTP error; a malformed request is an error, not a silent deny.
\ndef has_scope(token_claims: dict, required_scope: str) -> bool:\n return required_scope in token_claims.get(\"scopes\", [])\n\n\ndef policy_decision(subject: dict, action: str, resource: str, context: dict) -> dict:\n \"\"\"In production this is an HTTP call to an AuthZEN PDP.\n The Subject/Action/Resource/Context shape is the same either way.\"\"\"\n if action == \"github.issues.delete\":\n return {\"decision\": False, \"reason\": \"action_not_permitted_for_agents\"}\n if resource.split(\":\")[1].split(\"/\")[0] != subject[\"tenant\"]:\n return {\"decision\": False, \"reason\": \"cross_tenant_denied\"}\n if context.get(\"spend_usd\", 0) > 5.00:\n return {\"decision\": False, \"reason\": \"spend_cap_exceeded\"}\n return {\"decision\": True, \"reason\": \"policy:triage-agent-v2\"}\n\n\ndef authorize_tool_call(token_claims, action, resource, context):\n # Layer 1: does the token permit this category of action?\n if not has_scope(token_claims, action):\n return {\"allowed\": False, \"reason\": \"scope_missing\"}\n # Layer 2: does policy permit this specific call, right now?\n subject = {\"agent_id\": token_claims[\"sub\"], \"tenant\": token_claims[\"tenant\"]}\n decision = policy_decision(subject, action, resource, context)\n return {\"allowed\": decision[\"decision\"], \"reason\": decision[\"reason\"]}Running that against a correctly-scoped token makes the point:
\nallowed label call -> allowed=True reason=policy:triage-agent-v2\nscope not granted -> allowed=False reason=scope_missing\ncross tenant-> allowed=False reason=cross_tenant_denied\nspend cap -> allowed=False reason=spend_cap_exceededRows three and four are the entire argument. Valid token. Correct scope. Call denied anyway, because scope is not policy. Any agent architecture without that second check is one compaction away from the Yue incident.
\nOne rule governs placement: policy is evaluated at the tool server, never inside the agent’s prompt. Policy in a prompt is advisory text subject to exactly the failures described above.
\nA capability token valid for 120 seconds is still valid for 120 seconds after the user’s account is disabled. Continuous Access Evaluation Profile (CAEP) closes this gap by pushing security events (session-revoked, credential-change, device-compliance-change) from your identity provider to tool servers via the OpenID Shared Signals Framework, which profiles Security Event Tokens (RFC 8417) and pushes them over HTTP (RFC 8935). The spec explicitly covers “human or robotic users,” making agent runtimes first-class. Treat CAEP as what makes a kill switch real: revocation on the next token refresh is not a kill switch when the agent already has the token it needs.
A receiver is two pieces: an endpoint that accepts and verifies incoming SETs, and a revocation set the tool server checks before executing any action.
\nimport jwt\nfrom jwt import PyJWKClient\nimport requests\n\nCAEP_STREAM_ENDPOINT = \"https://idp.example.com/.well-known/sse-configuration\"\nREVOKED_SESSIONS = set() # Redis in production\n\ndef register_caep_stream(receiver_url: str, events: list[str]) -> dict:\n \"\"\"Register this tool server as a CAEP receiver.\"\"\"\n return requests.post(CAEP_STREAM_ENDPOINT, json={\n \"delivery\": {\"method\": \"urn:ietf:rfc:8935\", \"endpoint_url\": receiver_url},\n \"events_requested\": events,\n }).json()\n\nTRANSMITTER_JWKS_URI = \"https://idp.example.com/.well-known/jwks.json\"\n\n\ndef handle_caep_event(raw_set: str) -> None:\n \"\"\"Verify and process inbound Security Event Tokens.\"\"\"\n jwks_client = PyJWKClient(TRANSMITTER_JWKS_URI)\n key = jwks_client.get_signing_key_from_jwt(raw_set).key\n event = jwt.decode(raw_set, key, algorithms=[\"RS256\"])\n event_type = event.get(\"events\", {})\n CAEP_SESSION_REVOKED = \"https://schemas.openid.net/secevent/caep/event-type/session-revoked\"\n if CAEP_SESSION_REVOKED in event_type:\n session_id = event_type[CAEP_SESSION_REVOKED].get(\"subject\", {}).get(\"session_id\")\n if session_id:\n REVOKED_SESSIONS.add(session_id)\n\ndef session_is_revoked(token_claims: dict) -> bool:\n return token_claims.get(\"sid\") in REVOKED_SESSIONS\n\n# Register for revocation events at startup\nregister_caep_stream(\n receiver_url=\"https://tools.example.com/caep/events\",\n events=[\"session-revoked\", \"credential-change\"],\n)Not every action needs a human, and gating everything trains operators to approve reflexively. Route by risk instead:
\n| Ruleset | \nExample condition | \nOutcome | \n
|---|---|---|
| Auto-allow | \nRead-only operations under rate limit | \nExecute immediately | \n
| Soft-hold | \nSpend above threshold, first use of a new tool | \nQueue for async approval | \n
| Must-approve | \nDeletes, cross-tenant access, irreversible operations | \nBlock until explicit approval | \n
Three details separate a working gate from theatre. The gate is enforced at the tool server, not requested of the agent. “Ask before deleting” in a prompt is the instruction compaction removed in the Yue incident. Approval must be out of band. Yue’s STOP commands entered the same failing loop. And every decision is recorded in a store the agent cannot write to.
\nDPoP verification and the PDP call are not SuperTokens features. They belong in your tool server, using the Python implementations shown earlier or their Node equivalents, running before the tool body executes. Authentication establishes which agent is calling and which user it acts for. Authorization is two separate questions: whether the token carries the right scope, and whether policy permits this specific call with these arguments right now. Most agent incidents involve a correctly authenticated agent whose specific action nobody checked. For a remote MCP server, yes. The spec requires OAuth 2.1, mandates RFC 8707 Resource Indicators for audience binding, and requires protected resource metadata at DPoP binds a token to a key the caller proves possession of on every request, so a stolen token alone is useless. It matters more for agents than browsers because agent tokens travel to many third-party tool servers over long-running tasks, multiplying interception risk. DPoP works without the certificate infrastructure mTLS requires. It must not. Scopes narrow at every RFC 8693 token exchange and never widen, enforced in code at each token-issuing endpoint. An agent requesting a scope its parent session does not hold is a signal worth alerting on. Three controls compound. Short expiry bounds the window. DPoP makes the token unusable without the bound key. CAEP pushes a revocation event to tool servers so in-flight tokens are dropped immediately. Audience restriction limits replay to one tool server. AI agent authentication is three layers, and most implementations build two. Authentication answers who is calling. Scoped, sender-constrained, audience-restricted tokens answer what category of action the caller may take. Per-action policy evaluated at the tool server answers whether this specific call should proceed. The Yue incident cleared the first two layers and needed the third. Every constraint that mattered lived in a context window that compaction summarized away, and stop commands travelled through the same failing loop. Constraints belong in signed tokens and in policy evaluated outside the agent. Control channels belong outside the channel being controlled.import OAuth2Provider from \"supertokens-node/recipe/oauth2provider\";\nimport { UserRoleClaim } from \"supertokens-node/recipe/userroles\";\nimport SuperTokensMcpPlugin, {\n SuperTokensMcpServer,\n} from \"supertokens-mcp-plugin\";\nimport supertokens from \"supertokens-node\";\n\n\nconst server = new SuperTokensMcpServer({\n name: \"triage-mcp\",\n version: \"1.0.0\",\n path: \"/mcp\",\n validateTokenPayload: async (accessTokenPayload, _userContext) => {\n // Reject anything that is not an agent-derived token. Check the plugin's\n // exported types for the exact non-OK status shape in your version.\n if (accessTokenPayload.token_type !== \"agent\") {\n throw new Error(\"agent token required\");\n }\n return { status: \"OK\" };\n },\n claimValidators: [UserRoleClaim.validators.includes(\"agent-operator\")],\n});\n\n\nserver.registerTool(\n \"label-issue\",\n { inputSchema: {}, description: \"Apply a label to a GitHub issue\" },\n async (args, extra) => {\n const claims = extra.authInfo;\n validate_audience(claims);\n // DPoP proof verification requires raw request headers. \n // Wire this at the HTTP middleware layer before requests reach the MCP handler.\n if (session_is_revoked(claims)) throw new Error(\"session revoked\");\n const decision = authorize_tool_call(claims, \"github.issues.label\", \"repo:acme-org/payments-service\", {});\n if (!decision.allowed) throw new Error(decision.reason);\n return { content: [{ type: \"text\", text: \"labelled\" }] };\n },\n);\n\n\nsupertokens.init({\n supertokens: { connectionURI: \"<CONNECTION_URI>\", apiKey: \"<API_KEY>\" },\n appInfo: {\n appName: \"<APP_NAME>\",\n apiDomain: \"<API_DOMAIN>\",\n websiteDomain: \"<WEBSITE_DOMAIN>\",\n },\n recipeList: [\n OAuth2Provider.init(), // required for the MCP authorization flow\n ],\n experimental: {\n plugins: [SuperTokensMcpPlugin.init({ mcpServers: [server] })],\n },\n});FAQ
\nWhat is the difference between AI agent authentication and AI agent authorization?
\nDo I need OAuth 2.1 for my MCP server?
\n/.well-known/oauth-protected-resource. Local stdio servers are the exception; credentials arrive from the host process.What is DPoP and why does it matter for AI agents specifically?
\nCan an AI agent’s token have more access than the user who invoked it?
\nWhat happens if an agent’s token is stolen mid-session?
\nSummary
\n