Governance as Infrastructure — What the MCP 2026-07-28 Migration Actually Demands of Permissions, Audit, and Lifecycle

1. Executive summary

The 2026-07-28 revision of the Model Context Protocol is the largest change since the protocol launched. Its headline is technical: the protocol core becomes stateless. The initialize handshake and the Mcp-Session-Id header are removed, and every request must now stand on its own. The temptation is to treat this as a transport problem — swap sticky load balancing for round-robin, add a shared store, upgrade the SDK, done.

That framing misses the point that matters for anyone operating more than a handful of connectors. When the session disappears, teams can no longer rely on prior protocol or connection state to carry that context implicitly. The session was not necessarily the source of identity or authorization in every implementation, but wherever a design leaned on it — for who is calling, on whose behalf, with what authority, as part of which task — that context now has to travel in the request itself, or be resolved from durable systems on every call. Statelessness does not remove governance. It relocates it: out of the transport and into the request, and out of an implementation detail and into infrastructure.

This paper argues that the 7-28 migration is best run as a governance program with a transport upgrade inside it, rather than a transport upgrade with governance bolted on afterward. It grounds the argument in an illustrative composite connector estate and organizes the work around three disciplines the new reality makes non-negotiable:

- Permissions: authorization that is proven per request, not inherited from a session.

- Audit: observability that survives the loss of the session as a correlation mechanism.

- Lifecycle: disciplined management of connectors, versions, and deprecations over time.

The through-line: in a stateless world, governance is not paperwork produced alongside the system. It is load-bearing structure the system runs on. Teams that build it as infrastructure will find the migration leaves their estate more operable than before. Teams that treat it as an afterthought will inherit an estate that scales horizontally and audits poorly — the worst of both.

2. What 7-28 changes — and why the mechanics are the easy part

The migration mechanics are well documented and, frankly, the least interesting part of the work. In brief, grouped by what they mean rather than the order they appear in the spec:

- The session is gone. The initialize / initialized handshake (SEP-2575) and the Mcp-Session-Id header (SEP-2567) are removed. Protocol version, client info, and capabilities now ride in _meta on every request, and a new server/discover method fetches capabilities on demand. Any request can land on any instance.

- Server-to-client prompts no longer need a held-open stream. Elicitations return as an InputRequiredResult carrying an opaque requestState the client echoes back on retry (SEP-2322, SEP-2260), so any instance can resume the exchange. Server-initiated requests are permitted only while a client request is being processed — every prompt now traces back to something a user or agent started.

- Traffic becomes routable, cacheable, and traceable at the edge. Mcp-Method and Mcp-Name headers are required so gateways can route, rate-limit, and screen without reading the body (SEP-2243). List and read results carry ttlMs and cacheScope (SEP-2549). W3C Trace Context — traceparent, tracestate, baggage — is standardized in _meta (SEP-414).

- State that must persist moves into the open. The recommended substitute for session state is the explicit-handle pattern: a tool mints an identifier (a basket_id, a browser_id) and the model passes it back as an ordinary argument on later calls. State becomes visible to the model — and, crucially for us, to audit — instead of hidden in transport metadata.

- Extensions become first-class (SEP-2133). They carry reverse-DNS identifiers, version independently, and live in their own repositories. Two ship official: MCP Apps (server-rendered UIs in a sandboxed iframe, whose every UI action goes through the same consent and audit path as a direct tool call) and Tasks (now an extension; task creation is server-directed, and tasks/list is removed because it cannot be scoped safely without sessions).

- Authorization is hardened toward real OAuth / OIDC deployments. Issuer (iss) validation per RFC 9207 (SEP-2468); explicit OIDC application_type at registration (SEP-837); credentials bound to the issuing authorization server, with re-registration required when a resource migrates between servers (SEP-2352); plus documented refresh-token and step-up scope behavior.

- A formal lifecycle now governs change. Every feature moves Active to Deprecated to Removed with at least twelve months between deprecation and the earliest possible removal. Roots, Sampling, and Logging are deprecated in this release (annotation-only for now). A Standards-Track change cannot reach Final without a matching conformance-suite scenario.

