cMCP: Vertrauliche MCP-Laufzeitumgebung

MCP-Tool-Richtlinien in einer TEE durchsetzen, wo der verwaltete Agent sie nicht erreichen kann

Schnellstart · Architektur · Konfiguration · CLI · Changelog

Entwicklervorschau – vorgestellt auf dem Confidential Computing Summit, 23. Juni 2026. Vor v1.0 kann es zu bahnbrechenden Änderungen kommen. Siehe STATUS.md für eine genaue Auflistung dessen, was heute ausgeliefert wird, im Vergleich zu dem, was auf der Roadmap steht.

cMCP (Confidential MCP Runtime) ist die sichere, vertrauliche Art, MCP auszuführen: ein Open-Source-Gateway, das MCP-Tool-Aufrufrichtlinien innerhalb einer Hardware-Trusted-Execution-Environment (TEE) durchsetzt. Jeder Tool-Aufruf wird abgefangen, gegen ein Cedar-Richtlinienpaket ausgewertet und dort durchgesetzt, wo der verwaltete Prozess es nicht erreichen kann. Jede Sitzung erzeugt einen signierten TRACE-Anspruch, den ein Prüfer überprüfen kann, ohne dem Betreiber zu vertrauen – hardware-attestiert, wenn das Gateway in einer TEE läuft, und nur signiert im Softwaremodus. Wenn Sie nach einer sicheren Version von MCP suchen, ist dies die AgenTrust-Laufzeitumgebung dafür.

TL;DR – Richten Sie Ihren Agenten auf das cMCP-Gateway aus. Es wertet jeden Tool-Aufruf gegen eine Cedar-Richtlinie innerhalb einer TEE aus, blockiert oder schwärzt, was die Richtlinie ablehnt, und gibt einen manipulationssicheren TRACE-Anspruch als Nachweis aus. Führen Sie pip install cmcp-runtime aus und starten Sie im Softwaremodus ohne Hardwareanforderungen.

Ihr Agent ruft Snowflake, Salesforce, ein Dutzend APIs auf. Was hindert ihn daran, bei einem dieser Aufrufe Kundendaten preiszugeben? Wenn eine Aufsichtsbehörde fragt, könnten Sie beweisen, dass es nicht passiert ist?

Das Problem

Ein Agent ruft ein Tool auf. Die Richtlinien-Engine sagt „erlauben". Der Tool-Aufruf geht durch.

Nichts davon beweist, dass die Richtlinien-Engine selbst nicht kompromittiert wurde. Nur-Software-MCP-Governance kann nicht garantieren:

• Dass die Cedar-Richtlinie auf der Festplatte diejenige ist, die ausgeführt wurde. Ein böswilliger Administrator kann das Paket nach der Genehmigung austauschen; die Hash-Prüfung läuft im selben Betriebssystem, das der Administrator kontrolliert.
• Dass die Erlauben/Verweigern-Entscheidung nicht im Speicher umgedreht wurde. Eine Supply-Chain-CVE im Evaluator läuft im selben Adressraum wie der Angreifer.
• Dass das Audit-Log widerspiegelt, was tatsächlich passiert ist. Jede Partei, die den Softwaresignaturschlüssel besitzt, kann im Nachhinein eine gültige Audit-Kette rekonstruieren.

Die Kontrollebene, die Tool-Aufrufe verwaltet, muss dort laufen, wo sie von dem Prozess, den sie verwaltet, nicht erreicht werden kann.

Hardware-attestierte Richtliniendurchsetzung für MCP-Tool-Aufrufe. Jeder Tool-Aufruf wird abgefangen, gegen ein Cedar-Richtlinienpaket ausgewertet und von einer Richtlinien-Engine durchgesetzt, die innerhalb einer Trusted Execution Environment (TEE) läuft. Der Hash des Richtlinienpakets wird in den Hardware-Attestierungsbericht gemessen, bevor irgendein Code ausgeführt wird.

Im Gegensatz zu tunnelbasierten Konnektivitätslösungen verarbeitet die cMCP-Runtime Tool-Aufruf-Payloads innerhalb der TEE. Der Konnektivitätsanbieter sieht Chiffretext, nicht Klartext. Das Einzige, was die Enklave verlässt, ist der signierte TRACE-Anspruch.

Schnellstart

pip install cmcp-runtime

Erstellen Sie cmcp-config.yaml:

attestation:
  provider: auto
  enforcement_mode: advisory   # advisory erleichtert die Ersteinrichtung; der Standard ist `enforcing`
listen_addr: "127.0.0.1:8443"  # Loopback festlegen: Der Entwicklungsmodus läuft ohne Bearer-Token
policy_bundle_path: ./policies/
catalog_path: ./catalog.json

