Somebody clicked Allow once. Here is the document that keeps it true six weeks later.

THE OPERATOR'S MAP · Chapter: Ship AI · Episode 2 · 28 August 2026. The five chapters advance together each week — agent controls (Ship AI), the open-source stack (Sovereign Stack), governance (The AI Boardroom), evaluation (Beyond the Benchmark), physical AI (Twin & Machine). This chapter's Episode 1, and every other chapter's Episode 2, are linked at the foot of the piece.

The Operator's Map is a weekly series for the people who have to run AI rather than admire it — five chapters, one per domain, all advancing together each week. This chapter teaches agent controls: what actually governs what an AI agent can do inside your company, and how you would prove it. On Tuesday: why a cryptographic receipt of an agent's action is only as good as the grant underneath it. Today: how a one-time human approval becomes a standing entitlement, traced hop by hop through the documents that make it happen. Everything technical gets restated in plain terms as we go.

Why this reaches your desk. The permission model your agents run on is not a vendor's proprietary design. It is a public specification, currently at a revision most published commentary has not read, and it says in plain normative language where a single human approval turns into a capability that operates unattended and grows. Anyone on your team can read it this week, against your own deployment, and come back with an answer. That is unusual in AI governance, and it is worth an afternoon before someone external spends it for you.

Terms that matter this episode

The four seconds everything else hangs from

It is a Tuesday, mid-morning. Somebody on the platform team is wiring an agent to an internal tool server. A browser tab opens. There is a name at the top, an icon, a short list of permissions rendered as strings, and two buttons. They read it for about four seconds, which is longer than most people read it, and they click the one on the right.

The tab closes. The terminal says connected. The agent starts working. Six weeks later it is still working, on a schedule, at three in the morning, against systems nobody has re-approved, and the only approval event in the entire record is that four seconds on a Tuesday.

Nothing in that sentence is a failure. Every hop between the click and the three-in-the-morning run is specified, published, and mostly correct for the problem it was designed against. This article walks the hops in order and reads what each governing document actually says. By the end you will be able to do the same walk against your own deployment, which is the point.

Here is the whole trace on one page before we walk it.

Exactly one row of that table has a human in it.

Hop zero: the name on the approval screen was written by the thing asking for approval

Before a consent screen can render, the application asking for consent needs an identity the authorization server will accept. That identity is a client ID, and how it is obtained changed materially in the current revision of the protocol.

The Model Context Protocol specification's Client Registration chapter now offers three mechanisms and a stated priority order: pre-registered credentials first, then Client ID Metadata Documents, then Dynamic Client Registration, then prompting the user to type the details in.

Dynamic Client Registration, the headline mechanism of the previous revision, now carries a warning box. Its first two sentences, verbatim: "Dynamic Client Registration is deprecated. New implementations should use Client ID Metadata Documents instead." It stays available for compatibility with authorization servers that do not support the newer mechanism.

The replacement works like this, in the specification's words: "This approach enables clients to use HTTPS URLs as client identifiers, where the URL points to a JSON document containing client metadata. This addresses the common MCP scenario where servers and clients have no pre-existing relationship."

So the client identifier is a URL, and at that URL the client publishes a small JSON file about itself: client_id, client_name, redirect_uris. The authorization server fetches it on demand, and must validate that the document's client_id matches the URL exactly, that the redirect URIs in the request match those in the document, and that the document is well-formed JSON carrying the required fields.

Now read the flow diagram on that same page, at the step where the human enters. It says: Server->>User: Display consent page with client_name.

The string the person reads at the top of the approval screen is client_name, taken from a JSON document the requesting client hosts about itself. The authorization server must verify that the document is where it says it is and that the redirect targets match. It is not required to verify that the name is true.

The specification is candid about the residual weakness rather than quiet about it, which is worth saying plainly. It states that "Client ID Metadata Documents cannot prevent localhost URL impersonation by themselves," and instructs authorization servers to display extra warnings for localhost-only redirect URIs, to consider requiring additional attestation, and — a requirement, not a suggestion — to "clearly display the redirect URI hostname during authorization." That last line is something your team should be able to point at on a screenshot of their own consent screen.

Registration being the soft step is not hypothetical. On 16 April 2026 an advisory was published for an npm OAuth provider package, GHSA-xr8f-h2gw-9xh6, CVE-2026-41427, rated high at CVSS 8.4: the OAuth client creation endpoints did not call the authorization hook that the documentation said gated client registration, so deployments relying on that hook were not gated, and any authenticated user could register a client with attacker-controlled redirect URIs and metadata. The instructive detail is in the record: read, list, update, delete and rotate all enforced the hook correctly. Only creation did not. The fix, shipped in 1.6.5, has both creation endpoints call the hook before persisting the client. I name the record and the version, and characterize nobody — the maintainers found it, fixed it and published it, which is what a record like this is for.

Hop one: what the approval screen is required to show, and what it is not

The person is now looking at a list of permissions. Where do those strings come from, and what governs how many of them are on the screen?

The current specification devotes a whole section to this, called Scope Selection Strategy, and its instinct is exactly right. It tells servers to advertise the scopes required for the operation in the WWW-Authenticate challenge, "following the principle of least privilege and preventing clients from requesting excessive permissions." It tells clients to request "only the scopes necessary for their intended operations." It says the scopes_supported field "is intended to represent the minimal set of scopes necessary for basic functionality."

Everything in that paragraph points toward smallness. Hold onto it, because in four hops the same document points the other way, and the reason it does is not carelessness.

One more thing about the strings themselves. OAuth 2.1, which MCP builds on, defines scope in draft-ietf-oauth-v2-1-13 as "a list of space-delimited, case-sensitive strings," and adds: "The strings are defined by the authorization server." There is no registry, no schema, no shared meaning. files:read means whatever the server that issued it decided it means. The person clicking Allow is reading a vocabulary invented by the counterparty.

This is also the hop where a reader should notice something absent. The consent screen names the client and the scopes. In the base flow it does not name the individual task, it does not carry an expiry the person chose, and it does not ask the person to approve a duration. There is no field for "for the next hour." The approval is a switch, not a dial.

Hop two: the only hop where the target is named

The person clicks. The browser redirects. An authorization code comes back and the client exchanges it for tokens.

Two controls in the current revision deserve proper credit here, because this article is about to be hard on the stack and the balance matters.

The first is issuer validation. The current revision requires the client to record the authorization server's issuer before redirecting the user, and to compare it against the iss parameter that comes back, using strict string comparison, with a table of exactly what to do in each of four cases. It specifies that the client "MUST NOT apply scheme or host case folding, default-port elision, trailing-slash, or percent-encoding normalization" before comparing, and that the validation applies to error responses too. That is a mix-up attack closed carefully, with the pedantry that closing it properly requires.

The second is the resource parameter, and it is the most operationally useful thing in the chapter. The specification says clients "MUST implement Resource Indicators for OAuth 2.0 as defined in RFC 8707 to explicitly specify the target resource for which the token is being requested," that the parameter "MUST be included in both authorization requests and token requests," and that it "MUST identify the MCP server that the client intends to use the token with." Then it adds a line that tells you how much of the ecosystem is expected to be missing this: "MCP clients MUST send this parameter regardless of whether authorization servers support it."

That is the hop where the token acquires a target. It answers "a token for what," and it is why a leaked token cannot automatically be replayed at every other server the same authorization server protects.

And here is the conditional you have to read. The security chapter states the benefit as: resource indicators "provide critical security benefits by binding tokens to their intended audiences when the Authorization Server supports the capability."

Hop three: two tokens come back, and only one of them has a stated lifetime

The token endpoint returns an access token. It usually also returns a refresh token. That second object is where a four-second approval becomes a six-week capability, and the current revision added a section about it that did not exist before.

Here is the Refresh Tokens section, essentially in full.

Read the name of that scope again. offline_access. Its literal meaning is: let this client act while the person is offline. It is not a euphemism and it is not hidden. It is the name of the thing, sitting in a specification, doing exactly what it says.

