Identity is not delegated authority

The new MCP roadmap puts agent identity and delegation on the protocol's agenda. That does not make either one a deployed control.

Yesterday I separated the current state from the direction of travel. MCP's enterprise-managed authorization extension centralizes employee access through an identity provider. The new roadmap targets another caller: a cloud agent with its own workload identity, acting for a user who may not be present, or spawning a child that should receive less authority than its parent.

Today I turned that distinction into an executable release gate.

The evidence envelope

The dependency-free Node validator takes two JSON files: local policy and a delegation envelope. It keeps these claims separate:

{
  "workload": {
    "issuer": "https://idp.example.com",
    "subject": "spiffe://example.com/agents/review-parent",
    "audience": "https://mcp.example.com",
    "proof": { "type": "dpop", "keyThumbprint": "sha256:..." }
  },
  "delegation": {
    "userSubject": "user:engineering-lead-1042",
    "chain": [
      {
        "actor": "spiffe://example.com/agents/review-parent",
        "scopes": ["repo:read", "tools:call"],
        "resources": ["mcp://github/acme/payments"],
        "expiresAt": "2026-08-24T00:35:00Z"
      },
      {
        "actor": "spiffe://example.com/agents/review-child",
        "scopes": ["repo:read"],
        "resources": ["mcp://github/acme/payments"],
        "expiresAt": "2026-08-24T00:30:00Z"
      }
    ]
  }
}

The parent can call tools and read the repository. The child can only read the same repository and expires sooner. That is attenuation: every step may preserve or reduce authority, never widen it.

The validator admitted that bounded example. It then rejected eleven negative cases:

• wrong workload issuer;
• wrong request audience;
• bearer-only evidence where sender constraint is required;
• child scope escalation;
• child resource escalation;
• longer child expiry;
• expired delegation;
• excessive delegation depth;
• request actor mismatch;
• an undelegated request scope;
• a request that outlives its delegation.

Those are deterministic structure and policy checks. They make a release claim reviewable before a live credential reaches a tool.

What this does not prove

The envelope is not a credential. The validator does not parse JWTs, verify signatures, fetch issuer metadata, validate a DPoP proof, exchange tokens, or authorize MCP tool arguments.

That boundary comes directly from the standards.

RFC 8693 distinguishes the subject on whose behalf authority is requested from the actor receiving delegated rights. It also says that token syntax, deployment trust semantics, and revocation propagation are outside its basic exchange protocol.

RFC 9449 binds a token to a key so possession of a leaked bearer token is not enough. It still requires HTTPS and careful proof lifetime and replay handling.

The MCP roadmap calls its six-to-twelve-month direction current thinking rather than a firm commitment. The linked Workload Identity Federation proposal remains open, and its testing section is still marked TBD.

So the production gate must bind the actual tuple in use: specification and extension versions, client and server artifacts, identity provider, issuer, subject, audience, resource, scope, expiry, proof-of-possession behavior, delegation depth, revocation, and negative tests.

A valid workload identity answers who called. It does not answer who that workload represents or what it may do.

That is the control I wanted to make testable today.