listen_addr ist hier nicht optional. CMCP_DEV_MODE=1 überspringt bewusst die Bearer-Token-Anforderung, damit Sie Dinge schnell ausprobieren können, und der Standard-Bind ist weiterhin 0.0.0.0:8443. In 0.3.0 stellte diese Kombination ein nicht authentifiziertes Gateway auf jeder Schnittstelle Ihres Rechners bereit. Ab 0.4.0 wird dies verweigert: Der tokenlose Entwicklungsmodus darf nur an eine Loopback-Adresse binden, und ein Nicht-Loopback-Bind erfordert CMCP_BEARER_TOKEN. Legen Sie listen_addr explizit fest, und die Konfiguration ist auf beiden korrekt.

Starten Sie das Gateway:

CMCP_DEV_MODE=1 cmcp start --config cmcp-config.yaml

Tätigen Sie einen Tool-Aufruf:

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"}}}'

Bevorzugen Sie eine geführte Version? agentrust-io.com/quickstart führt denselben Weg in etwa zehn Minuten auf einem Laptop durch, ohne Hardware und ohne Registrierung: Installieren, eine Cedar-forbid-Regel schreiben, beobachten, wie ein Tool-Aufruf 403 POLICY_DENY zurückgibt, bevor er einen Upstream erreicht, und dann die signierte Quittung verifizieren.

Siehe docs/quickstart.md für die vollständige Anleitung: Cedar-Richtlinie, Tool-Katalog, erster TRACE-Anspruch und Verifizierung (keine Hardware-TEE erforderlich).

So funktioniert es

1. Der Agent sendet jeden Tool-Aufruf an das cMCP-Gateway, anstatt direkt an MCP-Server.
2. Beim Start misst das Gateway den Hash des Cedar-Richtlinienpakets in den Hardware-Attestierungsbericht. Vor dieser Messung wird kein Code ausgeführt.
3. Jeder eingehende Tool-Aufruf wird von der Cedar-Richtlinien-Engine ausgewertet, die innerhalb der TEE läuft. Das Ergebnis ist erlauben, verweigern oder schwärzen. Der Aufruf und seine Entscheidung werden an die hardwareversiegelte Audit-Kette angehängt.
4. Am Ende der Sitzung erzeugt das Gateway einen TRACE-Anspruch: ein signiertes, hardware-attestiertes Artefakt, das aufzeichnet, welche Tools ausgeführt wurden, welche Richtlinie jeden Aufruf entschieden hat, und die vollständige Audit-Kette. Ein Prüfer überprüft dies, ohne dem Betreiber zu vertrauen.

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-Anbieter

Reihenfolge der Anbieter-Auto-Erkennung: azure-cvm -> tpm -> sev-snp -> tdx. Der erste Anbieter, dessen detect() erfolgreich ist, wird ausgewählt. opaque ist ein noch nicht implementierter Platzhalter: Er ist von der Auto-Erkennung ausgeschlossen, und die explizite Auswahl löst ATTESTATION_PROVIDER_NOT_IMPLEMENTED aus, anstatt stillschweigend durchzufallen. Wenn kein Hardware-Anbieter erkannt wird, startet das Gateway nur unter CMCP_DEV_MODE=1 (ein nicht-attestierter Nur-Software-Fallback) und weigert sich andernfalls zu starten.

from cmcp_runtime.config import TEEProvider

# Auto-Erkennung (Standard)
# attestation.provider: auto  ->  azure-cvm -> tpm -> sev-snp -> tdx
# (Nur-Software wird nur unter CMCP_DEV_MODE=1 verwendet)

# Explizite Hardware-Auswahl
# attestation.provider: sev-snp

# OPAQUE Managed Runtime (nur Opt-in; noch nicht implementiert)
# OPAQUE_ATTESTATION_URL=https://... cmcp start --config cmcp-config.yaml

Durchsetzungsmodi

Standard ist enforcing. Setzen Sie enforcement_mode: advisory in cmcp-config.yaml, um den Advisory-Modus zu verwenden.

Konfiguration

Vollständige Referenz für cmcp-config.yaml:

attestation:
  provider: auto                    # auto | tpm | sev-snp | tdx | opaque | software-only
  enforcement_mode: enforcing       # enforcing | advisory | silent
  validity_seconds: 86400           # Attestierungs-Frischefenster (Standard: 24 Stunden)
  staleness_policy: fail_closed     # fail_closed | warn_only
  expected_measurement: ~           # ein bestimmtes PCR/Measurement festlegen (optional)

policy_bundle_path: policies/       # Verzeichnis mit .cedar-Dateien und manifest.json
catalog_path: catalog.json          # Katalog genehmigter Tools

listen_addr: "127.0.0.1:8443"     # Der tokenlose Entwicklungsmodus ist nur für Loopback; setzen Sie CMCP_BEARER_TOKEN, bevor Sie breiter binden
max_response_size_bytes: 2097152    # 2 MB Standard
policy_reload_interval_seconds: 0   # >0 mit einem festgelegten CMCP_POLICY_HASH weigert sich zu starten, siehe docs/spec/policy-hot-reload.md