Now the sentence this whole article turns on. It is not in the MCP specification; it is in the base standard, and it reads: "Note that there is no need to communicate the lifetime of the refresh token to the client, because the client can't do anything different with the knowledge of the lifetime." The same section states flatly that "there is no property defined to communicate the expiration of a refresh token to the client," and that consequently "the client already has to handle the case of a refresh token expiring at an arbitrary time."

The reasoning is sound as engineering. A client that knew the expiry would behave no differently, so telling it is wasted protocol surface. But look at what that means for anyone trying to answer a question about the deployment. How long does this permission last? The protocol has no field for the answer. The credential in your agent's possession has no stated end date, because the standard concluded that stating one served no purpose.

And the standard is explicit that the duration can be made effectively unbounded. It offers, as an ordinary design choice, that "the authorization server might choose to use dynamic lifetimes (e.g. the refresh token expiry is extended as long as the refresh token is used at least once every 7 days)."

Sit with that example against a scheduled agent. A process that runs nightly uses its refresh token every night. A refresh token whose expiry extends on every use, held by a process that runs every night, does not expire. Not as an abuse. As the documented behavior.

There is a real constraint, and it deserves full strength because it is the strongest thing on the stack's side of this argument. OAuth 2.1 requires that "if refresh tokens are issued, those refresh tokens MUST be bound to the scope and resource servers as consented by the resource owner." A refresh token cannot mint more than was consented. It is a faithful, bounded copy of that Tuesday morning.

So the honest reading is not that the refresh token is a loophole. It is that the refresh token is a correct and durable representation of an approval whose duration nobody was asked about, held by a party for whom duration is not a natural limit.

One further distinction, because it is where careful readers most often relax too early. The security chapter says: "Authorization servers SHOULD issue short-lived access tokens to reduce the impact of leaked tokens. For public clients, authorization servers MUST rotate refresh tokens." Rotation is a genuine and important control. It is also a control against theft, not against duration. A rotated refresh token is a fresh long-lived credential replacing the old one at every use. The chain does not get shorter. It gets newer.

Hop four: the credential now lives somewhere, and something has to hold it

Between the Tuesday click and the three-in-the-morning run, the refresh token has to sit somewhere. This is the hop where architecture, rather than specification, decides what you can prove.

The specification's contribution here is a single line, and it is stricter than most people realize: "Note that authorization MUST be included in every HTTP request from client to server." There is no session that carries authority implicitly. Every request re-presents the credential. That is good design, and it also means that whatever holds the credential is, functionally, the thing that holds the permission.

Vendors have started naming that thing and selling it, which is a sign the layer is being taken seriously. On 22 August 2026, Google Cloud's IAM release notes recorded, verbatim: "The Agent Identity auth manager and the Agent Identity APIs (agentidentity.googleapis.com and agentidentitycredentials.googleapis.com) are generally available." The same entry describes the service as centralized credential management and authentication brokering for outbound tool authentication, supporting OAuth variants and API keys, replacing an earlier connectors API. Two entries dated 14 August 2026 take the governance surface generally available alongside it: Organization Policy custom constraints for Agent Identity resources such as agentidentity.googleapis.com/AuthProvider, and VPC Service Controls integration for both Agent Identity APIs.

"Credential brokering for outbound tool authentication" is the vendor's own name for hop four. A named, policy-constrained, generally available broker is a considerably better place for a refresh token than an environment variable on a build agent, and an operator should treat the arrival of that product category as good news. It is also, precisely, an institution for holding standing capability. The credential did not become less standing by being managed well. It became easier to find, which is worth a great deal, and easier to keep, which is the part to watch.

Hop five: the ratchet, and the sentence that names it

Now the agent does something new. It reaches for an operation its current token does not cover. The server answers with a 403 and an insufficient_scope error, naming the scopes the operation needs.

What is the client supposed to do? The Step-Up Authorization Flow says, in step two, verbatim:

"Determine required scopes by computing the union of the client's previously requested scope set and the scopes from the current challenge. This ensures previously granted permissions are preserved when servers emit per-operation scope challenges."

