Re-submission of #2777, which was closed and could not be reopened because the head fork had been deleted. Same commits (tip f27a859), same content; pushed from a freshly recreated fork. Apologies for the noise.

Summary

Adds a new Standards Track SEP: Attested Tool-Server Admission (ATSA).

New file: seps/0000-attested-tool-server-admission.md (I'll rename it to the PR number once assigned, per the SEP guidelines).

ATSA is an optional, purely additive admission layer. A server publishes a small, offline-signed clearance assertion at a well-known URI; a host verifies it against a locally pinned trust root before any tool dispatch; admitting a server is kept distinct from authorizing its tools via a closed per-server tool allow-list; and every admission decision is auditable. No existing MCP message changes shape — an unextended host ignores the mechanism and behaves exactly as today.

Motivation (the gap in the current spec)

A host today takes a server's identity and its advertised tools/list on faith, so a prompt-injected model can drive a destructive tool on any server it connects to. This is exploitable in every deployment, and disqualifying + unauditable for regulated operators (NIST SP 800-53 AC-3/AC-4/AC-6, AU-2/AU-9). TLS answers "did I reach the named endpoint"; the authorization profile answers "may this user use this server"; nothing answers the third question — is this server one the host is authorized to use as a tool provider, and at what sensitivity?

Why this belongs in the spec, not a per-vendor layer

It can be built above MCP today — but additive ≠ interoperable. Bolted on by one vendor, attestation secures only that vendor's island. The payoff ("attested" as a claim any host can check; servers publishing one document instead of N vendor dialects; SDKs shipping the gate on by default) only materializes once a single format is agreed, and only the spec owner can mint that Schelling point.

Evidence (written from a production prototype, not theory)

• Public reference implementation: https://github.com/enclawed/enclawed-oss — extensions/mcp-attested (plus a Google Workspace bridge in extensions/mcp-google-workspace). Includes a JSON Schema, an error registry, and machine-checkable conformance vectors.
• 48 hermetic tests covering every verification rule and the tool-authorization rule.
• LLM-driven adversarial campaign: 27,025 unique tool-name evasions + 14,378 unique forged clearance assertions — all denied, zero leaked network writes.
• Live end-to-end run against a real Google Workspace MCP endpoint: the allow-listed tool was admitted and dispatched; out-of-allow-list tools were denied before any network call.
• Companion preprint (full threat model, methodology, results): doi:10.5281/zenodo.20349263.

Backward compatibility

None broken. The assertion lives at a well-known URI (RFC 8615); the tool allow-list is host-side state; no existing message changes shape. Unextended hosts and servers are unaffected — incremental rollout.

Design-principles alignment

The SEP's Rationale maps the proposal to all eight MCP design principles and addresses the two most likely objections head-on — Composability over specificity ("can't this just be an extension?") and Stability over velocity ("permanent cost"). It leads with Demonstration over deliberation: the mechanism is already in production. It is also written to satisfy the SEP-2484 conformance requirement out of the box — every MUST/SHOULD is already enumerated as a vector in the reference implementation.

Sponsor

Seeking a sponsor — this sits in the security / authorization scope, and was raised in #security-ig and #auth-ig for validation. Happy to walk through it at a Core Maintainer meeting.

AI-assistance disclosure (per CONTRIBUTING.md)

The author originated and directed this work and independently verified every factual claim, citation, and normative statement; an AI agent was used only as a mechanical drafting aid.