Notice how many of these "transport" changes are governance primitives wearing infrastructure clothes: a header you can authorize on, a cache scope that is really a tenancy boundary, a trace context that is really an audit spine, a handle that makes state auditable, a deprecation clock that is really a lifecycle contract. That is the whole thesis in miniature. The rest of this paper is about operating them deliberately.

Timeline note. The release candidate locked on May 21, 2026; the final specification publishes on July 28, 2026. As of this writing, SDK support is arriving inside that validation window rather than being uniformly available — which has direct sequencing consequences for a migration, covered in section 6.

3. The grounding case: an illustrative enterprise estate

Rather than reason about a tidy hypothetical with three well-behaved connectors, this paper uses an illustrative composite estate. It combines common patterns from larger MCP deployments, including repeated environment variants, mixed ownership, and uneven documentation. It is not a reference architecture or a description of a specific organization or completed migration.

Shape of the estate, as configured:

- Around 50 connected MCP server endpoints, mostly first-party cloud services, with a smaller set of external SaaS connectors.

- Around 100 tools across several servers, with additional tools loaded on demand rather than exposed up front.

The part that matters for governance is duplication and mixed maturity:

- The same logical connector appears many times, once per environment. One creative application shows up as PreProd, QA, Stage, a first-party Stage, a second Stage, and two production-flavored variants — roughly seven endpoints for one product. A content-management platform sprawls across a dozen endpoints (base, stage, content dev / stage / prod, a delivery-prod, a governance endpoint, and four dev / qa / stage / prod variants of a sub-system). Others repeat as dev / stage / prod or preview / stage / prod triplets.

- Maturity is mixed and not obvious from the outside. Some endpoints are clearly production; others are stage, dev, devtest, preview, or first-party staging; at least one is a QA endpoint pointed at a shadow host. Nothing in the connection list tells an operator which endpoints are authorized for production traffic, which handle regulated data, who owns each, or which are stale.

This is the ordinary condition of an enterprise MCP estate a year and a half into adoption: many connectors, many environments, many owners, uneven documentation. It is exactly the condition in which "just upgrade the transport" fails — not because the transport change is hard, but because you cannot safely change what you cannot enumerate, classify, and attribute. And the first casualty of statelessness in an estate like this is any control that quietly depended on the session to know who and what it was dealing with.

Illustrative status. This is a composite example, not a description of a specific deployment or completed migration. The figures are rounded to show scale and shape rather than report audit findings. The gap between a connection list and a governed inventory is itself the first finding of the next section.

4. The thesis: statelessness relocates governance into the request

In many implementations the session was doing quiet governance work. Removing it surfaces four things designs often leaned on it to carry:

- Identity continuity. Where a design pinned the caller's identity to the session at initialize, downstream calls inherited it for free.

- Authorization context. Grants, scopes, and consent obtained during a session were often assumed to hold for its duration.

- Task correlation. Everything within a session was trivially correlatable as "one interaction" — the backbone of any audit trail.

- State ownership. The instance holding the session was typically the de facto owner of in-flight context.

Remove the session and each of these becomes an explicit design decision on every request. Identity must be presented or resolved per request — there is no "we already know who this is." Authorization must be provable per request. A gateway can no longer assume that because a session was allowed in, this call is fine. Provable per request is not a small change in an agentic estate, because agents make one authorization decision per tool call rather than one per user action, and a single task can fan out into dozens. The decision point stops being an occasional check and becomes a service tier on the hot path of every call, which is the subject of section 5.1. Correlation must be manufactured rather than inherited, which is exactly why the spec promotes W3C Trace Context to first-class and why tasks/list was removed: it could not be scoped safely without a session. And state must live in durable, ownable systems, referenced by explicit handles that are visible and therefore governable.

Here is the reframing that makes the migration tractable. The same properties that make a stateless request scale horizontally — self-contained, routable, cacheable — are the properties that make it governable: attributable, authorizable, auditable. Scale and governance come from the same design act. Skip that act and you get scale without governance: instances multiply, requests fan out across them, and no single place holds the context to say who did what. That is the failure mode to design against.

