This document describes what cMCP does not prevent, where its guarantees end, and what operators and verifiers must address through separate controls.
Prompt injection into Cedar policy
Cedar policy evaluation is only as correct as the policy the operator wrote and approved. cMCP measures the policy bundle hash into the TEE attestation report, which proves the policy that ran is the policy that was approved. It does not evaluate whether that policy achieves the intended security outcome. A policy that contains permit(principal, action, resource); without conditions permits every tool call. Policy correctness is the operator’s responsibility; policy review is a separate control.
Compromised TEE firmware or microcode Hardware attestation proves the workload hash was measured in silicon. It does not protect against vulnerabilities in the TEE firmware or CPU microcode itself (Spectre-class side channels, cache timing, power analysis, fault injection targeting the TEE boundary). Protection at this level is the responsibility of the hardware vendor. Operators must keep TEE firmware and microcode up to date; see Compensating Controls in the threat model.
Operator-controlled key material The TEE-sealed signing key is generated inside the enclave and cannot be extracted by a privileged operator under normal circumstances. However, if the operator can substitute the TEE firmware, modify the enclave startup measurement, or compromise the SPIRE infrastructure that issues SVIDs, they can effectively control what key material is used. The trust root is the hardware platform vendor (AMD, Intel, or the TPM manufacturer), not cMCP. Deployments that do not independently verify the attestation report before routing traffic treat attestation as post-hoc audit evidence only.
Phase 2 completeness: server-side attestation
Phase 1 attests the gateway boundary. It does not attest what happens on the other side of that boundary. The tool_transcript.hash field in the TRACE Claim records a hash of the audit chain tip, but the tool transcript binding that ties a specific tool execution to a specific response is Phase 2 work. Phase 1 partially addresses P1.4 (transitive trust into upstream dependencies) and P4.1 (typosquatted packages added to catalog) – both are fully closed by Phase 2. Any compliance claim that relies on server-side proof must wait for Phase 2.
Tool server non-repudiation
The audit chain records a response_payload_hash for each tool call and an evidence_class that indicates the assurance level of the recorded response:
tls-pinned: The tool server URL uses HTTPS and has a non-placeholder TLS certificate fingerprint in the catalog. The response was received over a TLS connection whose certificate was pinned at catalog-load time. A verifier can confirm the server identity against the catalog fingerprint.hash-only: The tool server uses HTTP, has no TLS fingerprint assigned in the catalog (dev placeholder), or TLS pinning could not be enforced on the current platform. The hash proves what the gateway received, but the server identity cannot be independently verified from the audit record alone.Tool servers do not sign their individual responses. A tls-pinned entry proves the response came from a server holding the catalog-pinned certificate but does not prevent the server itself from later denying it produced a specific response. For strong non-repudiation, configure non-placeholder TLS fingerprints for all upstream servers so all evidence is tls-pinned, and treat the TEE attestation as the binding authority for what the gateway recorded.
Agent Manifest identity binding (issue #302)
When configured, cMCP verifies a signed Agent Manifest against a trusted issuer key, checks that the authenticated agent subject equals manifest.agent_id, and requires the manifest’s policy and catalog hashes to match the loaded runtime hashes. The Trust Record carries this as gateway.agent_identity. This proves that the session was bound to the reviewed manifest identity and approved hashes. It does not prove that the agent behaved correctly, that the model output was safe, or that the same logical agent persisted across restarts. The first implementation takes the authenticated subject from configuration; production deployments should source it from the agent SVID/mTLS identity path. Trust in the manifest issuer key remains an out-of-band PKI concern.
LLM inference and model output cMCP intercepts tool calls at the MCP protocol boundary. It does not observe or modify LLM inference, the contents of the agent’s context window, or model outputs that do not produce a tool call. A model could hallucinate a response, leak sensitive context in a chat reply, or receive a poisoned tool response that influences subsequent reasoning – none of these are visible to the gateway. cMCP controls the tool boundary, not the model boundary.
Response injection evasion via novel patterns The response inspector uses pattern-based detection for prompt injection in tool responses. Pattern-based detection has false negatives. A sufficiently sophisticated injection may evade the current pattern list. The pattern list must be maintained and updated by the operator as new injection techniques emerge; see Compensating Controls.
APM and telemetry payload capture The TEE prevents plaintext from leaving the enclave to any destination not covered by the egress policy. This protection is structural only when the egress policy explicitly denies APM and telemetry endpoints. If the operator allowlists those endpoints in the Cedar policy, the TEE boundary does not prevent payload capture by the APM agent. A TRACE Claim with an egress policy that permits APM or SDK telemetry endpoints does not provide this protection. Verifiers must inspect the policy bundle hash and confirm the policy excludes those endpoints.
Tool name collision via malicious catalog entries The catalog binds each tool name to a specific upstream server identity, which prevents routing ambiguity for approved servers. It does not prevent a typosquatted or look-alike package from being added to the catalog in the first place. Catalog approval is human-gated. The gateway trusts the catalog; it cannot detect that a catalog entry was added via a compromised reviewer or a social engineering attack.
CMCP_DEV_MODE=1 uses a software-only TEE provider. It is suitable for development, testing, and demo scenarios. It does not satisfy production governance requirements because:
trace.runtime.measurement field is all zeros in dev mode. There is no hardware-measured enclave identity, so a verifier cannot confirm which binary ran.cmcp_verify library returns status: partially_verified and reports hardware_attestation: software-only mode -- not hardware-backed. Claims produced in dev mode must not be presented as hardware-attested proof to auditors or regulators.Attestation is a startup cost, not a per-call cost. Per-call gateway overhead covers Cedar policy evaluation, audit entry creation, and routing. Upstream tool execution time is excluded.
| Provider | Typical latency |
|---|---|
| TPM | less than 500ms (hardware I/O bound) |
| SEV-SNP | less than 100ms (Azure DCasv5, AWS C6a Nitro) |
| TDX | less than 100ms (Azure DCedsv5, GCP C3) |
| Opaque Managed | less than 50ms |
| software-only | negligible |
| Percentile | Target |
|---|---|
| p50 | less than 1ms |
| p95 | less than 3ms |
| p99 | less than 5ms |
Expected component breakdown for a 10-rule policy bundle:
| Component | Estimated cost |
|---|---|
| Cedar evaluation (10 rules) | 0.2 to 0.5ms |
| Audit entry hash computation | approximately 0.1ms |
| Network routing overhead | 0.5 to 2ms |
These are targets from docs/testing/benchmarks.md. Actual results on real TEE hardware will vary by provider and payload size; benchmark results are committed per provider to benchmarks/ in CI.