docs(spec): propose the gateway as parent for stdio, and say what it costs

[imran-siddique]

Proposal, no code. You asked for the stdio bridge before server provenance. Working on it turned up a reason not to build a bridge at all.

What transport.md already decided, and why it was right

stdio is out of scope, and both bridging options are rejected because they put a translating component outside the enclave, where it can inject or suppress tool calls before the gateway sees them and where the attestation report does not cover it. That reasoning holds.

The assumption underneath both options

Both assume the agent spawns the MCP server. That is how stdio works by default. It is not how anything works once cMCP is in the path — and transport.md says so itself, two sections later:

The agent does not list individual MCP servers here. The runtime tool catalog is the authoritative list of available tools.

The agent already does not spawn, address or reach servers. It reaches the gateway.

The proposal

The gateway spawns the stdio server as its own child, inside the enclave.

Nothing crosses the boundary that does not cross it today. A process tree does not leave the VM by forking; SEV-SNP and TDX isolate a VM. The objection in transport.md is about a process outside the enclave forking a child inside it, which is a different thing and remains impossible.

What it buys that no HTTP upstream can have: the gateway chooses when to exec, so it can digest the executable and refuse to spawn on a mismatch. A pinned TLS fingerprint identifies an endpoint; a verified digest identifies the code. That is a stronger binding than Phase 1 makes about any upstream today, and it is the natural identity for the server provenance record — a package digest the gateway verified rather than a URL it trusted.

What it costs, which is the part worth arguing about

The server then runs in the same isolation domain as the policy evaluator and the audit chain. A compromised server is inside the boundary. Memory isolation protects the gateway from the host, not from its own child. That is a real weakening relative to a network upstream, where the network does the isolating.

The gateway's launch measurement does not cover a child spawned later. The child's digest is recorded in the audit chain and sealed by the gateway's key, which makes it operator-evident and hardware-rooted only as far as the gateway itself is. Weaker than a launch measurement, so it gets its own evidence classes — spawn-measured and spawn-unmeasured — rather than being folded into hardware_attestation.

Recommendation: adopt it, retire both bridging options, ship behind config with default off and spawn-unmeasured refused unless explicitly enabled.

Four open questions I did not answer

1. Lifecycle — one child per session, or a pool? A pool is faster and leaks state between sessions, which is exactly what the audit chain cannot see.
2. stderr — capturing it risks payloads in a shareable artifact; discarding it loses the only signal when a child misbehaves.
3. Framing — a child that logs to stdout desynchronizes the JSON-RPC stream. A parse failure has to be fatal, because resynchronizing means guessing which bytes were a response.
4. Phase model — a spawn-measured child sits between "unattested network upstream" and "server attests itself in its own TEE". The Phase 1/2 line has no place for it.

transport.md gets a pointer to this file so the two do not silently disagree.

🤖 Generated with Claude Code