Hence the title. Governance as infrastructure is not a policy document or a review board's output. It is a set of concrete, load-bearing components: an identity that propagates, a policy decision point at the edge that reads Mcp-Method and Mcp-Name, a trace spine that every call joins, a handle registry with ownership and expiry, and a connector inventory that is the source of truth for what may run. In the 7-28 world, those components are your infrastructure and your governance at the same time.

5. The three disciplines

5.1 Permissions: authorization proven per request

The session removal (SEP-2567, SEP-2575) is usually read as a transport change. For authorization it is the most consequential change in the release. Wherever a design let identity and grants ride the session, authorization was being amortized: prove who the caller is once at initialize, and every downstream call inherits that decision for free. Remove the session and that amortization is gone. There is no longer a place to answer "who is behind this call, on whose behalf, with what authority" once and reuse it. The answer has to be produced on every request, or it is not being produced at all.

That reframes authorization from a config concern into an infrastructure one. The governing detail is volume. Agentic workloads do not make one authorization decision per user action; they make one per tool call, and a single task can fan out into dozens. So the thing that answers the authorization question is not a check you run occasionally. It is a service tier on the hot path of every tool call, at tool-call latency, at tool-call scale. If it cannot answer in single-digit milliseconds thousands of times per task, teams will route around it, and routing around it means falling back to the one control this paper names as the most corrosive: a broad standing credential that stands in for the caller. Per-request authorization and the stand-in credential are the two ends of the same decision. You get one or the other.

The concrete controls:

● Per-request identity propagation. Adopt a single answer to "who is behind this call" for every request: end-user identity, agent identity, workload identity, and the delegation chain between them. The session is no longer available to carry any of these, so each must be presented in the request or resolved from a durable identity system on every call. No broad shared service credential standing in for a user. This is the highest-leverage control in the migration, because almost every other permission failure is downstream of getting it wrong.

● The delegation chain is the hard part, and it is where coarse models break. "A user asked an agent, which called a workload, which invoked a tool on the user's behalf" is four identities and a chain of authority between them, and 7-28 makes that chain explicit rather than implied by a session. A role check cannot express it: roles answer "what may this principal do," not "may this agent take this action, on behalf of this user, against this specific resource, right now." What the stateless model needs on every call is a decision over the relationship between the caller, the resource, and the on-behalf-of chain. A per-request check over identity, action, resource, and the delegation chain is what relationship-based authorization models are built to answer: instead of asking "what may this role do," they evaluate whether a specific subject stands in an authorized relationship to a specific resource for a specific action. That is the shape of the question a stateless estate asks on every call, and it is answerable at request latency when the authorization system is designed for it rather than bolted on.

● A policy decision point at the edge, with its limits stated. The required Mcp-Method and Mcp-Name headers (SEP-2243) exist so gateways can route and rate-limit without reading bodies. Once the caller is authenticated, those headers can also drive coarse gateway policy: allow or deny by identity, server, method, and tool name. They are client-supplied routing hints, not trusted authorization evidence on their own, so the coarse edge decision is a filter, not the authorization. Fine-grained authorization still has to be applied to the actual operation and resource inside the tool, against the real arguments. The spec already requires servers to reject requests whose headers and body disagree. Treat that mismatch as a security event, not a 400.

● Issuer discipline. Validate iss on authorization responses (RFC 9207, SEP-2468) now. The single-client, many-server shape of an MCP estate is exactly what mix-up attacks exploit, and a host wired to dozens of servers is a textbook instance. Plan for the near future in which responses lacking iss are rejected outright rather than warned on.

● Credential binding and re-registration as a migration event. Credentials bind to the issuing authorization server's issuer, and a resource moving between authorization servers requires re-registration (SEP-2352). Migration is precisely when resources move between servers, so "which authorization server issued this, and is it the right one for this environment" becomes a recurring runbook question rather than a one-time setup step. Put re-registration in the runbook rather than discovering it in an outage.

● Scope minimization and step-up. Prefer narrow scopes and step-up (SEP-2350) over broad standing grants. Removing the session also removes the excuse that "we already escalated earlier in this session," because there is no earlier to lean on. Every escalation is per-request and every escalation is logged.

