SEP: provenance-carrying authority confinement for delegated tool calls - #3246

Adds an Extensions Track SEP proposing io.noescalation/provenance: a delegation-chain record carried in _meta on tools/call, and a rule for checking each call against the intersection of the bounds along that chain.

Motivation and Context

A tools/call arrives at a server with no record of the authority path that produced it. When a host delegates to a planner, the planner narrows a worker to one repository, and the worker then requests a different one, the request is well-formed and the credential is valid — the server has no basis to deny it. The narrowing existed only in the planner's intent, and the protocol carried nothing about it. This is the confused deputy, and it is not detectable at the tool boundary today.
Several recent proposals (AIP, ACP, the Five-Plane architecture) have independently converged on chain attenuation as the mechanism, but none specifies what it guarantees under composition, revocation, or concurrency — so implementations can diverge without any way to detect that they disagree about which calls are permitted.

How Has This Been Tested?

A reference implementation is at https://github.com/alinamiretai/no-escalation (proxy/, Python 3, no dependencies):
test_attacks.py — four delegation attacks, rejected fail-closed
test_multihop.py — multi-hop composition: a later hop's narrowing binds against an earlier broader grant
test_vectors.py — the conformance vector suite
test_meta_realhost.py — _meta acceptance verified against @modelcontextprotocol/server-filesystem
The property is machine-checked in Lean 4 (lean/, Mathlib-free, lake build reproduces): soundness, chain conferral, composition, revocation effectiveness, graceful degradation, and a concurrency result.

Breaking Changes

None. The extension is purely additive metadata under a reverse-DNS _meta key. Participants that do not implement it ignore the key and behave exactly as they do today. No new methods, message types, or schema changes.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• [+] New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• [+] Documentation update

Checklist

• [+] I have read the MCP Documentation
• [+] My code follows the repository's style guidelines
• [ +] New and existing tests pass locally
• I have added appropriate error handling
• [ +] I have added or updated documentation as needed

Additional context

Raised in the auth channel before filing. Seeking a sponsor — maintainers working on authorization, this may be in your area.
Open questions I'd particularly like review on: whether this sits on the communication side of the communication-vs-policy line; and whether chain integrity being out of scope in v1 (§4.5 — the trust model is stated explicitly rather than specified cryptographically) is acceptable for a first version.