The Scope Selection Strategy section says the same thing in different words: "When re-authorizing, clients SHOULD include these scopes alongside any previously granted scopes to avoid losing permissions needed for other operations." And on responsibility: "Scope accumulation across operations is a client-side responsibility."

Episode 1 of this chapter drew a distinction between a union and a meet — between every door all your badges open, and the one door this errand needs — and argued that a durable control grants the meet. The current specification requires the client to compute the union, and uses that word.

This is not a defect and I am not going to pretend it is one. The rationale is stated and it is correct: if a client dropped its old scopes every time it answered a new challenge, users would be re-approving things all day and functionality would break at random. Union is the right answer to the question the specification is answering, which is how to keep an interactive tool usable across many operations.

The consequence is still that the permission set is monotone. It can grow at any 403. There is no step anywhere in the flow that shrinks it. And each growth step is a re-authorization, not a fresh deliberate approval of the whole — the person, if they are present at all, is being asked to keep going, not being shown the accumulated total and asked whether they still want it.

The specification does place guardrails, and they should be read for what they bound. "Clients SHOULD implement retry limits and SHOULD track scope upgrade attempts to avoid repeated failures for the same resource and operation combination." A retry limit bounds how many times a client asks after being refused. It does not bound what the union contains once the asks succeed. Those are different quantities, and only one of them is what an examiner will ask about.

Note also who the specification expects to walk this flow: "Clients acting on behalf of a user SHOULD attempt the step-up authorization flow. Clients acting on their own behalf (client_credentials clients) MAY attempt the step-up authorization flow or abort the request immediately." A client with no person behind it is anticipated, in the text, as a participant in a widening flow.

Hop six: the extension whose stated purpose is to remove hop one

Everything so far assumed a person clicked something once. There is a published, stable extension to this protocol whose purpose is to make that unnecessary, and reading it honestly is the most important reading in this episode.

The MCP Authorization Extensions repository currently holds exactly two extensions. One is marked draft. One is marked stable.

What does the stable one do for the end user? The extension states the benefit in its own words: "This removes the need to manually connect and authorize the MCP Client to each MCP Server."

What does it do for the administrator? "This enables visibility and control over which MCP Servers are able to be used within the organization."

How is access decided? "The IdP evaluates administrator-defined policies for the token exchange request and determines if the MCP Client should be granted access." And on the token that results: "The issued access token MUST be audience-restricted to the MCP Server identified by the resource claim in the ID-JAG."

The underlying mechanism is an IETF Internet-Draft, the Identity Assertion JWT Authorization Grant, at revision 04 dated 21 May 2026. Its abstract: "This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider." On consent, the draft is direct: the mechanism does not need to obtain user consent directly from the resource owner again at the token exchange step, because the identity provider's prior issuance of the identity assertion serves as the authorization delegation.

Now, the fair reading, because a one-sided reading of this would be dishonest. This extension is better than what it displaces in every direction an operator cares about. The alternative it replaces is a user pasting a long-lived API key into a configuration file, with no policy point, no audience restriction, no administrative visibility and no revocation story. Enterprise-Managed Authorization gives the organization a place to decide which clients may reach which servers for which users, and it binds the resulting token to a named audience. If your enterprise is choosing between this and the status quo, this is the better artifact.

And: it says, in its own words, that it removes the approval. The four seconds on a Tuesday are gone, replaced by an administrator's policy written once, at a different time, about a category rather than a task. That is a real improvement in governability and a real loss of the one event in the trace where a human looked at a specific thing. Both are true. An operator should hold both.

There is one narrowing point in the whole trace, and it is here. The ID-JAG draft says the resource authorization server "applies local policy to decide whether to honor the grant, whether to narrow or reject the requested access, and what access token to issue." That is the only place in eight hops where a document contemplates a party receiving a request and deliberately issuing less. It is a local-policy decision at the far end, not a grant event created at the hop. Whether any given deployment actually exercises it is precisely the sort of thing a reading checklist exists to ask.

Hop seven: the far end, and what the last few days added

The token finally arrives at the server that will act on it. The specification is at its strictest here, and rightly.

