protect-mcp

Fail-closed Cedar-Richtlinien-Gate plus signierte Belege für Tool-Aufrufe von KI-Agenten.

protect-mcp ist ein Gate, das vor den Tool-Aufrufen eines KI-Agenten sitzt. Es bewertet jeden Aufruf anhand einer Cedar-Richtlinie, blockiert, was gegen die Regeln verstößt, bevor es ausgeführt wird, und signiert einen offline verifizierbaren Ed25519-Beleg für jede Entscheidung. Das konfigurierte Gateway läuft lokal und sendet keine Entscheidungs-Telemetrie. Der separate Koordinationsadapter verbindet sich mit ScopeBlinds gehostetem Kollaborationsdienst; seine Anfragen und zurückgegebenen Datensätze haben den unten beschriebenen Datenpfad. Beide sind MIT-lizenziert.

Für gemeinsame Repository-Arbeit nutzen Sie Client-Projekte: Personen einigen sich auf das Briefing und die Grenzen, Agenten bereiten Reviews vor, und beide Personen genehmigen eine exakte Version, bevor der Receiver des Eigentümers das Repository ändern kann. Der Repository-Workflow unten enthält die Einrichtung und die fünf begrenzten Agenten-Tools.

Warum es anders ist

• Standardmäßig fail-closed. Bei jedem Richtlinienfehler, einer fehlenden Engine oder einem Bewertungsfehler lautet die Entscheidung DENY. Das Gate erlaubt niemals stillschweigend. Ein Observe-Modus existiert für den Shadow-Rollout, aber selbst dort wird ein Aufruf, der blockiert würde, mit would_deny: true gekennzeichnet, sodass ein Fehler niemals still bleibt.
• Es beweist seine eigene Zurückhaltung. serve --enforce und doctor führen einen Start-Selbsttest aus und weigern sich, das Gate zu scharf zu schalten, es sei denn, sie können zeigen, dass eine bekanntermaßen verbotene Aktion tatsächlich verweigert wird. Ein Gate, das nicht beweisen kann, dass es verweigert, startet nicht.
• Jede Entscheidung ist ein Beleg, den jeder verifizieren kann. Entscheidungen sind Ed25519-signiert und offline verifizierbar mit @veritasacta/verify. Die Signaturverifikation benötigt keine Netzwerkabfrage. Aussagen über die Ausführung hängen jedoch weiterhin vom identifizierten Gate-Betreiber ab.

Schnellstart: von der Installation zum ersten nützlichen Nachweis

# 1. Generate an Ed25519 keypair, config template, and sample policy.
npx protect-mcp init

# 2. Print a shadow-mode client configuration, then apply it in your MCP host.
#    This command prints configuration and exits; it does not launch the server.
npx protect-mcp wrap -- node your-mcp-server.js

# 3. Reopen the host and use its tools, then inspect the local-only dashboard.
npx protect-mcp dashboard --open

# 4. Draft a reviewable policy from observed calls.
npx protect-mcp recommend --write

# 5. When reviewed, restart the wrapper in enforce mode with that policy.
npx protect-mcp --policy protect-mcp.recommended.json --enforce -- node your-mcp-server.js

Für Claude Desktop führen Sie zuerst einen Dry-Run-Konfigurations-Patch aus und wenden ihn dann an:

npx protect-mcp wrap --claude-desktop
npx protect-mcp wrap --claude-desktop --write
npx protect-mcp dashboard --open

Das Dashboard bindet an 127.0.0.1, liest nur lokale Log-/Receipt-Dateien und lädt nichts hoch. Verwende npx protect-mcp connect nur, wenn du explizit ein gehostetes ScopeBlind-Dashboard möchtest.

Das Gate als MCP-Server

Wenn du das Gate lieber als Tools aufrufen möchtest, anstatt die Claude Code Hooks zu verdrahten, führe es als MCP-Server aus:

npx protect-mcp mcp

Es spricht MCP über stdio und stellt vier schreibgeschützte Tools bereit, den gesamten Ablauf:

• evaluate_action: entscheidet einen vorgeschlagenen Tool-Aufruf anhand einer Inline-Cedar-Richtlinie, fail-closed (jeder Richtlinienfehler ist DENY). Gibt { allowed, decision, reason, policy_digest } zurück.
• sign_decision: verwandelt eine Entscheidung in eine Ed25519-signierte Quittung (eine Ablehnung signiert eine gateway_restraint, eine Genehmigung eine decision_receipt). Gibt die Quittung und ihren öffentlichen Schlüssel zurück; generiert einen ephemeren Schlüssel, wenn Sie keinen bereitstellen.
• verify_receipt: verifiziert eine signierte Quittung offline gegen einen öffentlichen Schlüssel. Gibt { valid, error, type, kid, issuer } zurück.
• self_test: beweist es, ohne Eingaben. Eine bekanntermaßen verbotene Aktion wird abgelehnt, dann durchläuft eine signierte Quittung einen Round-Trip und eine manipulierte Kopie schlägt fehl.

Richten Sie einen beliebigen MCP-Host darauf aus, zum Beispiel Claude Desktop:

{
  "mcpServers": {
    "protect-mcp": { "command": "npx", "args": ["-y", "protect-mcp", "mcp"] }
  }
}

Receipts sind byte-kompatibel mit denen, die das Gate zur Laufzeit signiert, sodass ein hier erzeugtes Receipt dieselbe Acta-Hülle verwendet. Verifikationsfähigkeiten und Kanonisierungs-Kompatibilität hängen von der Verifier-Version ab; verwenden Sie die verifyReceipt-API des Gateways für das unten beschriebene Konformitätsverhalten.

Kompatibilität der Receipt-Kanonalisierung

Dieser Quellbaum behebt den Defekt der Integer-Key-Reihenfolge, der bis 0.14.0 vorhanden war: Signaturen und Chain-Hashes verwenden jetzt direkte JCS-Member-Emission und behalten dabei das ASCII-Objekt-Key-Profil des Gateways bei. Numerisch aussehende Keys wie "10" stehen vor "2", auch innerhalb verschachtelter Objekte. Nicht-JSON-Werte und ungültiges Unicode werden abgelehnt.

Gewöhnliche JSON-Receipts, deren Kodierungen unverändert sind, verifizieren weiterhin. Historische Receipts, die mit der alten numerischen Key-Reihenfolge signiert wurden, werden als legacy_non_jcs_signature gemeldet; die strikte Verifikation bezeichnet sie nicht als gültiges JCS. Für eine explizite historische Kompatibilitätsprüfung verwenden Sie verifyReceipt(receipt, publicKey, { allowLegacyNumericKeys: true }) und inspizieren Sie die Felder canonicalization und warning. Dessen hash ist dann der ursprüngliche historische Hash. Bewahren Sie Original-Receipts und Chain-Links auf: Das Neuberechnen eines alten Receipts mit numerischen Keys mittels receiptHash erzeugt jetzt dessen JCS-Hash und kann die historische Chain brechen. Diese Änderungen sind in 0.15.0 enthalten.

Beginnen Sie mit Ihrem Agenten, dann autorisieren Sie jede Aufgabe

Version 0.25.0 enthält ein wiederverwendbares Agentenprofil. Öffnen Sie Starten Sie über Ihren Agenten für den Einrichtungsbefehl mit dem angezeigten Authority-Key des Dienstes. Prüfen Sie diesen Key gegen eine vertrauenswürdige Quelle, bevor Sie sich verbinden. Zum Beispiel:

npx --yes [email protected] coordination agent setup \
  --client claude-code \
  --profile ~/.scopeblind/agent.json \
  --endpoint https://scopeblind.com/api/coordination \
  --authority-key PINNED_64_HEX_AUTHORITY_KEY

Verwende --client codex oder --client json für diese Registrierungsanweisungen. Das Setup gibt die Konfiguration aus; wende sie in deinem Client an und öffne diesen Client dann erneut. Das private Profil enthält einen Agent-Schlüssel und separat abgegrenzte Verbindungen, mit Dateiberechtigungen 600. Das Setup gewährt keine Task-Berechtigungen und kopiert keinen menschlichen Browser-Schlüssel. Der registrierte Server führt coordination agent --profile FILE aus.