Transport Compatibility Specification¶

Status: Draft v0.1 Last updated: 2026-06-04 Stability: Unstable , expect breaking changes before v1.0

Covers: Phase 1 transport scope, stdio gap analysis, SPIFFE-to-TEE attestation binding.

Closes #20, #21.

Transport Compatibility Matrix¶

stdio Gap: Technical Reason¶

The MCP stdio transport works as follows:

Agent process
  └── spawns MCP server as child process
        └── communicates over stdin/stdout (JSON-RPC 2.0 framing)

For the runtime to intercept this traffic, it would need to run inside the same process tree as the agent, which contradicts TEE isolation. TEE isolation works at the VM boundary (SEV-SNP, TDX) or at the TPM-measured boot boundary. A process inside the TEE cannot be a child of a process outside the TEE. Allowing it would defeat the hardware attestation guarantee: the enclave measurement would no longer cover the full execution context.

stdio Bridging Options¶

Option A: stdio-to-HTTP Bridge (new component at TEE boundary)¶

A new sidecar component runs outside the TEE and translates stdio JSON-RPC to HTTP/SSE. The runtime (inside the TEE) connects to the sidecar over localhost HTTP.

Agent
  └── spawns stdio-bridge (outside TEE)
        └── translates stdio <-> HTTP/SSE
              └── cMCP Gateway (inside TEE)
                    └── MCP Server (HTTP/SSE)

Option B: Agent-side stdio Proxy (agent wraps stdio server, exposes HTTP/SSE)¶

The agent developer wraps the stdio MCP server in a thin HTTP adapter that speaks HTTP/SSE externally. The runtime connects to the adapter endpoint as if it were a native HTTP/SSE MCP server.

Agent
  └── stdio-http-adapter (agent-side, outside TEE)
        └── spawns MCP server (stdio)
        └── exposes HTTP/SSE on localhost port
              └── cMCP Gateway (inside TEE)

Comparison Table¶

Decision for Phase 1: stdio transport is unsupported. Agents using stdio-only MCP servers must either migrate those servers to HTTP/SSE or use Option B as an undocumented workaround at their own risk.

"Zero Code Changes" Claim: Precise Scope¶

The "zero code changes" claim applies only to the following configuration:

• The MCP server is containerized (Docker or OCI image).
• The MCP server already supports HTTP/SSE transport (not stdio-only).
• The MCP server does not depend on host-level resources: local filesystem mounts, host network interfaces, or host-specific library versions (e.g., a specific glibc ABI not present in the TEE base image).
• The agent MCP client is configured to point to the runtime endpoint rather than the MCP server directly.

If any of these conditions are not met, code or configuration changes are required before the runtime can be used.

Concrete Agent-Side Configuration¶

The runtime is the sole MCP endpoint the agent host is configured to reach. All MCP servers are registered with the runtime, not with the agent directly.

YAML example¶

# agent-config.yaml
mcp:
  # The agent host connects only to the cMCP Runtime.
  # No direct connections to individual MCP servers.
  gateway_endpoint: "https://cmcp-runtime.internal:4433"
  tls:
    ca_cert: "/etc/cmcp/runtime-ca.pem"
    # SPIFFE SVID for mutual TLS (issued only after TEE attestation succeeds)
    client_cert: "/var/run/spire/svids/agent.pem"
    client_key:  "/var/run/spire/svids/agent.key"

  # The agent does not list individual MCP servers here.
  # The runtime tool catalog is the authoritative list of available tools.
  # servers: []  # empty -- runtime handles routing

JSON example (alternative)¶

{
  "mcp": {
    "gateway_endpoint": "https://cmcp-runtime.internal:4433",
    "tls": {
      "ca_cert": "/etc/cmcp/runtime-ca.pem",
      "client_cert": "/var/run/spire/svids/agent.pem",
      "client_key": "/var/run/spire/svids/agent.key"
    }
  }
}

The agent host must not have direct network routes to any MCP server. Network policy (Kubernetes NetworkPolicy, security group, or firewall rule) enforces this. The runtime is the only reachable MCP endpoint from the agent network namespace.

SPIFFE-to-TEE Attestation Binding (Issue #21)¶

Problem Statement¶

SPIFFE SVID issuance must be conditioned on successful TEE attestation. If a SVID can be issued without attestation, any process -- attested or not -- can claim a runtime identity. The binding is the critical-path item for Phase 1: without it, the chain of trust has a gap between hardware measurement and workload identity.

Standards Basis¶

• IETF RATS RFC 9334: Defines the reference architecture for remote attestation. The Attester (TEE) produces Evidence; the Verifier checks Evidence against Reference Values and produces an Attestation Result; the Relying Party (SPIRE) consumes the Attestation Result to make a trust decision.
• SPIFFE/SPIRE: SPIRE issues X.509 SVIDs and JWT SVIDs. SPIRE node attestation plugin model supports custom attestors. The TEE attestation plugin produces an attestation result that SPIRE uses as the basis for SVID issuance.

Binding Mechanism¶

TEE boots
  └── TEE produces attestation Evidence (measurement)
        └── SPIRE node attestation plugin receives Evidence
              └── Plugin forwards to Verifier (external or embedded)
                    └── Verifier checks measurement against Reference Values
                          └── On success: SPIRE issues SVID to TEE workload
                                └── Gateway uses SVID for mTLS with agents and MCP servers

Per-Provider Attestation Evidence Formats¶

Validation Spike¶

Goal: Confirm that a SPIFFE SVID can be issued if and only if TEE attestation succeeds, using at least one provider (TPM recommended for accessibility).

Pass conditions: 1. SPIRE issues an SVID to the runtime workload only after the TEE attestation plugin returns a successful result. 2. If the TPM PCR values are tampered with (e.g., by modifying the boot sequence in a test VM), SPIRE refuses to issue the SVID and the runtime does not start. 3. The SVID contains a SPIFFE ID that encodes the TEE provider and measurement (or a reference to it).

Fail conditions: 1. SPIRE issues an SVID without consulting the attestation plugin. 2. No existing SPIRE plugin supports the target TEE provider; a custom plugin would require more than 2 days to build. 3. The attestation API is not reachable from the TEE environment (network policy or credential bootstrap problem).

Estimated duration: 1-2 days.

If the spike fails: Phase 1 timeline slips. The binding is non-negotiable for the security model. A failed spike triggers one of: - Switch to a provider with a working SPIRE plugin (e.g., TPM if the SEV-SNP plugin is missing). - Build a minimal custom SPIRE plugin (adds 1-2 weeks). - Defer SPIFFE and use a simpler credential bootstrap (e.g., pre-provisioned TLS cert pinned to the TEE measurement via a separate verification step) -- requires a security architecture review before proceeding.