cmcp

<p align="center">
  <img src="https://raw.githubusercontent.com/agentrust-io/cmcp/HEAD/docs/assets/icon.svg" width="96" height="96" alt="cMCP"/>
</p>

# cMCP: Vertrauliche MCP-Laufzeitumgebung

Community-Updates und Highlights von Mitwirkenden: [AgenTrust auf LinkedIn](https://www.linkedin.com/company/agentrust-io/).

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

<p align="center">
  <a href="https://cmcp.agentrust-io.com">
    <img src="https://img.shields.io/badge/Documentation-cmcp.agentrust--io.com-7c3aed?style=for-the-badge" alt="Dokumentation" height="36">
  </a>
</p>

<p align="center">
  <strong>
    <a href="#quick-start">Schnellstart</a> ·
    <a href="#how-it-works">Architektur</a> ·
    <a href="#configuration">Konfiguration</a> ·
    <a href="#cli-reference">CLI</a> ·
    <a href="https://github.com/agentrust-io/cmcp/blob/main/CHANGELOG.md">Änderungsprotokoll</a>
  </strong>
</p>

[![CI](https://github.com/agentrust-io/cmcp/actions/workflows/ci.yml/badge.svg?branch=main)](https://github.com/agentrust-io/cmcp/actions/workflows/ci.yml) [![License: MIT](https://img.shields.io/badge/license-MIT-blue)](LICENSE) [![PyPI](https://img.shields.io/pypi/v/cmcp-runtime)](https://pypi.org/project/cmcp-runtime/) [![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/agentrust-io/cmcp/badge)](https://scorecard.dev/viewer/?uri=github.com/agentrust-io/cmcp) [![Discord](https://img.shields.io/badge/Discord-Join-5865F2?logo=discord&logoColor=white&style=flat)](https://discord.gg/grgzFEHgkj)

> **Developer Preview** – vorgestellt auf dem Confidential Computing Summit, 23. Juni 2026. Bis v1.0 sind möglicherweise Breaking Changes möglich. Siehe [STATUS.md](https://github.com/agentrust-io/cmcp/blob/main/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](https://agentrust-io.com/#plain-terms).

> **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](https://github.com/agentrust-io/cmcp/blob/main/LIMITATIONS.md) listet auf, was cMCP nicht verhindert.

---

## Schnellstart

```bash
pip install cmcp-runtime
```

Erstelle `cmcp-config.yaml`:

```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:

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

Einen Tool-Aufruf durchführen:

```bash
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](https://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](https://github.com/agentrust-io/cmcp/blob/main/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

1. Der Agent sendet jeden Tool-Aufruf an das cMCP Gateway statt direkt an MCP-Server.
2. Beim Start, bevor es Traffic bedient, misst das Gateway seinen installierten Code, das Cedar-Policy-Bundle und die Konfiguration. Auf SEV-SNP, TDX und Azure CVM wird der Digest in `report_data` gebunden; auf der TPM-Stufe wird er in einen zertifizierten NV-Index erweitert. Ein Policy-Reload löst eine frische Attestierung aus.
3. Jeder eingehende Tool-Aufruf wird von der Cedar-Policy-Engine ausgewertet, die innerhalb der TEE läuft. Das Ergebnis ist allow, deny oder redact. Der Aufruf und seine Entscheidung werden an die hardwareversiegelte Audit-Kette angehängt.
4. Am Ende der Sitzung erzeugt das Gateway einen TRACE Claim: ein signiertes, hardware-attestiertes Artefakt, das festhält, welche Tools ausgeführt wurden, welche Policy jeden Aufruf entschieden hat und die vollständige Audit-Kette. Ein Verifier prüft dies, ohne dem Betreiber vertrauen zu müssen.

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

| Anbieter | Plattform | Zusicherung | Hinweise |
|---|---|---|---|
| `tpm` | TPM 2.0 / vTPM (Azure, AWS, GCP Trusted Launch) | Mittel | Lokales TPM-Quote |
| `sev-snp` | AMD SEV-SNP (Azure DCasv5, AWS C6a Nitro) | Hoch | AMD KDS |
| `tdx` | Intel TDX (Azure DCedsv5, GCP C3) | Hoch | Intel PCS |
| `gpu-cc` _(v0.2)_ | NVIDIA H100/H200/Blackwell (CC-Modus) | Hoch | NVIDIA Remote Attestation Service (NRAS) |

Reihenfolge der Auto-Erkennungsprüfung der Anbieter: `azure-cvm -> tpm -> sev-snp -> tdx`. Der erste Anbieter, dessen `detect()` erfolgreich ist, wird ausgewählt. Wenn kein Hardware-Anbieter erkannt wird, startet das Gateway nur unter `CMCP_DEV_MODE=1` (ein nicht-attestierter, rein softwarebasierter Fallback) und verweigert andernfalls den Start.

```python
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
```

## Durchsetzungsmodi

| Modus | Verhalten | Anwendungsfall |
|---|---|---|
| `enforcing` | Richtlinien-Ablehnungen geben HTTP 403 zurück; der Aufruf wird nicht weitergeleitet | Produktion |
| `advisory` | Richtlinien-Ablehnungen werden protokolliert; der Aufruf wird fortgesetzt | Erste Bereitstellung, Richtlinien-Feinabstimmung |
| `silent` | Die Richtlinie wird ausgewertet, aber nichts wird protokolliert oder blockiert | Baseline-Erstellung |

Der 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`:

```yaml
attestation:
  provider: auto                    # auto | tpm | sev-snp | tdx | 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: "127.0.0.1:8443"     # tokenless dev mode is loopback-only; set CMCP_BEARER_TOKEN before binding wider
max_response_size_bytes: 2097152    # 2 MB default
policy_reload_interval_seconds: 0   # >0 with a pinned CMCP_POLICY_HASH refuses to start, see docs/spec/policy-hot-reload.md
```

Umgebungsvariablen:

| Variable | Wirkung |
|---|---|
| `CMCP_DEV_MODE=1` | Verwendet einen rein softwarebasierten TEE-Provider; keine Hardware erforderlich |
| `CMCP_BEARER_TOKEN` | Erfordert dieses Bearer-Token bei allen eingehenden Anfragen |

---

## CLI-Referenz

| Befehl | Flags | Beschreibung |
|---|---|---|
| `cmcp start` | `--config PATH` (erforderlich) | Startet das Gateway |
| `cmcp validate-config` | `--config PATH` (erforderlich) | Validiert `cmcp-config.yaml`, ohne zu starten |
| `cmcp validate-bundle` | `--bundle-path PATH` (erforderlich), `--expected-hash sha256:<hex>` (erforderlich) | Überprüft einen Cedar-Bundle-Hash vor der Bereitstellung |
| `cmcp verify` | `CLAIM_FILE` (erforderlich); `--policy-hash`, `--catalog-hash`, `--max-age`, `--trusted-key`, `--trusted-tpm-ca`, `--audit-bundle`, `--agent-manifest`, `--agent-manifest-trust-anchor` | Überprüft einen signierten TRACE Claim (Signatur, Schema, Aktualität, Audit-Kette, gepinnte Hashes und Trust Anchors) |

---

## TRACE Claims

Ein `GatewayClaim` ist die Nachweiseinheit, die einem Auditor, Regulator oder 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.

| Feld | Beschreibung |
|---|---|
| `trace.eat_profile` | EAT-Profil-URI: `tag:agentrust-io.com,2026:trace-v0.2` |
| `trace.runtime` | TEE-Plattform und Hardware-Messung, aufgezeichnet beim Start der Enclave |
| `trace.policy.bundle_hash` | SHA-256 des beim Start geladenen Cedar-Bundles; jede Änderung an einer Policy-Datei ändert diesen Wert |
| `trace.cnf.jwk` | Ed25519-Public-Key, gebunden an den TEE-Signaturschlüssel |
| `trace.tool_transcript` | Aus der Audit-Kette abgeleitete Pro-Aufruf-Ansicht: `hash` (bindet an die Spitze der Audit-Kette), `call_count` und datenschutzwahrende `entries` (Tool-Name, Datenklasse, Entscheidung) |
| `gateway.audit_chain` | Hash-verkettete Audit-Log-Wurzel und -Spitze; verifizierbar ohne Wiedergabe einzelner Einträge |
| `signature` | Ed25519 über kanonisches JSON des vollständigen Claim-Bodys (RFC 8785) |

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

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

Das normative Schema ist [`schemas/trace-claim.schema.json`](https://github.com/agentrust-io/cmcp/blob/main/schemas/trace-claim.schema.json), und [docs/quickstart.md](https://github.com/agentrust-io/cmcp/blob/main/docs/quickstart.md) zeigt ein vollständiges Beispiel. Siehe [docs/spec/verification-library.md](https://github.com/agentrust-io/cmcp/blob/main/docs/spec/verification-library.md) und die [TRACE-Spezifikation](https://trace.agentrust-io.com) für das vollständige Verifikationsprotokoll.

---

## Ausrichtung an Standards

| Standard | Abdeckung |
|---|---|
| OWASP Agentic AI Top 10 | MCP10 (Datenabfluss über Tool-Aufrufe), MCP02 (nicht genehmigte Tools), MCP08 (nachweisbare Governance), MCP04 (Lieferkette) |
| NIST SP 800-207 | Policy Decision Point innerhalb der TEE; kein implizites Vertrauen in die Workload-Identität |
| EU AI Act Art. 12, 15 | Audit-Aufzeichnungen pro Entscheidung (Art. 12); TEE-gestützte Cybersicherheitskontrollen (Art. 15) |
| DORA Art. 9 | Attestierungskette; Aufbewahrung des Audit-Logs über `gateway.audit_chain` |
| RATS/EAT RFC 9711 | `GatewayClaim` ist ein EAT; das Feld `eat_profile` identifiziert das TRACE-Profil |

---

## Sicherheit

| Tool | Was es prüft |
|---|---|
| ruff | Style- und Import-Linting bei jedem PR |
| bandit | Python-Sicherheits-Linting bei jedem PR |
| pip-audit | Schwachstellenscan der Abhängigkeiten bei jedem PR |
| mypy | Statische Typprüfung bei jedem PR |
| CodeQL | Python-SAST, security-extended-Abfragen, wöchentlich |
| OpenSSF Scorecard | Wöchentliche Bewertung, SARIF-Upload |

Siehe [SECURITY.md](https://github.com/agentrust-io/cmcp/blob/main/SECURITY.md) für die Meldung von Schwachstellen und Response-SLAs. Siehe [LIMITATIONS.md](https://github.com/agentrust-io/cmcp/blob/main/LIMITATIONS.md) für explizite Geltungsbereichsgrenzen, einschließlich Restrisiken bei der APM-Payload-Erfassung, der Laufzeit-Konfigurationsinjektion und der P4.1-Lieferkette (Typosquatting), die Phase 1 nicht schließt.

---

## Dokumentation

| Seite | Beschreibung |
|---|---|
| [docs/quickstart.md](https://github.com/agentrust-io/cmcp/blob/main/docs/quickstart.md) | Von null zum ersten TRACE Claim in unter 30 Minuten |
| [docs/configuration.md](https://github.com/agentrust-io/cmcp/blob/main/docs/configuration.md) | Vollständige Konfigurationsreferenz mit allen Feldern und Standardwerten |
| [docs/confinement.md](https://github.com/agentrust-io/cmcp/blob/main/docs/confinement.md) | Experimentelle Linux-Agent-Sandbox, Bypass-Tests und Vertrauensannahmen |
| [docs/SPEC.md](https://github.com/agentrust-io/cmcp/blob/main/docs/SPEC.md) | Produktspezifikation: Problem-Taxonomie, Architektur, Abdeckungsmatrix |
| [docs/spec/threat-model.md](https://github.com/agentrust-io/cmcp/blob/main/docs/spec/threat-model.md) | STRIDE-Analyse, Angreifermodell, Restrisiken |
| [docs/spec/cedar-policy.md](https://github.com/agentrust-io/cmcp/blob/main/docs/spec/cedar-policy.md) | Referenz zur Cedar-Policy-Sprache und Schema |
| [docs/testing/benchmarks.md](https://github.com/agentrust-io/cmcp/blob/main/docs/testing/benchmarks.md) | Latenz- und Durchsatz-Benchmarks pro TEE-Anbieter |

---

## FAQ

### Was ist cMCP?

cMCP (Confidential MCP Runtime) ist ein Open-Source-Gateway, das die Richtlinie für MCP-Tool-Aufrufe innerhalb einer hardwarebasierten Trusted Execution Environment durchsetzt. Es fängt jeden Tool-Aufruf ab, wertet ihn gegen ein Cedar-Policy-Bundle aus, setzt die Entscheidung durch (erlauben, verweigern oder redigieren) und zeichnet den Aufruf in einer hardwareversiegelten Audit-Kette auf.

### Wie unterscheidet sich cMCP von rein softwarebasierter MCP-Governance?

Rein softwarebasierte Governance führt die Policy-Engine im selben Betriebssystem aus, auf das ein Betreiber oder eine Supply-Chain-CVE zugreifen kann. Daher kann sie nicht beweisen, dass die ausgeführte Richtlinie die genehmigte war oder dass die Entscheidung nicht im Speicher manipuliert wurde. cMCP führt die Policy-Engine innerhalb einer TEE aus und misst ihren Code sowie das Cedar-Bundle in den Hardware-Attestierungsbericht ein, bevor auch nur ein einziger Aufruf bedient wird. Dadurch kann die Control Plane nicht von dem Prozess erreicht werden, den sie kontrolliert.

### Benötige ich spezielle Hardware, um es auszuprobieren?

Nein. Setzen Sie `CMCP_DEV_MODE=1`, um den rein softwarebasierten TEE-Anbieter zu verwenden und den vollständigen Quickstart ohne Hardware-TEE auszuführen. Hardware-Anbieter (TPM, AMD SEV-SNP, Intel TDX) werden in der Produktion eingesetzt.

### Was ist ein TRACE Claim?

Ein TRACE Claim (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 Hash des Cedar-Bundles und die Audit-Kette, und es wird mit einem Ed25519-Schlüssel signiert, der die TEE niemals verlässt. Ein Verifizierer prüft es mit der `cmcp_verify`-Bibliothek, ohne dem Betreiber vertrauen zu müssen.

### 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. Die Reihenfolge der automatischen Erkennung ist Azure Confidential VM, dann TPM 2.0 / vTPM, dann AMD SEV-SNP, dann Intel TDX; der rein softwarebasierte Anbieter wird nur unter CMCP_DEV_MODE=1 verwendet.

### Unter welcher Lizenz steht cMCP?

MIT.

---

## Mitwirken

[CONTRIBUTING.md](https://github.com/agentrust-io/cmcp/blob/main/CONTRIBUTING.md) · [GOVERNANCE.md](https://github.com/agentrust-io/cmcp/blob/main/GOVERNANCE.md) · [Diskussionen](https://github.com/orgs/agentrust-io/discussions)

Treten Sie der Community auf [Discord](https://discord.gg/grgzFEHgkj) bei.

Setzen Sie cMCP in der Produktion ein? Fügen Sie Ihre Organisation zu [ADOPTERS.md](https://github.com/agentrust-io/cmcp/blob/main/ADOPTERS.md) hinzu.

---

## Lizenz

MIT – siehe [LICENSE](https://github.com/agentrust-io/cmcp/blob/main/LICENSE).