How it works

How an agent gets permission, step by step

One delegation, from a person's request to the token running out. The person approves a specific task, the agent gets a token limited to that task and a short lifetime, and every call it makes is checked and logged. When something goes wrong, the damage depends on how much that token allows and for how long. The steps follow Maya's request through a remote MCP server; a plain OAuth API works the same way.

1. Requested. The person asks. The server answers 401 with a pointer to its Protected Resource Metadata (RFC 9728), which names the authorization server. The agent's app identifies itself, preferably with a Client ID Metadata Document (a client ID that is a URL describing the app), since the MCP spec of July 28, 2026 deprecated anonymous dynamic registration, and asks for a token that works at that one server. What can go wrong: if the server names no scopes, the agent falls back to every scope the server lists as supported, so a long list means a broad token.
2. Approved. Someone says yes: the person clicks Allow on a consent screen (MCP's default), the company's identity provider has pre-approved this agent for this app with no screen at all (Cross App Access), or a CIBA request (an OpenID standard) asks the person's phone to approve one sensitive action. Step-up belongs here too: a stronger sign-in, or a fresh approval for a scope the agent wasn't given. What can go wrong: approval turns into reflex. Anthropic reported in March 2026 that people approve 93% of Claude Code's permission prompts; the classifier it built to decide instead still missed 17% of risky actions in a small test. The Refused exception starts here.
3. Granted. The authorization server issues an access token for one server, with only the approved scopes and a short life. This is the diagram's mark: keep it narrow and short. NIST's final guidance on tokens (IR 8587, September 2026) says access tokens should last no more than an hour and workload tokens should be bound to their holder. Google already binds its agents' tokens; MCP doesn't require it, and its DPoP proposal has been an open draft since December 2025. What can go wrong: refresh tokens outlive the task, and whoever stores them becomes the target, as Drift's AWS environment did.
4. Acting. Each call carries the token. The server checks its signature, audience and scope, then its own permission rules (the login guide covers those), and logs the person, the agent, the token, the scope used, the tool and the outcome. If the agent needs more, the server returns 403 with insufficient_scope and the agent goes back to step 2. What can go wrong: step-up only adds. MCP tells clients to ask for the union of old and new scopes, so a long session ends with the broadest token of the day. The Hijacked exception starts here.
5. Ended. The token expires. Refresh tokens get revoked (RFC 7009), an admin can revoke the agent at the identity provider, and a retired agent is disabled; Entra also moves sponsorship when an agent's human sponsor leaves. A self-contained token can't be recalled before it expires, so its lifetime is the real off switch. What can go wrong: revocation is all or nothing. Salesloft and Salesforce revoked every Drift token on August 20, 2025, so every customer had to reconnect.

Refused comes off the approval step, when a request is too broad or someone declines. The person may say no, or an identity provider rule (an Entra Conditional Access policy, say) may block the agent; a well-built agent narrows its request and asks again. The more common failure is that almost nothing gets refused: in Okta's own 2026 survey of 306 security executives, fewer than half were confident they could control what their agents access.

Hijacked comes off the acting step, through injection or a stolen token. With injection, text the agent reads steers it into misusing access it legitimately holds. Security researchers showed it in May 2025 when a malicious public issue led an agent using GitHub's MCP server to post the user's private repositories publicly, and EchoLeak did something similar to Microsoft 365 Copilot through one email in June 2025. Identity can't catch this, because the token is real, the person consented and the agent is the registered one. With token theft, someone else uses a valid token: Drift in August 2025, Context.ai's stolen tokens reaching Vercel in April 2026, Klue's customers' Salesforce tokens in June 2026. Either way, what limits the damage is the same: tokens bound to one server and one holder, short lifetimes, one identity per agent, separate read and write identities, and an approval for actions you can't undo. Injection itself is covered in AI agents: orchestration platforms.

Cheat sheet: five ways to give an agent an identity

The models mix: Maya's assistant acts for Maya, while the logistics company's overnight reconciliation agent acts on its own. For one sensitive action, CIBA plus Rich Authorization Requests (RFC 9396) is the closest thing to "approve exactly this"; Auth0 ships that pairing.

What an MCP server has to do

As of the July 28, 2026 version of the MCP specification, authorization is optional. A server that follows it must publish Protected Resource Metadata, check that each token was issued for it, and never accept or pass on a token issued for someone else ("token passthrough"; token exchange is the sanctioned route). Clients should register with a Client ID Metadata Document, since dynamic registration is deprecated. Nothing requires sender-constrained tokens, per-tool authorization or an audit field naming the agent. The enterprise path, a stable extension since June 18, 2026, answers critics who said anonymous registration was unacceptable to enterprises. The MCP project named Anthropic's Claude apps and, in preview, Microsoft's VS Code as clients using it; the sources I read don't say either way for OpenAI's or Google's apps.

One agent visits a website: identify, verify, then allow, charge or block

Picture a buyer at a construction firm who asks an agent to find a replacement pump on an industrial distributor's website and add it to a quote. The distributor's site runs behind Cloudflare.

1. Identify. The agent can declare itself with a user-agent string, come from its operator's published IP ranges, or sign each request, with a Signature-Agent header saying where the operator's keys live. What the site sees depends on the operator. As of October 2026, OpenAI signs ChatGPT agent requests with Web Bot Auth. Google signs a subset of Google-Agent requests, calls it experimental and tells sites to keep checking IPs and user agents. Anthropic documents its user agents and an IP list, and I found no documented signing; Perplexity is the same. AWS's AgentCore Browser can sign, in preview. Agent browsers such as OpenAI's Atlas and Perplexity's Comet present a stock Chrome user agent and no public signed identity, according to HUMAN, which sells bot defence.
2. Verify. The gatekeeper fetches and caches the operator's key directory, then checks the signature, its short validity window and a one-time value. Unsigned traffic gets IP and behaviour checks, since a user-agent string proves nothing: DataDome, another bot-defence vendor, says a spoofed ChatGPT user agent got through on about 80% of roughly 700,000 sites it tested.
3. Classify. On July 1, 2026, Cloudflare folded what it had called signed agents into its verified bots, labelled Direct (one operator acting for itself) or Intermediary (acting for many end users, like ChatGPT agent), and sorted them into categories such as Search, Agent, Training and Transact. Cloudflare's docs now say verification "only confirms identity". A verified agent is one whose identity checks out, and whether it gets in is up to the site's rules.
4. Allow, charge or block. The distributor sets a policy per category. Cloudflare announced that from September 15, 2026, new domains would block Training and Agent crawlers by default on pages with ads; I haven't seen whether that rolled out as described. To charge, Cloudflare's pay per crawl answers HTTP 402 with a price; it's still a closed beta in Cloudflare's docs, 15 months after launch, and a "pay per use" version is reported only in the press. If the agent goes on to buy, Visa's Trusted Agent Protocol and Mastercard Agent Pay reuse the same kind of signature, with tags that separate browsing from paying. To block, unverified or abusive traffic gets a challenge or a refusal, and a verified operator can lose its status: Cloudflare delisted Perplexity in August 2025 after finding an undeclared crawler, posing as Chrome, making 3-6 million requests a day.

So the pump agent's fate depends on its operator: signed, in an allowed category, it gets the catalogue; presenting as Chrome, it's judged on behaviour and may meet a challenge halfway through. A verified agent can still behave badly, which is why Akamai and DataDome check intent on top of identity. Whether a site may legally refuse an agent its user sent is still open; see the Amazon and Perplexity case in the deep dive.