Sichere MCP-Muster für Agenten, die Geschäftszustand verändern

Ein minimaler MCP-Server, der drei Muster für sicheren Schreibzugriff von KI-Agenten auf reale Geschäftssysteme zeigt: Phasen-Gating, Validierung vor Mutation und strukturierte Audit-Protokollierung.

Dies ist eine Demo, kein Produkt. Die Domäne (ein Spielzeug-Inventar- und Bestellsystem) existiert nur, um den Mustern etwas Konkretes zu geben, worauf sie angewendet werden können – die Muster selbst sind der Punkt, und sie sind domänenunabhängig.

Warum es das gibt

KI-Agenten erhalten zunehmend Schreibzugriff auf reale Systeme – Bestellungen, Inventar, CRM-Datensätze, Prognosen. Die häufige Fehlerquelle ist nicht, dass das zugrunde liegende LLM in einem abstrakten Sinne unzuverlässig ist; es ist, dass Implementierungen dem Modell oft vertrauen, „das Richtige zu tun", ohne strukturelle Schutzvorrichtung dahinter. Wenn ein Agent einen Zustand halluziniert, durch eine Prompt-Injection manipuliert wird oder nur die Reihenfolge der Operationen falsch versteht, ist das Ergebnis ein stiller, falscher Schreibvorgang in ein System, den ein Mensch jetzt im Nachhinein bemerken, diagnostizieren und beheben muss.

Die drei Muster unten sind keine neue Forschung – sie sind standardmäßige technische Disziplin für alles, was Produktionszustand berührt, angewendet speziell auf Agenten-Tool-Aufrufe.

Related MCP server: sop-mcp

Die drei Muster

1. Phasen-Gating. Eine mutierende Operation (submit_purchase_order) kann nur erfolgreich sein, wenn eine entsprechende Lese-/Vorschau-Operation (draft_purchase_order) zuvor in derselben Sitzung stattgefunden hat. Dies wird im Code erzwungen – ein harter Fehler, keine Prompt-Anweisung, die das Modell ignorieren oder aus der es sich herausreden lassen kann. Die Fehlermeldung sagt dem Aufrufer genau, was als Nächstes zu tun ist, was es einem Agenten ermöglicht, sich selbst zu korrigieren, statt nur zu scheitern.

2. Validierung vor Mutation. Jede Prüfung – existiert die SKU, ist die Menge vernünftig, überschreitet dies eine vernünftige Bestellschwelle – läuft gegen eine reine Darstellung der vorgeschlagenen Änderung, bevor irgendetwas geschrieben wird. Validierung hat niemals Nebenwirkungen. Und entscheidend: Alle Prüfungen laufen unabhängig von früheren Fehlern, sodass ein Aufrufer alle Probleme auf einmal sieht, statt eines zu beheben, erneut zu senden und auf das nächste zu stoßen.

3. Strukturierte Audit-Protokollierung. Jeder Tool-Aufruf wird protokolliert – einschließlich blockierter und abgelehnter, nicht nur erfolgreicher Mutationen. Eine Audit-Spur, die über verweigerte Versuche schweigt, vermisst genau die Ereignisse, die später am ehesten eine Überprüfung wert sind: Was hat der Agent versucht, das gestoppt wurde, und warum.

Die Demo

• examples/happy_path.md – Entwurf → Prüfung → Einreichung, mit echtem erfassten Output

• examples/blocked_paths.md – fünf Wege, auf denen die Sicherheitsebene tatsächlich einen schlechten Aufruf stoppt, ebenfalls mit echtem Output

Probieren Sie es selbst aus

pip install -r requirements.txt
pytest tests/ -v          # 17 tests, exercises every pattern above
python server.py          # runs the MCP server over stdio

Die Tests sind der eigentliche Beweis, nicht der obige Prosa. Wenn Sie eine Behauptung in dieser README verifizieren möchten, ist der entsprechende Test eine bessere Quelle der Wahrheit als meine Beschreibung davon.

Struktur

server.py              # MCP tool definitions — thin, delegates everywhere
safety/
  phases.py             # session state + the phase gate itself
  validation.py         # pure validation functions
  audit.py               # structured logging, including failures
domain/
  inventory.py           # toy in-memory "database"
  purchase_orders.py    # draft/commit data + transformations
tests/                   # one file per pattern, ~17 tests total
examples/                 # real captured walkthroughs

safety/ und domain/ importieren nicht voneinander in der Richtung, die man von einer Aufteilung in „Geschäftslogik" und „Schutzvorrichtungen" erwarten würde: Die Domänenschicht hat keine Ahnung, dass Sitzungen oder Genehmigungen existieren. Das Gate lebt vollständig außerhalb davon, in safety/phases.py, das entscheidet, ob domain.purchase_orders.commit_draft() jemals erreicht wird. Diese Trennung ist beabsichtigt – sie ist es, die es möglich macht, über die Sicherheitseigenschaften nachzudenken, ohne gleichzeitig über Inventarlogik nachdenken zu müssen.

Was dies nicht ist

Kein Produktionscode. Keine echte Datenbank – Inventar ist ein Python-Dict. Keine Authentifizierung. Sitzungszustand ist im Speicher und Single-Process. Dies existiert, um die Sicherheitsmuster isoliert prüfbar und testbar zu machen, nicht um ein System zu sein, das jemand bereitstellen sollte.

Hintergrund

Ich habe während meines Praktikums bei Eli Lilly Produktions-MCP-Server (Go, Kubernetes) entworfen und gebaut, einschließlich phasengesteuertem Tool-Zugriff und obligatorischer Validierung vor jeder zustandsverändernden Bereitstellungsoperation. Diese Demo ist frisch gebaut, in einer anderen Domäne, ohne diesen Code zu verwenden – sie isoliert dieselben zugrunde liegenden Muster, sodass sie gelesen, ausgeführt und getestet werden können, ohne Zugriff auf etwas Proprietäres zu benötigen.