● The handle pattern needs its own authorization. The explicit-handle substitute for session state is the right pattern, but a handle is a capability, not a convenience. If create_basket mints a basket_id and add_item accepts it, add_item must verify the caller is entitled to that specific handle. Skip that and you have not removed session fixation, you have replaced it with handle forgery. Treat handles as scoped, owned, and expiring, and authorize the handle on every call that consumes it. A handle is a relationship between a caller and the resource it points at, so authorizing it per call is the same fine-grained decision as everything above: does this subject stand in an authorized relationship to this capability, right now. Nothing about the handle pattern requires a new authorization mechanism; it requires applying the per-request one you already need.

The through-line for the section: in a stateful world you could authorize once and coast. In the 7-28 world every call is its own authorization decision, over a delegation chain a role model cannot express, at a volume that makes the decision point real infrastructure. Build that decision point deliberately and the estate is governable by construction. Skip it and horizontal scale just means the stand-in credential runs everywhere at once.

5.2 Audit: observability that survives the loss of the session

- W3C Trace Context is the correlation layer, not the audit trail itself. Fixed in _meta (SEP-414), it lets a single interaction be followed from host to client SDK to server to downstream systems as one span tree in an OpenTelemetry-compatible backend, and it replaces the session as the way to correlate activity across services. It does not by itself provide a complete or durable audit trail: traces are typically sampled and short-lived, and a span records timing and structure rather than the full account. Propagate it on every call and stamp the trace id onto every audit record, so records written independently by each service can be matched up; a call without trace context is a gap in correlation, not the same as a missing audit record.

- The audit trail itself is the set of durable, structured records you write per request. A stateless architecture only audits well if each request emits its own record — the complete, retained account of who did what, on whose behalf, and under which policy decision — rather than leaving it smeared across interchangeable instances. Those records are what use the trace id above to correlate across services. The minimum fields are set out in Appendix B.

- Audit the edge, not just the tool. The gateway is a coarse filter (5.1), so a call it denies never reaches the tool that would have recorded it. Have the gateway emit its own allow / deny record carrying the same trace id — otherwise edge denials, often the most security-relevant events, leave no record at all.

- MCP Apps ride the same audit path — keep it that way. Server-rendered UI actions go through the same consent-and-audit path as direct tool calls. That is a gift: do not let a UI action become an unaudited side channel. Every button in an MCP App should be as traceable as a direct call.

- Retire ad-hoc logging in favor of structured observability. With Logging deprecated (replacement: stderr for stdio transports, OpenTelemetry for structured observability), standardize now on OTel-structured audit rather than bespoke per-connector logs. Across dozens of connectors, uniform audit is the only kind you can actually query during an incident.

- Correlation is manufactured now — budget for it. There is no session to group "one interaction" for free. Agentic workloads generate many short-lived calls, so the audit tier is a real service tier that must keep up at tool speed. Design it to, and load-test it like one.

5.3 Lifecycle: connectors, versions, and deprecations over time

- Inventory is the precondition for everything. You cannot govern around 50 endpoints and 100-plus tools you have not enumerated, classified, and attributed. Build a connector registry that is the source of truth: for each endpoint, its environment, owner, authorization server, data sensitivity, spec and extension versions supported, and current lifecycle state. A connection list is not an inventory; the delta between the two is your first backlog.

- Collapse environment sprawl deliberately. Seven endpoints for one product and a dozen for another are a governance liability, not just clutter: each is an attack surface, an audit source, and a credential to rotate. Migration is the moment to decide which environment variants are authorized to persist, which are decommissioned, and which are consolidated — and to make "which environment am I calling" an explicit, enforced property rather than a guess from a display name.

- Adopt the spec's lifecycle policy as your own operating model. The protocol now guarantees Active to Deprecated to Removed with at least twelve months between deprecation and removal. Mirror that internally: no connector or tool goes from "in use" to "gone" without a published deprecation, a named replacement, and a window. Your consumers — agents and their authors — deserve the same contract the protocol gives you.

- Treat cacheScope and ttlMs as lifecycle and tenancy controls. Whether a tools/list may be shared across users (cacheScope) is a tenancy decision; how long it stays fresh (ttlMs) is a change-management decision. Set them per connector on purpose. A permissive cacheScope on a connector whose tool list varies by a user's entitlements is a cross-tenant leak wearing a performance optimization's clothes.

- Migrate deprecated capabilities on a clock, not on breakage. Roots, Sampling, and Logging are deprecated (annotation-only today, with a twelve-month floor before any removal). Inventory their use across connectors now and schedule replacement — Roots to tool parameters, resource URIs, or config; Sampling to direct LLM-provider APIs; Logging to stderr and OTel — rather than waiting for a future release to force it. Anyone who shipped against experimental Tasks must move to the new server-directed lifecycle and stop relying on tasks/list.

- Version connectors against the conformance suite. A Standards-Track change now cannot be Final without a conformance scenario, and official SDKs are scored on tiers. Record which spec version each connector supports, prefer connectors backed by higher-tier SDKs for critical paths, and gate promotion to production on conformance rather than "it worked in a demo."

- Extensions version independently — govern them independently. MCP Apps, Tasks, and future extensions carry reverse-DNS IDs and their own version streams. Track extension versions per connector as first-class inventory; do not assume that "on 7-28" tells you which extension versions are in play.

6. A migration operating model

Five phases, each producing a governance artifact and mapped to the estate. The important design choice is sequencing: the governance work runs across the whole estate immediately, while cutover happens per connector as SDK support lands.

Phase 0 — Enumerate (turn the connection list into an inventory).Populate the connector registry for the full estate and its deferred-tool servers: owners assigned, environments and data-sensitivity classified, spec and extension versions recorded. This is the gate. Nothing else starts until it is done for at least the production-critical subset. Output: a populated registry that is the source of truth.

Phase 1 — Classify and prioritize. Rank connectors by blast radius — production, regulated data, and high call volume first. Identify the environment variants to retire. Flag connectors using deprecated capabilities (Roots, Sampling, Logging) and experimental Tasks. Output: a migration order and a decommission list.

Phase 2 — Instrument before you change (make it observable). Turn on W3C Trace Context propagation and structured OTel audit across the estate while it is still on the old spec. You want the audit spine in place before behavior changes, so you can compare before and after and so nothing goes dark mid-migration. Output: uniform trace and audit coverage, plus a baseline.

Phase 3 — Enforce at the edge. Stand up the gateway policy decision point on Mcp-Method and Mcp-Name; wire per-request identity propagation; enforce iss validation and credential-to-issuer binding; add handle authorization. Introduce the explicit-handle pattern in tools — it works on today's SDKs and survives the upgrade — and back handles with shared storage. Keep load-balancer stickiness only as a temporary bridge. Output: authorization proven per request; the estate ready to run stateless.

Phase 4 — Cut over and decommission. As SDK support lands per connector, drop the session dependency and the stickiness bridge — in practice, removing an ingress annotation once the code already threads handles. Re-register credentials where resources moved authorization servers. Retire the environment variants and deprecated-capability usages on their published clocks. Output: a smaller, enumerated, per-request-governed estate on 7-28.

Sequencing reality. SDK support arrives inside the validation window rather than all at once, so cutover (Phase 4) is per-connector and staggered, while the governance work (Phases 0-3) can and should proceed across the whole estate immediately and independently of SDK readiness. Do the governance now; cut over as each SDK is ready. The bridge pattern — shared store, temporary stickiness, and explicit handles — lets old and new coexist without a flag day.

7. Controls checklist

A practical control set, with the discipline it belongs to, a suggested owner, and the evidence that shows it is actually in place. Owners are indicative; adapt to your org.

- Per-request identity propagation, with no shared service credential behind tool calls. Permissions. Owner: platform + IAM. Evidence: gateway config; audit shows distinct caller identities.

- iss validation on every authorization response. Permissions. Owner: IAM. Evidence: authorization server returns iss; client rejects missing (roadmap).

- Credential-to-issuer binding and a re-registration runbook. Permissions. Owner: IAM + connector teams. Evidence: runbook; re-registration logs at cutover.

