The MCP 2026-07-28 Spec Hardens the Token. The Action Still Needs a Decision.

The Model Context Protocol specification dated July 28, 2026 tightens the authorization layer in four concrete ways, and teams running MCP in production should adopt all of them. Authorization servers must return the iss parameter and clients must validate it before redeeming a code, applying RFC 9207 and closing authorization-server mix-up attacks. Client credentials are bound to the issuer that minted them, ending reuse across authorization servers. Clients declare application_type during registration so servers handle localhost redirects correctly for desktop and command-line hosts. Dynamic Client Registration begins a formal deprecation in favor of Client ID Metadata Documents, with twelve months of backward compatibility.

The transport model changed alongside it. The initialize and initialized exchange and the Mcp-Session-Id header are retired. Each request carries protocol version, client identity, and client capabilities in _meta, and requests include Mcp-Method and Mcp-Name HTTP headers so gateways can route and authorize on headers without parsing the JSON body. Server-initiated requests are replaced by Multi Round-Trip Requests.

What the specification settles

The credential questions, and it settles them properly. Which client is this. Which issuer vouched for it. Whether a credential can be replayed against a different authorization server. Whether a gateway can make a routing and coarse authorization decision cheaply, at the edge, without deserializing a request body.

Those were real vulnerabilities. The move from Dynamic Client Registration to Client ID Metadata Documents in particular removes an entire class of registration abuse that had no clean mitigation. Header-based routing deserves specific credit: Mcp-Method and Mcp-Name give an enforcement point something to act on before the payload is trusted, which is the correct ordering.

What the specification does not settle

Whether the action is permitted. A validated, issuer-bound credential establishes that a known client is making a known call. It establishes nothing about whether the object that call concerns should be released to this requester, for this purpose, from this network, at this risk level, at this moment.

That gap is structural rather than an oversight. A protocol specification defines how parties talk. It does not and should not encode an enterprise's access policy. The consequence is that an MCP deployment can be fully compliant with the current specification and still hand an agent a document the requesting human could not have opened.

The failure mode is the one described in earlier coverage of the MCP blast radius. Authentication is not authorization. Presenting a valid credential is not the same as holding a current, evaluated decision about a specific object.

Where the decision belongs

At a policy decision point, evaluated per action, against attributes rather than a static grant. Lattix evaluates attribute-based access control across subject, device, environment and geography, purpose of use, network posture, risk, and the attributes of the data object, then returns a signed short-lived decision carrying the allow or deny, the reasons, and the hash of the policy version that produced it.

Enforcement happens at decrypt time at the policy enforcement point. That placement is what makes the control survive the architecture. An MCP server, a retrieval index, a message bus, and a downstream agent all sit between the request and the data, and none of them has to be trusted for the policy to hold, because the policy travels with the object rather than living in the service that happens to be serving it.

Defaults are fail-closed, and revocation propagates to deny. That last property is the one that matters most for agent deployments, because the interesting case is not a forged credential. It is a valid credential attached to an agent that has been subverted, which is the shape credential delegation chains take once they extend past a single hop.

Adoption guidance for teams running MCP

Adopt the specification changes on their own merits and treat them as the credential layer they are. Validate iss. Move off Dynamic Client Registration inside the twelve-month window rather than at the end of it, since the compatibility period is the migration budget and not a grace period. Use Mcp-Method and Mcp-Name at the gateway for coarse routing, rate control, and early rejection.

Then add the decision the specification leaves to the deployer. For each tool that touches regulated, classified, or customer data, identify what has to be true about the requester and the object for release to be lawful, express that as attribute policy, and place an enforcement point where the data is decrypted rather than where the request is received.

The specification is doing its job. The remaining work sits at the data boundary, and it belongs to whoever owns the data.