[phase-2] Policy enforcement inside TEE — Cedar evaluation runs in the enclave, not at API boundary

[imran-siddique]

What and why

Phase 1 enforces Cedar policy at the API layer — the gateway process evaluates policy before forwarding calls to upstream MCP servers. In Phase 1, a compromised host OS can still bypass this (it can intercept the gateway process).

Phase 2 moves the Cedar evaluation inside the TEE boundary so policy decisions are hardware-protected. The Cedar engine must run inside the enclave; the policy bundle must be measured into the TEE attestation report; the enforcement result must be signed with the TEE key.

Architecture change

Phase 1 (current):
Agent → [cMCP API layer → Cedar eval → forward] → Upstream MCP server

Phase 2 (target):
Agent → [cMCP API layer] → TEE enclave: [Cedar eval + session state + audit chain] → [forward or deny] → Upstream MCP server

The TEE boundary is at the Cedar evaluation step. The enclave holds:

• The Cedar policy bundle (loaded and measured at startup)
• The session state (sensitivity tags, call history)
• The audit chain (hash-chained, TEE-signed)

Acceptance criteria

• Cedar evaluation runs inside the enclave — the policy bundle is measured into the TEE attestation report
• policy.bundle_hash in the TRACE Trust Record is the hash measured at enclave load time (tamper-evident)
• policy.enforcement_mode = "enforce" means a deny inside the enclave cannot be bypassed by the host
• All Phase 1 tests continue to pass
• Conformance tests POLICY-TEE-001 through POLICY-TEE-005 added and passing
• TRACE Trust Record policy.bundle_hash matches the value measured at startup

Notes

This is the critical path item for the GTC Berlin demo. Without it, the demo shows software-only governance (useful, but not the hardware-proof story). Target: end of Q3 2026.