- Edge policy decision point on Mcp-Method / Mcp-Name. Permissions. Owner: platform. Evidence: gateway policy; header/body-mismatch alerts.

- Handle authorization on every handle-consuming call. Permissions. Owner: connector teams. Evidence: tool tests proving forged-handle rejection.

- W3C Trace Context propagated on every call. Audit. Owner: observability. Evidence: coverage dashboard; orphan-trace alerts.

- Durable, structured audit record per request. Audit. Owner: observability. Evidence: record-schema conformance; retention policy.

- MCP App UI actions on the same audit path. Audit. Owner: connector teams. Evidence: audit shows UI-initiated actions.

- Connector registry as source of truth (environment, owner, authorization server, sensitivity, spec/extension version, lifecycle state). Lifecycle. Owner: platform. Evidence: registry populated for all endpoints.

- Environment-variant consolidation / decommission plan. Lifecycle. Owner: platform + connector teams. Evidence: decommission list with dates.

- cacheScope / ttlMs set intentionally per connector. Lifecycle. Owner: connector teams. Evidence: no cross-tenant cache on entitlement-varying lists.

- Deprecated-capability replacement on a clock. Lifecycle. Owner: connector teams. Evidence: usage inventory plus scheduled removal.

- Spec-version, SDK-tier, and conformance gate for production promotion. Lifecycle. Owner: platform. Evidence: promotion checklist.

8. Anti-patterns to design against

- Transport tunnel vision. Fixing stickiness and calling it a migration, while the governance relocation goes entirely unmanaged.

- The stand-in credential. One broad service credential behind every tool call — scale without accountability. The single most corrosive anti-pattern, because it makes every other control unenforceable.

- Session amnesia mistaken for context loss. Treating "stateless" as license to forget task context, instead of moving that context to durable stores and explicit handles.

- The unaudited handle. Accepting a minted handle without authorizing the caller against it — session fixation replaced by handle forgery.

- The permissive cache. A cross-user cacheScope on an entitlement-varying tool list — a tenancy leak dressed as a performance win.

- Environment roulette. Not knowing whether a call hits dev, stage, or prod because the only signal is a display name.

- Sprawl left standing. Carrying seven endpoints for one product through the migration because retiring them felt out of scope.

- Building on the unreleased. Making production commitments against spec behavior before it ships and before your SDK supports it. Treat future specs as direction and released specs as contracts.

- Audit that cannot keep up. An audit tier that works for human-paced use and collapses under agentic call volume.

9. What to do now

Immediately, independent of SDK readiness:

- Stand up the connector registry and assign an owner to every endpoint.

- Turn on W3C Trace Context propagation and structured OTel audit across the estate.

- Inventory usage of deprecated capabilities (Roots, Sampling, Logging) and experimental Tasks.

- Begin validating iss on authorization responses.

Before cutover:

- Build the edge policy decision point on Mcp-Method / Mcp-Name.

- Implement per-request identity propagation and retire shared service credentials.

- Introduce explicit handles backed by shared storage; add handle authorization.

- Publish internal deprecation clocks for the environment variants and capabilities you will retire.

At cutover, per connector, as SDKs land:

- Drop load-balancer stickiness and the session dependency.

- Re-register credentials where resources changed authorization servers.

- Decommission retired environment variants.

- Verify audit continuity before and after the switch.

The one-sentence version. Do the governance across the whole estate now, on the old spec; cut the transport over per connector as each SDK is ready — and treat the identity, trace, handle, and inventory work not as migration overhead but as the infrastructure the stateless estate will run on.

Appendix A. Change to governance map

Each 7-28 change and the governance obligation it creates or enables. SEP numbers are given for traceability back to the specification.

● Session and handshake removed (SEP-2567, SEP-2575): identity, authority, and task correlation can no longer be inherited from a session. Each must be presented or resolved on every request, which makes per-request authorization a hot-path decision rather than a one-time check.

● server/discover and client info in _meta (SEP-2575): capability discovery becomes an explicit, per-need call, a point at which what a client may see can be logged and authorized.