MCP servers "MUST validate that access tokens were issued specifically for them as the intended audience." Clients "MUST NOT send tokens to the MCP server other than ones issued by the MCP server's authorization server." Servers "MUST only accept tokens that are valid for use with their own resources," and — the line that closes the confused-deputy hole — "MCP servers MUST NOT accept or transit any other tokens." If the server calls an upstream API, the specification is explicit that this requires a separate token from the upstream authorization server, and that "the MCP server MUST NOT pass through the token it received from the MCP client."

Those requirements are unambiguous. What a reading checklist asks is whether the implementation in front of you meets them, and the public record from the last few days is a useful place to calibrate expectations.

I ran a bounded sweep of the GitHub Advisory Database for reviewed advisories matching "MCP server," sorted by publication date, over the seventy-two hours of 25 to 27 August 2026. Re-run the query yourself; the link is the query.

Read the description of the first high-severity one, because it is this article's entire argument compressed into a defect: "Cross-Session Data Exposure via Caller-Controlled session_id. The process-global SessionStore accepts caller-supplied session_id values without binding them to any authenticated principal or transport session."

Without binding them to any authenticated principal. That is the sentence. The most severe entry in the same window is a different shape of the same thing: an endpoint that took the user identifier from the request body because the shared secret gating it was unset by default, rated critical under CWE-306 and patched in 0.117.2. I name these records, with their identifiers and their fixes, and I characterize nobody. Every one of them came out of the ecosystem's own disclosure process, which is the process working.

The pattern worth carrying out of the sweep is not that a handful of packages had bugs. It is where the bugs sit. At the far end of a carefully specified authorization chain, the recurring failure is not a badly scoped token. It is no binding to a principal at all.

The seam, named

Walk the trace once more and the answer to Episode 1's promised question falls out.

An approval is an event: a person, at a moment, looked at something and said yes. There is exactly one of those in the whole chain, at hop one, and it lasts about four seconds.

An entitlement is a standing capability: what a principal may do, indefinitely, until someone changes it. There are several of those, and they are created at hop three when the refresh token is issued, made durable at hop four when something holds it, widened at hop five by a flow that computes a union, and generalized at hop six by an extension that replaces the approval with a policy.

The conversion is not hidden and it is not anybody's mistake. All three are correct answers to the questions their authors were asking. None of them was asked the question an examiner asks, which is: who approved this, for what, and when does it end?

This chapter's answer to that is the same answer the whole wave of Episode 2 is built on. Read the artifact in front of you. The AI Boardroom chapter reads an examination list this week; Sovereign Stack reads a model card as a contract; Beyond the Benchmark reads what a benchmark actually measured; Twin & Machine reads what a certification scope covers. This chapter reads a permission model. In every case the finding is in the document, written down, and the skill is the reading rather than the discovery.

The worked artifact: an agent permission-model reading checklist

Here is the thing to take to work. Thirteen questions, in trace order, each naming what to look for, where it lives, and what a bad answer sounds like. It is designed to be walkable in one sitting against one deployment, by an engineer or by a reviewer who has never read the specification. Reproduce it, edit it, argue with it.

While you are inside item 13, ask the three things the specification states as MUSTs at the far end: does the resource server validate audience, does it refuse to pass the token upstream, and is the session bound to an authenticated principal. That third one is where the this week's published advisories landed.

Where this reads the same, and where it does not

One geographic note, and it cuts the useful way.

The supervisory frames differ sharply across the markets an operator in this audience actually works in. In the United States, the 17 April 2026 interagency revision to model risk guidance put generative and agentic systems expressly out of scope and disclaimed enforceable standards, which is a deferral rather than an exemption: the obligations attached to the underlying activity are untouched, and what was removed is the framework that would have specified the controls. The Gulf and Indian pictures are different again, and this series' governance chapter reads them properly this week rather than in passing here.

The artifact, though, does not vary. draft-ietf-oauth-v2-1-13 reads identically in Charlotte, in Riyadh and in Bengaluru. The refresh token in a Mumbai deployment has the same absent expiry field as the one in Toronto. The step-up flow computes the same union in Abu Dhabi as in Chicago. A team that can read its own permission model can answer any supervisor who asks; a team that cannot can answer none of them, and will be waiting for a framework that arrives, when it arrives, written against whatever the market has already built.

