cMCP: Vertrauliche MCP-Laufzeitumgebung

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

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

Schnellstart · Architektur · Konfiguration · CLI · Changelog

Developer Preview – vorgestellt auf dem Confidential Computing Summit, 23. Juni 2026. Kann vor v1.0 Breaking Changes enthalten. Siehe STATUS.md für eine genaue Übersicht, was heute ausgeliefert wird und was sich auf der Roadmap befindet.

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 Cedar-Richtliniensprache) 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 abschirmt) laufen, wo der verwaltete Agent es nicht erreichen kann. Jede Sitzung endet mit einem signierten Beleg, einem TRACE Claim, den jeder überprü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 (kein 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 (schwärzt) 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, ein Dutzend APIs auf. Was hindert ihn daran, bei einem dieser Aufrufe die Daten eines Kunden preiszugeben? Wenn eine Aufsichtsbehörde fragt, könnten Sie beweisen, dass er es nicht getan hat?

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. Software-basierte MCP-Governance kann nicht garantieren:

Die Cedar-Richtlinie auf der Festplatte ist diejenige, die ausgeführt wurde. Ein bösartiger Administrator kann das Bundle nach der Genehmigung austauschen; die Hash-Prüfung läuft innerhalb desselben Betriebssystems, das der Administrator kontrolliert.
Die Erlauben/Verweigern-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 passiert ist. Jede Partei, die den Software-Signaturschlüssel besitzt, kann nachträglich eine gültige Audit-Kette rekonstruieren.

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

Hardware-attestierte Richtliniendurchsetzung für MCP-Tool-Aufrufe. Jeder Tool-Aufruf wird abgefangen, gegen ein Cedar-Richtlinien-Bundle ausgewertet und von einer Policy-Engine durchgesetzt, die in einer Trusted Execution Environment (TEE) läuft. Bevor sie einen einzigen Tool-Aufruf bedient, misst das Gateway seinen installierten Code, das Richtlinien-Bundle 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-Nutzlasten innerhalb der TEE. Was der Host und der Konnektivitätsanbieter lesen können, hängt auch von der Egress-Richtlinie ab, und der vorgelagerte 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

Erstellen Sie cmcp-config.yaml:

attestation:
  provider: auto
  enforcement_mode: advisory   # advisory erleichtert die Abstimmung beim ersten Start; der Standard ist `enforcing`
listen_addr: "127.0.0.1:8443"  # Loopback festlegen: der Dev-Modus 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 richtete diese Kombination ein nicht authentifiziertes Gateway auf jeder Schnittstelle Ihres Rechners ein. Ab 0.4.0 wird dies abgelehnt: tokenloser Dev-Modus darf nur eine Loopback-Adresse binden, und ein Nicht-Loopback-Bind erfordert CMCP_BEARER_TOKEN. Legen Sie listen_addr explizit fest, dann ist die Konfiguration in beiden Fällen korrekt.

Starten Sie das Gateway:

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

Führen Sie einen Tool-Aufruf aus:

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 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-Richtlinie, Tool-Katalog, erster TRACE Claim und Verifikation (keine Hardware-TEE erforderlich).

cmcp v0.4.0