AI Signal 506
Show HN: cMCP, deny an AI agent's tool call and get a signed receipt
cMCP is a runtime that places MCP tool-call policy enforcement inside a hardware Trusted Execution Environment and emits a signed audit claim for each session.
By moving the policy engine into a TEE, cMCP prevents a compromised host or administrator from tampering with policy decisions or audit logs, giving operators verifiable proof that an AI agent obeyed its restrictions. This capability is valuable for compliance and for any scenario where regulators or customers need evidence that no data-leaking calls were allowed.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
All tool calls are routed through a gateway that evaluates a Cedar policy inside a TEE and returns allow, deny, or redacted results.
Each session ends with a hardware-attested, signed TRACE claim that records the calls, decisions, and policy bundle hash.
The system can run without hardware in a software-only mode, but only the hardware-backed mode provides the full attestation guarantees.
THE READ
What elseif makes of it.
The core change introduced by cMCP is the relocation of the MCP policy decision point into a confidential enclave, ensuring that the policy engine cannot be accessed or altered by the process it protects. Every request from an AI agent is intercepted by the cMCP gateway, evaluated against a Cedar policy bundle, and the outcome is enforced before the request reaches the underlying tool. The result, together with the request data, is appended to an audit chain that is sealed by the enclave and later emitted as a signed TRACE claim.
Adopting cMCP requires adding a Python package, creating a simple YAML configuration, and launching the gateway process instead of calling MCP services directly. If the deployment environment provides a supported TEE, such as TPM, AMD SEV-SNP, Intel TDX, or NVIDIA confidential GPU, the gateway measures the policy bundle hash into the hardware attestation report and produces a hardware-attested claim. In environments lacking such hardware, the same software can be run in a non-attested mode, but the resulting claim lacks the hardware-based tamper evidence.
The solution only protects calls that are routed through the cMCP gateway; any tool call made directly to an MCP server bypasses the policy enforcement and audit generation. Hardware attestation is limited to the listed providers, and the auto-detect logic currently favors Azure, so deployments on other clouds may need explicit provider configuration. Moreover, the software-only mode does not prevent a malicious operator from swapping the policy bundle or forging audit entries, so its guarantees are weaker.
For verification, a downstream party can validate the signed TRACE claim without trusting the operator, using the embedded Ed25519 key and the measured policy bundle hash. This enables regulators or auditors to confirm that the agent’s tool usage complied with the declared policy, even when the operator’s infrastructure is untrusted. The approach therefore shifts trust from the operator to the hardware attestation and cryptographic proof.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER