cMCP: Vertrauliche MCP-Laufzeitumgebung

Community-Updates und Highlights von Mitwirkenden: AgenTrust auf LinkedIn.

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

Schnellstart · Architektur · Konfiguration · CLI · Änderungsprotokoll

Developer Preview – vorgestellt auf dem Confidential Computing Summit, 23. Juni 2026. Bis v1.0 sind möglicherweise Breaking Changes möglich. Siehe STATUS.md für eine genaue Übersicht, was heute bereits ausgeliefert wird und was auf der Roadmap steht.

cMCP (Confidential MCP Runtime) ist ein Open-Source-Gateway, das jeden Tool-Aufruf eines KI-Agenten gegen von Ihnen geschriebene Regeln prüft und auf abgeschotteter Hardware laufen kann, die der Agent nicht manipulieren kann. KI-Agenten nutzen Tools (Datenbanken, CRMs, E-Mail, interne APIs), indem sie Anfragen senden, sogenannte Tool-Aufrufe, üblicherweise über MCP, das Model Context Protocol. cMCP sitzt im Pfad dieser Aufrufe, prüft jeden einzelnen gegen Ihre Regeln (geschrieben in der Richtliniensprache Cedar) und blockiert diejenigen, die die Regeln verbieten. Es kann innerhalb einer TEE (Trusted Execution Environment: Hardware, die den Speicher eines Programms selbst vor dem Eigentümer der Maschine abschottet) laufen, wo der von ihm verwaltete Agent es nicht erreichen kann. Jede Sitzung endet mit einem signierten Beleg, einem TRACE Claim, den jeder prüfen kann, ohne demjenigen vertrauen zu müssen, der das Gateway betrieben hat. Der Beleg wird durch einen Hardware-Bericht gestützt, wenn das Gateway in einer TEE läuft, und ist im Software-Modus nur signiert (ohne Hardware-Nachweis). Neu bei diesen Begriffen? Siehe die Begriffe, in einfachem Englisch.

TL;DR: Richten Sie Ihren Agenten auf das cMCP Gateway. Es prüft jeden Tool-Aufruf gegen Ihre Cedar-Regeln, blockiert oder redigiert (blendet aus), was die Regeln verweigern, und liefert Ihnen einen signierten Beleg, der zeigt, ob jemand ihn verändert hat. Führen Sie pip install cmcp-runtime aus und starten Sie im Software-Modus auf jedem Computer; keine spezielle Hardware erforderlich.

Ihr Agent ruft Snowflake, Salesforce und ein Dutzend APIs auf. Was hindert ihn daran, bei einem dieser Aufrufe die Daten eines Kunden preiszugeben? Und falls eine Aufsichtsbehörde fragt: Könnten Sie beweisen, dass es nicht geschehen ist?

---

Das Problem

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

Nichts davon beweist, dass die Policy Engine selbst nicht kompromittiert wurde. Eine reine Software-Governance für MCP kann Folgendes nicht garantieren:

• Die Cedar-Richtlinie auf der Festplatte ist diejenige, die ausgeführt wurde. Ein böswilliger Administrator kann das Bundle nach der Genehmigung austauschen; die Hash-Prüfung läuft innerhalb desselben Betriebssystems, das der Administrator kontrolliert.
• Die Allow/Deny-Entscheidung wurde nicht im Speicher umgedreht. Eine Supply-Chain-CVE im Evaluator läuft im selben Adressraum wie der Angreifer.
• Das Audit-Log spiegelt wider, was tatsächlich geschehen ist. Jede Partei, die den Software-Signaturschlüssel besitzt, kann im Nachhinein eine gültige Audit-Kette rekonstruieren.

Die Kontrollebene, die Tool-Aufrufe verwaltet, muss dort laufen, wo der von ihr verwaltete Prozess sie nicht erreichen kann.

Hardwaregestützte Durchsetzung von Richtlinien für MCP-Tool-Aufrufe. Jeder Tool-Aufruf wird abgefangen, gegen ein Cedar-Richtlinienbundle ausgewertet und von einer Richtlinien-Engine durchgesetzt, die in einer Trusted Execution Environment (TEE) läuft. Bevor der Gateway einen einzigen Tool-Aufruf bedient, misst er seinen installierten Code, das Richtlinienbundle und die Konfiguration in den Hardware-Attestierungsbericht ein und attestiert erneut, wann immer das Bundle neu geladen wird.

In einer Hardware-Bereitstellung verarbeitet die cMCP Runtime Tool-Aufruf-Payloads innerhalb der TEE. Was der Host und der Konnektivitätsanbieter lesen können, hängt auch von der Egress-Richtlinie ab, und der Upstream-Tool-Server ist eine separate Komponente außerhalb der TEE. Der Software-Modus (CMCP_DEV_MODE) bietet keine Hardware-Isolation. LIMITATIONS.md listet auf, was cMCP nicht verhindert.

---

Schnellstart

pip install cmcp-runtime

Erstelle cmcp-config.yaml:

attestation:
  provider: auto
  enforcement_mode: advisory   # advisory eases first-run tuning; the default is `enforcing`
listen_addr: "127.0.0.1:8443"  # pin loopback: dev mode runs without a 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 du Dinge schnell ausprobieren kannst, und die Standardbindung ist weiterhin 0.0.0.0:8443. In 0.3.0 richtete diese Kombination ein nicht authentifiziertes Gateway auf jeder Schnittstelle deiner Maschine ein. Ab 0.4.0 wird dies abgelehnt: tokenloser Dev-Modus darf nur eine Loopback-Adresse binden, und eine Nicht-Loopback-Bindung erfordert CMCP_BEARER_TOKEN. Lege listen_addr explizit fest, und die Konfiguration ist in beiden Fällen korrekt.

Starte das Gateway:

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

Einen Tool-Aufruf durchführen:

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

Lieber eine geführte Version? agentrust-io.com/quickstart führt dich in etwa zehn Minuten auf einem Laptop durch denselben Weg, ohne Hardware und ohne Anmeldung: installieren, eine Cedar-forbid-Regel schreiben, beobachten, wie ein Tool-Aufruf 403 POLICY_DENY zurückgibt, bevor er ein Upstream erreicht, und dann den signierten Beleg verifizieren.

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

---

Funktionsweise