● Mcp-Method / Mcp-Name headers required (SEP-2243): gives the gateway a body-free routing key, and therefore a coarse authorization and rate-limit surface, for every operation.

● InputRequired plus requestState; prompts only during active requests (SEP-2322, SEP-2260): every elicitation is resumable on any instance and traces to a user-initiated action; nothing prompts out of band.

● ttlMs and cacheScope on lists and reads (SEP-2549): freshness becomes a change-management control; cross-user sharing becomes an explicit per-connector tenancy decision.

● W3C Trace Context standardized in _meta (SEP-414): provides the correlation spine that replaces the session for audit, one span tree from host to downstream.

● Explicit-handle pattern (guidance): application state becomes visible and referenceable, and thus governable, but each handle is a capability, and authorizing it per call is the same per-request relationship decision as any other authorization in the estate.

● Extensions, MCP Apps, Tasks (SEP-2133, SEP-1865, Tasks extension): capabilities version independently and must be inventoried per connector; UI actions ride the same consent and audit path; tasks/list is gone because it cannot be scoped without a session.

● Authorization hardening: iss, application_type, credential binding (SEP-2468, SEP-837, SEP-2352): mix-up-attack mitigation for the single-client, many-server shape of an MCP estate; migrating a resource between authorization servers is an explicit re-registration event, and migration is when that happens most.

● Feature lifecycle; Roots / Sampling / Logging deprecated (SEP-2577): a twelve-month Active-to-Deprecated-to-Removed contract to mirror for your own connectors; schedule replacement of deprecated capabilities on a clock.

Appendix B. Minimum audit record

The fields a per-request audit record should carry in a stateless estate, and why each earns its place.

● Caller identities and delegation chain. Not a single principal but the full chain: end-user identity, the agent identity acting for them, the workload identity the agent invoked through, and the on-behalf-of links between them. This is the answer to "who did this, on whose behalf, under what authority" that the session no longer carries. Record it as a chain rather than a flattened "actor" field, because a flattened identity cannot be reconciled against the per-request authorization decision in 5.1, which was made over the chain, not over one principal.

● Server, method, and tool name. The operation, mirrored from Mcp-Method and Mcp-Name so gateway logs and application logs reconcile against the same call.

● Input parameters. The arguments, with sensitive fields redacted or tokenized per policy.

● Handles minted, read, and authorized. Which capability identifiers were created or consumed on this call, and the authorization result for each handle consumed. A handle is a capability, so an audit record that notes a handle was used without noting whether the caller was entitled to it cannot distinguish legitimate use from handle forgery. Record the handle, its owner, and the per-use authorization decision together.

● Policy decision and basis. Allow, deny, or step-up, plus the specific rule, relationship, or scope that decided it. In a relationship-based model this is the subject, resource, action, and the relationship that granted or refused the call, not just a rule id. This field is what makes an authorization decision reviewable after the fact rather than merely logged, and it is what a compliance reviewer actually reads.

● Assets and data version. Datasets, scopes, or resources touched, and where relevant the snapshot or version read.

● Result status. Success, error code, or partial. Note the missing-resource code is now -32602, not the old -32002.

● Trace and correlation id. The traceparent linking this call to the wider task. Stamp it onto the audit record itself, not only into the trace context, so the short-lived trace and the durable audit record can be matched during an incident. A record that carries the delegation chain but not the trace id cannot be followed across services.

Appendix C. Sources

Primary specification and community field reports consulted for this paper. The specification blog is authoritative for the change list; the community pieces supply operational and data-platform framing.

- Model Context Protocol Blog — "The 2026-07-28 MCP Specification Release Candidate" (D. Soria Parra, D. Delimarsky), blog.modelcontextprotocol.io.

- Alex Merced — "What the Stateless Spec Means for Data Platforms," iceberglakehouse.com.

- Sai Nitesh Palamakula — "MCP Goes Session-less: What the 2026-07-28 Release Candidate Actually Changes," medium.com.

- Microsoft Community Hub (Apps on Azure) — "MCP Just Went Stateless: What the 2026 Spec Changes About Scaling on App Service."

- Model Context Protocol organization and specification repositories, github.com/modelcontextprotocol.