SEP-2624: chain-free consolidation of the interceptors SEP (draft)

[wi-ski]

What this revises

This revises the SEP body to complete the removal of the "chain" concept the Interceptors WG agreed to on the 2026-07-23 call, while keeping all of its mechanics. Chain execution had already been downgraded from a protocol method to a utility; this finishes the job: the wire protocol carries only unit operations (interceptors/list + interceptor/invoke), and multi-interceptor behavior is expressed as an invoker-local execution plan — never a protocol object.

Credit where due: Ukjae Jeong proposed removing the chain concept; Kurt Degiorgio and Peder Holdgaard Pedersen agreed to "eliminate the chain concept but keep the mechanics." Logged as a WG action item.

What it does (and does not)

• Strictly subtractive on the concept — removes the four chain pseudo-interfaces and the Chain Execution section; the ordering, atomicity, and failure-routing guarantees are preserved as invoker obligations in one self-contained Execution Model section (the sole normative home).
• Adds no wire surface — no new JSON-RPC method, request/response shape, pseudo-interface, or schema.
• Changes no mode naming — active / audit only, fail-closed default; audit never blocks.
• Removes attestation — the reserved signature field is gone; attestation is a separable design for a future track (per the July scope discussion).
• Net normative improvements (so this reads as tightening, not weakening): direction is now separated from phase with a MUST NOT infer direction from phase (the fix for the C#/Go divergence and the ordering bug flagged on-call); equal-priority ordering uses locale-independent Unicode comparison instead of ambiguous "alphabetically"; failure routing (mode × failOpen × severity, cancelled invocations, aggregate deadline) is made internally consistent; and every Execution Model MUST is wire-observable at a mock host, so the SEP-2484 conformance story maps onto it one-to-one.

Open questions for the WG (please weigh in)

These are decisions the SEP deliberately does not make unilaterally — flagging them for the group rather than silently choosing:

1. Error-response governance. v1 scopes the trust-boundary guarantee to successful result payloads; JSON-RPC error responses (carrying error, no result) are not intercepted, and are listed under Not specified with a SHOULD-not-smuggle note. Should v1 govern error payloads, or is deferring correct? (Governing them adds surface; the honest v1 position is to scope the claim and not overpromise — but this is the group's call.)
2. SEP-2133 reference-implementation gate — process ruling needed. The gate ("a reference implementation in an official SDK prior to review") is not yet met: the work is in flight as #13 (TypeScript SDK, draft) and #31 (conformance suite, draft). Does SDK code merged in the extension repository discharge the gate, or must it land in the official SDK repository proper? The SEP names the intended landing target and self-blocks advancement until this is resolved.
3. llm/completion payload schema. The one non-MCP event in the v1 union has no pinned schema yet. The SEP carries a self-resolving fallback: if the schema is not pinned when formal review begins, the event drops out of the v1 union and remains expressible as a custom event, changing no other rule. Pin the schema or accept the drop?
4. Track: Standards → Extensions. The header now reads Extensions Track (SEP-2133 designates extension SEPs as such, and the promotion-to-core endgame only parses this way). PR #2624 currently declares Standards Track — flagging so the sponsor ratifies or vetoes the change in review rather than discovering it.
5. Extension Maintainers. SEP-2133 requires the SEP to name the responsible WG and Extension Maintainers. The Consensus section names the Interceptors WG and points at SEP-2148 for appointment; individual maintainers still to be named by the group.
6. Pure-discovery fail-closed posture. Discovery-failure fail-closed applies to policy-designated interceptors; a pure-discovery invoker cannot be fail-closed by construction, so the SEP SHOULDs policy designation for security-critical boundaries. Should this be strengthened to a MUST for security-critical governance?

Status / ask

This is a Draft-stage revision. The ask today is feedback + the one process ruling (Q2) — not a formal-review trigger: the SEP-2133 reference-implementation gate is genuinely unmet and the document self-blocks on it (Q2/Q3/Q5). Pushing the revision to the Draft PR is safe and correct; advancing past Draft is gated on the items above.

Housekeeping

• AI-assisted drafting disclosure (per CONTRIBUTING): portions of this revision were drafted with AI assistance and reviewed by the author.
• An independent conformance run of the Initial implementation of TypeScript SDK #13 TypeScript SDK against the shared SEP-2624 fixtures is available (24/24) as supporting evidence for the reference-implementation track.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Copilot wasn't able to review any files in this pull request.

[Degiorgio]

Thanks for taking this one on @wi-ski!

My only ask is scope, beyond relocating the chain mechanics it also adds a fair bit of new normative surface that isn't strictly needed to remove the "chain" concept.

Can we keep this PR to just the chain removal and minimise churn?

[dgenio]

One part of this rewrite is worth preserving even if the PR is narrowed: the post-mutation authorization invariant in Security Implications.

In a production MCP deployment with per-principal discovery filtering and resource-level authorization, filtering "tools/list" reduced exposure and model confusion, but it could not act as an authorization grant. A caller can invoke a tool directly, and authorization may depend on the final resource, tenant, or other arguments—not only the method name.

The current SEP head mandates "Receive → Validate → Mutate → Process", while mutators may replace the complete payload. Without an explicit final-operation rule, a validator can allow payload A while local processing executes payload B. We had to bind authorization to the effective principal and final post-mutation operation and arguments immediately before protected handler dispatch.

This rewrite’s requirement that authorization checks apply to the post-mutation payload at the enforcing boundary is the smallest correction I can see. It adds no wire surface and does not require another generic interceptor pass.

I would retain it and, if useful, clarify two related boundaries:

• discovery-time filtering is least-exposure and model guidance, not authorization;
• a receiving-side mutator that can change authorization-relevant fields is part of the authorization trusted computing base.

Identity acquisition and policy-language design can remain outside this SEP.

Disclosure: I used ChatGPT/Codex to help research the current SEP, working-group material, and draft this comment. I verified the technical claims and remain responsible for them.