Ein MCP-Server kann technisch einwandfrei funktionieren und trotzdem keine gute Idee für den Produktivbetrieb sein. Die Verbindung ist hergestellt, die Tools erscheinen im Client und der erste Aufruf klappt. Aber wer darf welches Werkzeug mit welchen Argumenten ausführen? Wer trägt die Verantwortung für eine Veröffentlichung, eine Zahlung oder einen Shell-Befehl? Und was lässt sich nach einem Fehler tatsächlich rekonstruieren?
Genau dafür habe ich die kostenlose MCP Tool Risk Map gebaut. Sie nimmt eine reale tools/list-Antwort, klassifiziert jedes Werkzeug nach seiner Wirkung und erzeugt daraus einen maschinenlesbaren Control Contract.
Die Analyse läuft vollständig im Browser. Es gibt keinen Upload, kein Backend und keine Modell-API.
Was sich durch MCP 2026 verändert hat
Am 28. Juli 2026 ist eine neue MCP-Spezifikation erschienen. Der Kern ist nun stateless. Die bisherigen Initialisierungs- und Sitzungsmechanismen entfallen. Bei HTTP-Verbindungen machen die Header Mcp-Method und Mcp-Name Methode und Tool bereits auf Gateway-Ebene sichtbar.
Das ist für Unternehmen relevant. Wenn der Name eines aufgerufenen Tools vor der Ausführung erkennbar ist, kann ein Gateway eine deterministische Richtlinie anwenden. Zum Beispiel:
search_public_docsdarf automatisch laufenget_customer_recordbraucht eine eindeutige Nutzeridentität und ein Audit-Logupdate_crm_contactbraucht eine Freigabe für den konkreten Datensatzpublish_linkedin_postbleibt standardmäßig gesperrtrun_shell_commanddarf nur isoliert und mit eng begrenzten Argumenten ausgeführt werden
Die Spezifikation schafft dafür einen guten technischen Kontrollpunkt. Sie liefert aber nicht die unternehmensspezifische Entscheidung, welches Tool unter welchen Bedingungen erlaubt sein soll.
Die Recherche hat meine erste Idee verändert
Mein erster Entwurf war ein klassischer MCP-Konfigurationscheck. Er sollte Inline-Secrets, unverschlüsselte Endpunkte, breite Dateisystempfade und ungepinnte Paketstarts erkennen.
Nach einer breiteren Markt- und Quellenrecherche habe ich diesen Ansatz verworfen. Für genau diese Aufgabe gibt es bereits mehrere Browser-Scanner und deutlich umfangreichere Open-Source-Werkzeuge. Der MCP Scanner von Cisco AI Defense untersucht beispielsweise Konfigurationen, Remote- und lokale Server, Paketquellen und bekannte Schwachstellen. MCP-Scan von Invariant Labs fokussiert unter anderem Tool Poisoning und Veränderungen von Tool-Beschreibungen zur Laufzeit.
Ein weiterer Ampel-Scanner hätte funktioniert. Er hätte aber kaum gezeigt, wie aus einem technischen Befund eine betriebliche Entscheidung wird.
Die interessantere Lücke liegt zwischen Entdeckung und Durchsetzung:
- Ein Client entdeckt ein Tool.
- Eine Organisation muss dessen Wirkung verstehen.
- Daraus entstehen Regeln für Identität, Freigabe, Argumente, Limits und Protokollierung.
- Erst danach kann ein Gateway oder eine Plattform die Entscheidung zuverlässig durchsetzen.
Mein Tool konzentriert sich auf die Schritte zwei und drei.
Warum ein Tool-Name allein nicht reicht
Die offiziellen MCP Security Best Practices warnen unter anderem vor schädlichen lokalen Startbefehlen, zu breiten Dateisystem- und Netzwerkrechten, unsicheren URL-Schemata und der Eskalation von Webangriffen über lokale MCP-Proxys. Für lokale Server wird stdio bevorzugt. Remote-Verbindungen benötigen saubere Authentifizierung, Transportverschlüsselung und klar begrenzte Vertrauenszonen.
Auch der OWASP MCP Security Cheat Sheet geht deutlich über Konfiguration hinaus. Er nennt Least Privilege, Integrität von Tool-Beschreibungen und Schemas, Isolation, menschliche Freigaben, Validierung, Supply-Chain-Risiken, Monitoring und Prompt Injection durch Tool-Antworten.
Die Security Design Considerations der NSA betrachten MCP ebenfalls als System aus Vertrauensgrenzen. Besonders relevant sind dynamische Tool-Aufrufe, implizites Vertrauen, geteilte Kontexte, Token- und Session-Sicherheit sowie gefährliche Datenflüsse zwischen mehreren Servern.
Das gemeinsame Muster: Ein Tool darf nicht nur nach seiner technischen Erreichbarkeit bewertet werden. Entscheidend sind Wirkung, Datenklasse, handelnde Identität und Umgebung.
Vier Risikostufen statt einer falschen Gesamtnote
Ich habe mich bewusst gegen einen einzelnen „Security Score“ entschieden. Eine Zahl wie 82 von 100 wirkt präzise, obwohl sehr unterschiedliche Risiken dahinterstehen können. Ein einziger unkontrollierter Zahlungs- oder Publishing-Aufruf ist nicht durch zehn harmlose Lese-Tools kompensierbar.
Die Risk Map nutzt deshalb vier nachvollziehbare Stufen:
R0: Public Read
Ein rein lesender Zugriff auf öffentliche Daten. Die Eingabe wird validiert und die Antwort bleibt nicht vertrauenswürdig, aber der Aufruf kann häufig automatisch erlaubt werden.
R1: Sensitive Read
Das Tool liest interne, vertrauliche oder personenbezogene Daten. Der Zugriff braucht eine eindeutige Identität, eng begrenzte Rechte und ein Audit, das den konkreten Datenzugriff nachvollziehbar macht.
R2: Write
Das Tool verändert einen Zustand, etwa einen CRM-Datensatz. Im Produktivbetrieb sollte die Freigabe an das konkrete Tool und die wirkungsrelevanten Argumente gebunden sein. Ein geänderter Datensatz oder Empfänger braucht eine neue Entscheidung.
R3: Critical Action
Das Tool veröffentlicht, sendet, löscht, bezahlt, deployed oder führt Code aus. Es bleibt standardmäßig deaktiviert. Eine Aktivierung braucht exakte Argumentbindung, enge Limits, Isolation und eine überprüfbare Ergebnisbehandlung.
Praxisbeispiel selbst auswerten
Warum die Freigabe an Argumente gebunden werden muss
„Darf der Agent send_email verwenden?“ ist eine zu grobe Frage. Die eigentliche Entscheidung lautet: „Darf dieser Nutzer jetzt diese Nachricht an diesen Empfänger senden?“
Wenn Empfänger, Betrag, Zielsystem, Dateipfad oder Inhalt nach der Freigabe verändert werden können, wurde nicht die tatsächlich ausgeführte Aktion bestätigt. In einer Community-Diskussion zu Berechtigungen für viele MCP-Server wird genau diese Lücke sichtbar: Tool-Level-Rechte reichen nicht, wenn Argumente die reale Wirkung bestimmen.
Deshalb sucht die Risk Map in jedem inputSchema nach wirkungsrelevanten Feldern wie recipient, amount, account_id, path, url, content oder command. Diese Felder erscheinen im Control Contract unter bindArguments.
send_email freigeben, sondern den konkreten Aufruf mit seinen wirkungsrelevanten Argumenten.Was der Control Contract enthält
Für jedes Tool entsteht ein prüfbarer Entwurf mit:
- Risikostufe und Begründung
- Aktivierung im Standardzustand
- Art der Freigabe
- Argumenten, die an eine Freigabe gebunden werden müssen
- erforderlicher Identität
- Audit-Feldern
- Rate Limit
- Datenklasse
Der Contract ist absichtlich kein angeblicher MCP-Standard. Er ist ein offenes Review-Artefakt mit einem veröffentlichten JSON Schema. Ein Team kann ihn an ein vorhandenes Gateway, eine Policy Engine oder interne Abnahmekriterien anpassen.
Aktuelle Plattformen bewegen sich bereits in diese Richtung. Bei Anthropic Managed Agents können MCP-Toolsets standardmäßig auf always_ask stehen und pro Tool überschrieben werden. Microsoft beschreibt für Microsoft 365 Agent Tools einen zentralen Katalog mit Admin-Freigaben, blockierbaren Servern, Tool-Snapshots und Laufzeitkontrollen.
Die konkrete Syntax unterscheidet sich. Das Produktproblem bleibt gleich: Sichtbarkeit, Entscheidung und Durchsetzung müssen getrennt und trotzdem miteinander verbunden sein.
Was Forschung über die Vertrauenslücke sagt
Aktuelle Forschung untersucht nicht nur einzelne fehlerhafte Server, sondern Schwächen im Vertrauensmodell. Die Arbeit Breaking the Protocol beschreibt unter anderem fehlende Capability-Attestierung und implizite Vertrauensweitergabe. MCP at First Glance analysiert MCP-spezifische Risiken wie Tool Poisoning empirisch. VIPER-MCP betrachtet gefährliche Datenflüsse und automatisierte Erkennung in größerem Maßstab.
Keines dieser Papiere beweist, dass jeder MCP-Einsatz unsicher ist. Sie zeigen aber, warum ein einmaliger Scan keinen stabilen Vertrauensnachweis liefert. Tool-Beschreibungen können sich ändern, Server können je nach Kontext unterschiedlich reagieren und harmlose Einzelschritte können zusammen einen gefährlichen Datenfluss bilden.
Ein Control Contract löst diese Forschungsprobleme nicht vollständig. Er macht aber die beabsichtigte Wirkung explizit und damit überprüfbar.
Was mein Tool bewusst nicht behauptet
Die Risk Map analysiert Namen, Beschreibungen und Eingabeschemas. Sie führt keine Tools aus und sendet keine Anfrage an einen MCP-Server.
Sie kann deshalb nicht beweisen:
- was ein Server intern wirklich ausführt
- ob eine Tool-Beschreibung zur Laufzeit ausgetauscht wird
- ob OAuth-Scopes tatsächlich korrekt begrenzt sind
- ob Antworten indirekte Prompt Injection enthalten
- ob Logs vollständig und manipulationsarm gespeichert werden
- ob mehrere erlaubte Tools zusammen einen gefährlichen Datenfluss erzeugen
Die Heuristik darf überstimmt werden, aber nur bewusst. Ein falsch benanntes Tool kann sonst zu niedrig oder zu hoch eingestuft werden. Für einen Produktivbetrieb bleiben Code-Review, Laufzeittest, reale Rechteprüfung und ein verantwortlicher Owner notwendig.
Was dieses Projekt über meine Arbeitsweise zeigt
Der wichtigste Teil war nicht das Schreiben des Browser-Codes. Entscheidend war, die erste Idee nach der Recherche zu verwerfen und eine stärker differenzierte Lösung zu bauen.
Das Projekt verbindet vier Ebenen:
- aktuelle Protokollentwicklung
- Security- und Governance-Anforderungen
- Produktentscheidungen für verständliche Freigaben
- eine konkrete, lokal nutzbare Implementierung
Genau an dieser Schnittstelle sehe ich meine Arbeit: KI nicht nur demonstrieren, sondern aus einem funktionierenden Prototyp ein kontrollierbares System machen.
Selbst ausprobieren
Die MCP Tool Risk Map ist kostenlos, ohne Anmeldung und vollständig lokal nutzbar. Das eingebaute Praxisbeispiel enthält öffentliche Suche, CRM-Zugriff, E-Mail, LinkedIn-Publishing und Shell-Ausführung. So wird der Unterschied zwischen einem sichtbaren Tool und einer verantwortbaren Freigabepolitik sofort konkret.
Mich interessiert dabei besonders eine Frage: Welche Entscheidung fehlt dir heute zwischen tools/list und produktiver Freigabe?