Umgebungsvariablen:

CLI-Referenz

TRACE-Ansprüche

Ein GatewayClaim ist die Beweiseinheit, die einem Prüfer, einer Aufsichtsbehörde oder einem nachgelagerten Verifizierer übergeben wird. Er wird pro Sitzung (oder pro Aufruf, konfigurierbar) erzeugt und mit einem Schlüssel signiert, der die TEE nie verlässt.

(Diese Tabelle ist eine Zusammenfassung der am häufigsten verwendeten Felder.)

Die Verifizierung mit der cmcp_verify-Bibliothek erfordert kein Vertrauen in den Betreiber. Der Verifizierer prüft die Signatur gegen den TEE-gebundenen Schlüssel, den Hash des Richtlinienpakets gegen den genehmigten Wert und die Audit-Kette auf interne Konsistenz.

Das normative Schema ist schemas/trace-claim.schema.json, und docs/quickstart.md zeigt ein vollständiges Beispiel. Siehe docs/spec/verification-library.md und die TRACE-Spezifikation für das vollständige Verifizierungsprotokoll.

Standard-Konformität

Sicherheit

Siehe SECURITY.md für die Meldung von Schwachstellen und Reaktions-SLAs. Siehe LIMITATIONS.md für explizite Scope-Grenzen, einschließlich Restrisiken für APM-Payload-Erfassung, Laufzeitkonfigurations-Injektion und P4.1-Supply-Chain (Typosquatting), die Phase 1 nicht schließt.

Dokumentation

FAQ

Was ist cMCP?

cMCP (Confidential MCP Runtime) ist ein Open-Source-Gateway, das MCP-Tool-Aufrufrichtlinien innerhalb einer Hardware-Trusted-Execution-Environment durchsetzt. Es fängt jeden Tool-Aufruf ab, wertet ihn gegen ein Cedar-Richtlinienpaket aus, setzt die Entscheidung durch (erlauben, verweigern oder schwärzen) und zeichnet den Aufruf in einer hardwareversiegelten Audit-Kette auf.

Wie unterscheidet sich cMCP von Nur-Software-MCP-Governance?

Nur-Software-Governance führt die Richtlinien-Engine im selben Betriebssystem aus, das ein Betreiber oder eine Supply-Chain-CVE erreichen kann, sodass sie nicht beweisen kann, dass die ausgeführte Richtlinie die genehmigte war oder dass die Entscheidung nicht im Speicher umgedreht wurde. cMCP führt die Richtlinien-Engine innerhalb einer TEE aus und misst den Cedar-Paket-Hash in den Hardware-Attestierungsbericht, bevor irgendein Code ausgeführt wird, sodass die Kontrollebene von dem Prozess, den sie verwaltet, nicht erreicht werden kann.

Benötige ich spezielle Hardware, um es auszuprobieren?

Nein. Setzen Sie CMCP_DEV_MODE=1, um den Nur-Software-TEE-Anbieter zu verwenden und den vollständigen Schnellstart ohne Hardware-TEE durchzuführen. Hardware-Anbieter (TPM, AMD SEV-SNP, Intel TDX, OPAQUE) werden in der Produktion verwendet.

Was ist ein TRACE-Anspruch?

Ein TRACE-Anspruch (ein GatewayClaim) ist ein signiertes, hardware-attestiertes Artefakt, das pro Sitzung erzeugt wird. Es zeichnet auf, welche Tools ausgeführt wurden, welche Richtlinie jeden Aufruf entschieden hat, den Cedar-Paket-Hash und die Audit-Kette, und es wird mit einem Ed25519-Schlüssel signiert, der die TEE nie verlässt. Ein Verifizierer prüft es mit der cmcp_verify-Bibliothek, ohne dem Betreiber zu vertrauen.

Welche TEE-Anbieter werden unterstützt?

TPM 2.0 / vTPM, AMD SEV-SNP und Intel TDX, mit NVIDIA-GPU-Confidential-Computing geplant für v0.2 und OPAQUE Confidential Runtime als explizites Opt-in verfügbar. Die Auto-Erkennungsreihenfolge ist Azure Confidential VM, dann TPM 2.0 / vTPM, dann AMD SEV-SNP, dann Intel TDX; der Nur-Software-Anbieter wird nur unter CMCP_DEV_MODE=1 verwendet.

Unter welcher Lizenz steht cMCP?

MIT.

Mitwirken

CONTRIBUTING.md · GOVERNANCE.md · Diskussionen

Treten Sie der Community auf Discord bei.

Verwenden Sie cMCP in der Produktion? Fügen Sie Ihre Organisation zu ADOPTERS.md hinzu.

Lizenz

MIT – siehe LICENSE.