What would make me wrong

Three things, stated so they are checkable.

Show me an authorization server whose consent screen presents a duration as an approvable field, and the hop-three argument weakens considerably. Nothing prevents it; it is a product decision, not a protocol limitation, and the protocol would carry it fine.

Show me a step-up flow that presents the accumulated union to a person and asks them to approve the total rather than the increment, and hop five stops being a ratchet and becomes a periodic review. That is buildable today, inside the current specification, by a single authorization server that decides to.

And show me a deployment where the resource authorization server routinely exercises the ID-JAG draft's provision to narrow the requested access rather than honor it as asked, and hop six looks materially different. The draft explicitly contemplates it. I have not found published documentation of anyone doing it as a default, and public documentation is not the same as internals — a counterexample would be a fact about one deployment, not about the field, and I would publish it.

The symmetric point, honestly stated: if the supervisory frame that makes these questions bite never bites, some of the urgency here is overstated. On that, the record cuts the uncomfortable way rather than the comfortable one. Deferrals with the obligation left in place are not relief; they are the interval in which every institution decides for itself, and gets read later against whatever it decided.

What to ask your team

1. For each agent integration we run: who clicked Allow, on what date, and where is that recorded?
2. What is the current scope set on our live agent tokens, and how does it compare to the set approved at the beginning?
3. What is the expiry on our refresh tokens, and can whoever answers point at the issuer's configuration rather than a number they remember?
4. Have we ever revoked an agent's access and confirmed it stopped working — not in theory, in a test?
5. If we adopt an enterprise-managed authorization scheme, who is the person whose policy replaces the click, and what does that policy actually say?

The series

This is Episode 2 of The Operator's Map — a weekly series in five chapters, advancing together: Ship AI teaches agent controls, Sovereign Stack the open-source stack, The AI Boardroom governance, Beyond the Benchmark evaluation, Twin & Machine physical AI. All five episodes this week are acts of reading the artifact in front of you.

Next week, this chapter teaches revocation: what actually stops an agent, how long the stop takes to propagate, and why the tested revocation is the only one that counts. Subscribe to follow the map as it fills in.

Cut in verification, and why

• A major cloud vendor's agent credential vault. Secondary summaries describe a service that captures a user's OAuth consent, stores the resulting access and refresh tokens alongside API keys and client secrets, and reuses them on later runs. That is this article's hop four stated by a vendor about its own product, and it would have been the strongest example in the piece. Every attempt to reach the vendor's own documentation failed with a connection reset to an automated client. Cut entirely, rather than cited to a secondary. The hop-four paragraph rests on a different vendor's release note, which was retrieved.
• The publication date printed on two individual advisory pages. An automated read of the two advisory pages returned June 2026, while two independent reads of the sorted advisory listing placed both under 25 August 2026. The sweep is cited to the reproducible query rather than to a date alone, and a human must read the date off the page in a browser before this publishes. Stated here rather than smoothed over.
• Any count of how many MCP server implementations in the wild validate token audience. Several secondary write-ups assert numbers. No primary measurement was found and none was conducted in this pass. Cut. The article states the requirement and its condition, and asks the reader to measure one deployment: their own.
• A removal date for Dynamic Client Registration. The specification marks it deprecated and the project's feature-lifecycle policy sets minimum periods before a deprecated feature becomes eligible for removal, but no removal date for this feature appears on a primary. Cut. The article says deprecated, and says what replaces it.
• Any claim about how a specific commercial agent platform stores or reuses a consented credential internally. Vendor internals are not public documentation, and public documentation is not internals. Cut. Every claim here is what a specification or a vendor's own release note says about itself.
• A second regional vendor record, from the Gulf or India. None was found at a primary in this pass, and manufacturing regional balance from a press summary would break the rule that every claim carries a live link to a primary. Cut. The regional paragraph makes the only claim the evidence supports, which is that the specification does not vary by jurisdiction.