MCP authorization · Runs 019–020
Control-plane boundaries are narrower than a connection demo.
A bounded localhost matrix exposed assurance, resource-binding, revocation and replay boundaries in one task-owned MCP authorization path.
Published 25 October 2026The boundary that matters
MCP authorization requires a resource parameter and access-token validation.[1] Enterprise-Managed Authorization describes an enterprise IdP issuing an ID-JAG that the MCP authorization server exchanges for an access token.[2]
RFC 9470 supplies step-up challenge vocabulary and retry shape, but the resource server still makes the policy decision about sufficient authentication strength.[3] The local matrix therefore separates protocol requirements from adapter behavior.
This is a bounded experiment report—not general MCP ecosystem conformance, production IdP evidence, replay protection or enterprise readiness.
What was tested
Run 019 used three distinct task-owned processes: an IdP, a resource authorization server and an MCP resource. The canonical resource identifier was http://127.0.0.1:18979/. The pinned Inspector EMA client used commit ae865a19178ddf6f375780a02e9c77c4cf4da184.[5]
The matrix covered assurance-level propagation, resource-identifier variants, wrong-resource and unsupported-scope requests, replay, revocation and a successful protected tool call.
Evidence matrix
| Case | Observed result |
|---|---|
| `loa2` requested | HTTP 302 callback; ID token carried urn:mcp:loa2 |
| `loa1` baseline | MCP initialization 200; high-risk route 401 |
| `loa2` requested, `loa1` asserted | HTTP 400 insufficient_user_authentication |
| Satisfied `loa2` path | MCP initialization 200; high-risk route 200 |
| Resource without trailing slash | HTTP 400 invalid_target |
| ID-JAG without trailing slash | HTTP 400 invalid_grant |
| Pinned Inspector EMA flow | Connected and called protected_read |
| Same bearer token twice | HTTP 200, then HTTP 200; replay accepted |
| Revocation | HTTP 200; later MCP initialization HTTP 401 invalid_token |
Interpretation
The `insufficient_user_authentication` response is an adapter policy observation, not proof of complete RFC 9470 conformance. Exact trailing-slash rejection is also adapter behavior; canonical resource identifiers matter, but this result is not a universal URI-normalization rule.[1][4]
The accepted replay is the negative control that prevents overclaiming. A successful EMA connection does not establish sender-constraining or single-use bearer semantics.
A bounded matrix can expose assurance, resource-binding, revocation and replay boundaries that a successful connection demo would hide.
Limits
One task-owned adapter and one pinned client/resource path.
Second resource-AS, external IdP, heterogeneous URI normalization, TLS, DCR, key rotation and production observability.
No sender-constraining, distributed revocation, cache staleness, partitions or replay prevention.
Useful negative-case evidence, not enterprise readiness or a universal MCP property.