翻訳待ち：Show HN: cMCP, deny an AI agent's tool call and get a signed receipt

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

Uh oh! There was an error while loading. Please reload this page. Notifications You must be signed in to change notification settings Fork 7 Star 5 BranchesTags Open more actions menu Folders and files NameName Last commit message Last commit date Latest commit History 314 Commits 314 Commits .github .github benchmarks benchmarks docs docs examples examples experiments experiments governance governance overrides overrides schemas schemas scripts scripts src src tests tests .gitignore .gitignore ADOPTERS.md ADOPTERS.md CHANGELOG.md CHANGELOG.md CHARTER.md CHARTER.md CODE_OF_CONDUCT.md CODE_OF_CONDUCT.md CONTRIBUTING.md CONTRIBUTING.md Dockerfile Dockerfile GOVERNANCE.md GOVERNANCE.md LICENSE LICENSE LIMITATIONS.md LIMITATIONS.md MAINTAINERS.md MAINTAINERS.md NOTICE NOTICE PRIVACY.md PRIVACY.md README.md README.md ROADMAP.md ROADMAP.md SECURITY.md SECURITY.md STATUS.md STATUS.md docker-compose.yml docker-compose.yml mkdocs.yml mkdocs.yml pyproject.toml pyproject.toml requirements-docs.txt requirements-docs.txt robots.txt robots.txt Repository files navigation Enforce MCP tool policy inside a TEE, where the agent it governs cannot reach it Quick Start · Architecture · Configuration · CLI · Changelog Developer Preview - launched at the Confidential Computing Summit, June 23 2026. May have breaking changes before v1.0. See STATUS.md for exactly what ships today versus what is on the roadmap. cMCP (Confidential MCP Runtime) is the secure, confidential way to run MCP: an open-source gateway that enforces MCP tool-call policy inside a hardware Trusted Execution Environment (TEE). Every tool call is intercepted, evaluated against a Cedar policy bundle, and enforced where the process it governs cannot reach it. Each session produces a signed TRACE Claim that a verifier checks without trusting the operator, hardware-attested when the gateway runs in a TEE and signed-only in software mode. If you are looking for a secure version of MCP, this is the AgenTrust runtime for it. TL;DR - Point your agent at the cMCP Gateway. It evaluates every tool call against a Cedar policy inside a TEE, blocks or redacts what the policy denies, and emits a tamper-evident TRACE Claim as proof. Run pip install cmcp-runtime and start in software mode with no hardware required. Your agent calls Snowflake, Salesforce, a dozen APIs. What stops it from leaking a customer's data on one of those calls? If a regulator asks, could you prove it didn't? The problem An agent calls a tool. The policy engine says allow. The tool call goes through. None of that proves the policy engine itself was not compromised. Software-only MCP governance cannot guarantee: The Cedar policy on disk is the one that ran. A rogue admin can swap the bundle after approval; the hash check runs inside the same OS the admin controls. The allow/deny decision was not flipped in memory. A supply chain CVE in the evaluator runs in the same address space as the attacker. The audit log reflects what actually happened. Any party holding the software signing key can reconstruct a valid audit chain after the fact. The control plane that governs tool calls must run where it cannot be reached by the process it governs. Hardware-attested policy enforcement for MCP tool calls. Every tool call is intercepted, evaluated against a Cedar policy bundle, and enforced by a policy engine running inside a Trusted Execution Environment (TEE). The policy bundle hash is measured into the hardware attestation report before any code runs. Unlike tunnel-based connectivity solutions, the cMCP Runtime processes tool-call payloads inside the TEE. The connectivity provider sees ciphertext, not plaintext. The only thing that leaves the enclave is the signed TRACE claim. Quick Start pip install cmcp-runtime Create cmcp-config.yaml: attestation: provider: auto enforcement_mode: advisory # advisory eases first-run tuning; the default is enforcing policy_bundle_path: ./policies/ catalog_path: ./catalog.json Start the gateway: CMCP_DEV_MODE=1 cmcp start --config cmcp-config.yaml Make a tool call: curl -X POST http://localhost:8443/mcp \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"salesforce.contacts","arguments":{"query":"Acme Corp"},"_cmcp":{"session_id":"s1","workflow_id":"demo-agent"}}}' See docs/quickstart.md for the full walkthrough: Cedar policy, tool catalog, first TRACE Claim, and verification (no hardware TEE required). How it works The agent sends every tool call to the cMCP Gateway instead of directly to MCP servers. At startup the gateway measures the Cedar policy bundle hash into the hardware attestation report. No code runs before this measurement. Each incoming tool call is evaluated by the Cedar policy engine running inside the TEE. The result is allow, deny, or redact. The call and its decision are appended to the hardware-sealed audit chain. At the end of the session the gateway produces a TRACE Claim: a signed, hardware-attested artifact that records which tools ran, which policy decided each call, and the full audit chain. A verifier checks this without trusting the operator. Agent -> cMCP Runtime -> Cedar Policy Engine (TEE) -> Tool | GatewayClaim (TRACE Profile) +-- trace.eat_profile +-- trace.runtime.platform + measurement +-- trace.policy.bundle_hash +-- trace.cnf.jwk (Ed25519 confirmation key) +-- gateway.audit_chain (root/tip/length) +-- signature (Ed25519 over canonical JSON) Hardware providers Provider Platform Assurance Notes tpm TPM 2.0 / vTPM (Azure, AWS, GCP Trusted Launch) Medium Local TPM quote sev-snp AMD SEV-SNP (Azure DCasv5, AWS C6a Nitro) High AMD KDS tdx Intel TDX (Azure DCedsv5, GCP C3) High Intel PCS gpu-cc (v0.2) NVIDIA H100/H200/Blackwell (CC mode) High NVIDIA Remote Attestation Service (NRAS) opaque (opt-in) OPAQUE Confidential Runtime n/a (not yet implemented) Placeholder: excluded from auto-detect; selecting it explicitly raises a not-implemented error Provider auto-detect probe order: azure-cvm -> tpm -> sev-snp -> tdx. The first provider whose detect() succeeds is selected. opaque is a not-yet-implemented placeholder: it is excluded from auto-detect, and selecting it explicitly raises ATTESTATION_PROVIDER_NOT_IMPLEMENTED rather than falling through silently. If no hardware provider is detected, the gateway starts only under CMCP_DEV_MODE=1 (a non-attested software-only fallback) and otherwise refuses to start. from cmcp_runtime.config import TEEProvider # Auto-detect (default) # attestation.provider: auto -> azure-cvm -> tpm -> sev-snp -> tdx # (software-only is used only under CMCP_DEV_MODE=1) # Explicit hardware selection # attestation.provider: sev-snp # OPAQUE Managed Runtime (opt-in only; not yet implemented) # OPAQUE_ATTESTATION_URL=https://... cmcp start --config cmcp-config.yaml Enforcement modes Mode Behavior Use case enforcing Policy denies return HTTP 403; call is not forwarded Production advisory Policy denies are logged; call proceeds First deployment, policy tuning silent Policy is evaluated but nothing is logged or blocked Baselining Default is enforcing. Set enforcement_mode: advisory in cmcp-config.yaml to use advisory mode. Configuration cmcp-config.yaml full reference: attestation: provider: auto # auto | tpm | sev-snp | tdx | opaque | software-only enforcement_mode: enforcing # enforcing | advisory | silent validity_seconds: 86400 # attestation freshness window (default: 24 hours) staleness_policy: fail_closed # fail_closed | warn_only expected_measurement: ~ # pin a specific PCR/measurement (optional) policy_bundle_path: policies/ # directory containing .cedar files and manifest.json catalog_path: catalog.json # approved tool catalog listen_addr: "0.0.0.0:8443" max_response_size_bytes: 2097152 # 2 MB default policy_reload_interval_seconds: 0 # 0 = disabled; restart required to update policy Environment variables: Variable Effect CMCP_DEV_MODE=1 Use software-only TEE provider; no hardware required CMCP_BEARER_TOKEN Require this bearer token on all inbound requests OPAQUE_ATTESTATION_URL Enable OPAQUE Managed Runtime attestation (explicit opt-in) CLI reference Command Flags Description cmcp start --config PATH (required) Start the gateway cmcp validate-config --config PATH (required) Validate cmcp-config.yaml without starting cmcp validate-bundle --bundle-path PATH (required), --expected-hash sha256: (required) Verify a Cedar bundle hash before deployment cmcp verify CLAIM_FILE (required); --policy-hash, --catalog-hash, --max-age, --trusted-key, --audit-bundle, --agent-manifest, --agent-manifest-trust-anchor Verify a signed TRACE Claim (signature, schema, freshness, audit chain, and pinned hashes) TRACE Claims A GatewayClaim is the unit of proof handed to an auditor, regulator, or downstream verifier. It is produced per session (or per call, configurable) and signed with a key that never leaves the TEE. Field Description trace.eat_profile EAT profile URI: tag:agentrust-io.com,2026:trace-v0.2 trace.runtime TEE platform and hardware measurement recorded at enclave boot trace.policy.bundle_hash SHA-256 of the Cedar bundle loaded at startup; changing any policy file changes this value trace.cnf.jwk Ed25519 public key bound to the TEE signing key trace.tool_transcript Audit-chain-derived per-call view: hash (binds to the audit chain tip), call_count, and privacy-preserving entries (tool name, data class, decision) gateway.audit_chain Hash-chained audit log root and tip; verifiable without replaying individual entries signature Ed25519 over canonical JSON of the full claim body (RFC 8785) (This table is a summary of the most-used fields.) Verification with the cmcp_verify library does not require trusting the operator. The verifier checks the signature against the TEE-bound key, the policy bundle hash against the approved value, and the audit chain for internal consistency. The normative schema is schemas/trace-claim.schema.json, and docs/quickstart.md shows a complete example. See docs/spec/verification-library.md and the TRACE specification for the full verification protocol. Standards alignment Standard Coverage OWASP Agentic AI Top 10 MCP10 (data leakage via tool calls), MCP02 (unsanctioned tools), MCP08 (provable governance), MCP04 (supply chain) NIST SP 800-207 Policy decision point inside TEE; no implicit trust in workload identity EU AI Act Art. 12, 15 Per-decision audit records (Art. 12); TEE-backed cybersecurity controls (Art. 15) DORA Art. 9 Attestation chain; audit log retention via gateway.audit_chain RATS/EAT RFC 9711 GatewayClaim is an EAT; eat_profile field identifies the TRACE profile Security Tool What it checks ruff Style and import linting on every PR bandit Python security linting on every PR pip-audit Dependency vulnerability scan on every PR mypy Static type checking on every PR CodeQL Python SAST, security-extended queries, weekly OpenSSF Scorecard Weekly scoring, SARIF upload See SECURITY.md for vulnerability reporting and response SLAs. See LIMITATIONS.md for explicit scope boundaries, including residual risks for APM payload capture, runtime config injection, and P4.1 supply chain (typosquat) that Phase 1 does not close. Documentation Page Description docs/quickstart.md From zero to first TRACE Claim in under 30 minutes docs/configuration.md Full config reference with all fields and defaults docs/SPEC.md Product specification: problem taxonomy, architecture, coverage matrix docs/spec/threat-model.md STRIDE analysis, adversary model, residual risks docs/spec/cedar-policy.md Cedar policy language reference and schema docs [truncated for AI cost control]