SEP: Align text with WG decisions on out-of-process execution and config

[olaservo]

Text-only changes to docs/sep.md from the 7/23 and 8/18 WG meetings. No wire changes; SDKs are unaffected.

• Interceptors always run out of process as MCP servers (7/23 Peder; 8/18 Sambhav, Peder, confirmed for Clare). Replaces the "first-party / in-process" wording in Key Advantage 3, the threat-model mitigation, and the sidecar YAML comments with local (stdio) and remote (Streamable HTTP) MCP servers.
• Defines Interceptor Server and adds SHOULD NOT co-host tools, prompts, or resources (8/18, Peder's proposal, Sambhav and Clare agreed).
• States that per-invocation config exists for statelessness, server defaults apply when omitted, and a server MAY expose no configurable settings (8/18, Sambhav answering Clare).
• Gives ChainExecutionParams.context the same principal.claims, spanId, and sessionId fields as InterceptorInvocationParams.context (also raised by the Tersign comment on PR #2624).
• Uses interceptors/list consistently in diagrams and prose. interceptor/invoke is left as is pending a WG decision on the plural form raised by a-akimov on PR #2624, since that one touches SDK constants.

Not in this PR: deployment architecture section, diagram replacement, stripping implementation detail (Sambhav and Clare, 8/18), and anything in the chain section pending #33.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NrQ4aQW4mRjgj5GJZbahEB

[Copilot]

Pull request overview

Aligns the interceptor SEP with working-group decisions on deployment, configuration, context fields, and method naming.

Changes:

• Defines local and remote out-of-process Interceptor Servers.
• Clarifies per-invocation configuration and context.
• Standardizes interceptors/list references.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

docs/sep.md:1757

• This mitigation says the interceptor receives only payload and context, but InterceptorInvocationParams also sends per-invocation config (line 699), along with other invocation metadata. That makes the threat model understate what a compromised interceptor can observe, especially when configuration carries sensitive policy values. Describe the address-space isolation without limiting the visible data to those two fields.

- Interceptors run out of process and receive only what is passed in `payload` and `context`; a local stdio interceptor still inherits the environment and filesystem access of the process that launches it, so it SHOULD be isolated accordingly

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

docs/sep.md:138

• This new unconditional out-of-process requirement contradicts the PR's claim that SDKs are unaffected: the Go SDK's primary Extension.LocalChain path installs interceptors on the invoking mcp.Server and connects through mcp.NewInMemoryTransports() in the same process (go/sdk/interceptors/extension/server.go:116-124), and its conformance documentation explicitly labels this an in-process deployment. Either update/remove that SDK path and its documentation or qualify this requirement; otherwise the SEP immediately makes the repository's reference implementation nonconformant.

An **Interceptor** is an MCP primitive that provides governance for context operations through validation or mutation logic. Like tools, prompts, and resources, interceptors are discoverable, and hosted on MCP servers. Interceptors are always invoked over an MCP transport; they do not run inside the invoking client or server process.

docs/sep.md:1710

• The two names do not both mirror the cited MCP pattern: tools/list and other primitive methods use a plural namespace, while the retained interceptor/invoke is singular and explicitly remains pending a WG decision. Reword this rationale so it does not present the provisional singular form as following that convention.

- **Method Names**: `interceptors/list` and `interceptor/invoke` mirror MCP patterns (`tools/list`, etc.)

[olaservo]

Addressed two suppressed Copilot notes in 57d6a1f:

• The definition no longer says interceptors cannot run inside the invoking process. It now requires invocation over an MCP transport via interceptors/list / interceptor/invoke, names out-of-process (stdio or Streamable HTTP) as the expected deployment, and allows an SDK to use an in-memory transport for testing or embedding. This keeps the Go SDK's LocalChain conformant. Whether the SEP should go further and require a process boundary is a WG question; the 8/18 notes record execution as always out of process, and the Key Advantage bullets and sidecar example still describe only stdio and Streamable HTTP servers.
• The Method Names rationale no longer presents singular interceptor/invoke as mirroring tools/list.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[jeongukjae]

I agree that interceptor shouldn't sit in request path.

but regarding exposing interceptor with other resources in the same mcp server part, I think it should remain as recommendation rather than enforcement.

[jeongukjae]

I'm +1 on using same and plural prefix - interceptors/list & interceptors/invoke