mcp-policy-gateway

Eine Policy-first-MCP-Server-Referenzimplementierung. Sie zeigt, wie man einem Agenten nützliche Werkzeuge bereitstellt, ohne dem Modell zu erlauben, Autorisierungen zu entscheiden, Mandantengrenzen zu überschreiten, direkte personenbezogene Daten (PII) preiszugeben oder eigenständig risikoreiche Mutationen auszuführen.

Dies ist eine Portfolio-/Referenzimplementierung. Alle Datensätze sind synthetisch; es ist keine Produktionssoftware und erhebt nicht den Anspruch, in ein Bank-, Zahlungsabwicklungs- oder Kundensystem integriert zu sein.

Warum dieses Projekt existiert

Ein übliches MCP-Demo stellt einem Modell eine rohe API zur Verfügung und behandelt einen erfolgreichen Tool-Aufruf als Sicherheitsmodell. Dieses Projekt vertritt die gegenteilige Position:

• Policy ist deterministisch. Das Modell kann sich nicht selbst autorisieren.

• Die Mandantengrenze wird serverseitig durchgesetzt. Ein Tool-Argument kann den Mandanten nicht wechseln.

• Die Tool-Ausgabe ist minimiert. Die Kontozusammenfassung schließt Eigentümername und E-Mail bewusst aus.

• Risikoreiche Aktionen enden an einem Genehmigungs-Gate. Eine Sperranfrage erzeugt keine Zustandsänderung.

• Jede Entscheidung ist auditierbar. Allow-, Deny- und Genehmigungsergebnisse erzeugen strukturierte Audit-Ereignisse.

• Mutationsanfragen erfordern einen Grund und einen Idempotenzschlüssel.

Related MCP server: scopeguard-mcp

Architektur

MCP client / agent
       │ tool call
       ▼
FastMCP stdio adapter
       │ verified principal (demo fixture here)
       ▼
GatewayService ──► PolicyEngine ──► allow / deny / require approval
       │                 │
       ▼                 ▼
synthetic domain data   structured audit event

In einer Produktionsumgebung würde der Principal aus einer verifizierten Identität/Sitzung außerhalb des Modellkontexts abgeleitet. Akzeptieren Sie tenant_id, Rollen oder Scopes niemals aus einem Tool-Argument oder einer Modellausgabe.

Tools

Schnellstart

Erfordert Python 3.11+.

python -m venv .venv
.venv/bin/pip install -e '.[dev]'
.venv/bin/pytest
.venv/bin/ruff check .

Als MCP-stdio-Server ausführen:

.venv/bin/mcp-policy-gateway

Der Adapter verwendet für die lokale Erkundung bewusst einen festen Demo-Principal. Die echte Identitätsweitergabe wird absichtlich als Produktionsintegrationsaspekt dokumentiert und hier nicht simuliert.

Demonstrierte Missbrauchskontrollen

Die Tests beweisen, dass das Gateway:

1. einem Agenten aus tenant_red den Zugriff auf Daten von tenant_blue verweigert;

2. einen Tool-Aufruf ohne den erforderlichen Scope verweigert;

3. Eigentümername oder E-Mail nicht über das Zusammenfassungs-Tool zurückgibt;

4. require_approval zurückgibt, anstatt den Kontostatus zu mutieren; und

5. zustandsändernde Anfragen ablehnt, die einen Grund oder Idempotenzschlüssel auslassen.

Bedrohungsmodell und Nicht-Ziele

Siehe THREAT_MODEL.md. Das Design ist bewusst eng gefasst: Es demonstriert eine Policy-Grenze um MCP-Tools, nicht eine vollständige Identitätsinfrastruktur, dauerhafte Audit-Speicherung, Secrets-Management oder ein Zahlungs-/Hauptbuchsystem.

Interview-Durchlauf

Eine prägnante Möglichkeit, das Projekt zu erklären:

Ich habe die MCP-Grenze so gestaltet, dass das Modell über sichere, scoped Daten nachdenken kann, aber keinen Zugriff entscheiden oder risikoreiche Aktionen ausführen kann. Die Autorisierung ist deterministisch, die Mandantenisolierung wird serverseitig durchgesetzt, die Tool-Oberfläche minimiert personenbezogene Daten (PII), und sensible Mutationen enden in einem auditierbaren menschlichen Genehmigungs-Gate.

Entwicklung

.venv/bin/pytest
.venv/bin/ruff check .

CI führt beide Prüfungen bei Pushes und Pull Requests aus.

Lizenz

MIT. Siehe LICENSE.