MCP · 10 Min.
MCP Security Top 10: 2026-Einordnung für Unternehmen
MCP kann Agenten mit echten Systemen verbinden. Genau deshalb muss jede Verbindung wie eine Sicherheitsgrenze behandelt werden.
SYSTEMS Grafik zu MCP Security Top 10: Context -> Tools -> Control. Fokus: Welche Sicherheitsrisiken Unternehmen bei MCP-Servern und Agenten-Tools einplanen müssen.
Kurzfassung
MCP macht Tools für Agenten standardisierter verfügbar. Jede MCP-Verbindung ist auch eine neue Angriffs- und Berechtigungsfläche. Unternehmen brauchen Scope-Design, Token-Management, Tool-Freigaben und Monitoring.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Update Mai 2026: MCP-Security ist mehr als Prompt Injection Viele Teams denken bei Agenten-Security zuerst an Prompt Injection . Bei MCP ist das zu eng. Die offiziellen Sicherheitsleitlinien sprechen auch über Token-Passthrough, Confused Deputy, SSRF, Session-Hijacking, lokale Server-Kompromittierung und Scope-Minimierung. Das sind Betriebs- und Architekturthemen, nicht nur Prompt-Themen.
Ein produktiver MCP-Server muss deshalb wie eine Integrations- und Berechtigungsschicht behandelt werden. Wer ihn nur als schnellen Tool-Adapter baut, verlegt den kritischsten Teil der Security in eine Demo-Komponente.
OWASP hat inzwischen ein eigenes MCP Top 10 Projekt. Wichtig: Der aktuelle Stand ist eine v0.1-Liste und keine finale 2026-Norm. Diese SYSTEMS-Einordnung übersetzt die aktuellen OWASP-Risiken in Unternehmensentscheidungen für 2026: Protokoll, Tooling, Client, Betrieb und Governance müssen zusammen betrachtet werden.
Warum MCP so stark ist Das Model Context Protocol gibt Agenten eine strukturierte Möglichkeit, auf Tools, Daten und Systeme zuzugreifen. Statt für jedes Modell eigene Integrationen zu bauen, können Unternehmen Server bereitstellen, die Funktionen sauber beschreiben.
Das ist ein grosser Schritt für produktive Agenten. Aber jede Standardisierung, die Zugriff erleichtert, macht auch Missbrauch skalierbarer.
Die drei kritischen Grenzen Bei MCP gibt es drei Grenzen, die sauber sein müssen:
Wenn diese Grenzen weich sind, entsteht Scope Creep. Ein Server startet mit harmlosen Lesezugriffen und endet mit zu breiten Rechten.
Wer darf den Server nutzen? Welche Tools sind für welche Rolle sichtbar? Welche Daten oder Aktionen sind pro Tool erlaubt? OWASP-MCP-Risiken in Unternehmenssprache Die OWASP-MCP-Risiken lassen sich für Entscheider so übersetzen:
Das klingt abstrakt, wird aber konkret, sobald ein Agent Daten suchen, Tickets verändern oder Nachrichten senden darf.
Model Misbinding: Der falsche Agent oder Client bekommt Zugriff. Context Spoofing: Der Agent vertraut Kontext, der nicht vertrauenswürdig ist. Prompt-State Manipulation: Angreifer beeinflussen den Zustand, aus dem Tools gesteuert werden. Insecure Memory References: Memory verweist auf Daten, die der Nutzer nicht sehen sollte. Covert Channel Abuse: Tools werden als versteckter Datenkanal missbraucht. Lack of Audit and Telemetry: Niemand sieht, was wirklich passiert ist. Shadow MCP Servers: Teams betreiben ungeprüfte Server ausserhalb der Governance. Context Injection und Over-Sharing: Kontext wird zu breit geteilt oder als versteckter Instruktionskanal missbraucht. Die praktische Top-10-Liste für Unternehmen Token-Passthrough statt sauberer Token-Audience. Zu breite Scopes wie `all`, `admin` oder `files:*`. Fehlender per-client Consent bei Proxy-Servern. Redirect-URIs mit Wildcards oder unscharfer Validierung. SSRF durch ungeprüfte OAuth- oder Fetch-URLs. Session-IDs, die als Authentifizierung missbraucht werden. Lokale MCP-Server ohne Sandbox und klare Zustimmung. Tool-Beschreibungen ohne Review und Versionierung. Kombinierte Lese-, Schreib- und Versandtools ohne Freigabe. Logs, die Tokens, Prompts oder Kundendaten unnötig speichern. Transport- und Auth-Grenzen Bei Streamable HTTP verlangt MCP Sicherheitsmassnahmen wie Origin-Validierung, lokale Bindung an `localhost` statt alle Interfaces und echte Authentifizierung. Bei Authorization geht es um OAuth 2.1, Resource Indicators, Audience Validation und klare Token-Grenzen. Clients müssen den richtigen Resource-Kontext mitsenden; Server müssen prüfen, ob ein Token wirklich für diesen MCP-Server und diesen Zweck ausgestellt wurde.
Das wichtigste Anti-Pattern bleibt Token-Passthrough: Ein MCP-Server darf nicht einfach den vom Client erhaltenen Token an Downstream-APIs weiterreichen. Downstream-Zugriffe brauchen eigene Tokens und eigene Scopes.
Bei Proxy- und OAuth-Flows ist auch `state` keine Formalie. Der Server muss pro Authorization Request einen sicheren State erzeugen, serverseitig binden und exakt validieren. Sonst werden Consent und Session zu einer Angriffsoberfläche.
Token und Secrets MCP-Server dürfen keine Secret-Sammelstelle werden. Tokens müssen kurzlebig, eng begrenzt und nicht in Logs oder Modellkontext landen. Ein Agent darf ein Secret nicht "wissen", nur weil er ein Tool ausführt.
Die Architektur sollte Zugriff delegieren, nicht Geheimnisse verteilen.
Tool Poisoning und Prompt Injection Ein weiteres Risiko: Tools können falsch beschrieben, manipuliert oder über Kontext angegriffen werden. Wenn ein Agent Tool-Beschreibungen oder Datenquellen unkritisch vertraut, können Angriffe die Tool-Wahl beeinflussen.
Deshalb braucht MCP nicht nur Auth, sondern auch Tool-Review, Versionierung und Missbrauchstests.
Audit und Telemetry als Pflicht OWASP nennt fehlendes Audit und fehlende Telemetry als eigenes MCP-Risiko. Das ist berechtigt: MCP-Systeme kombinieren Agent, Client, Server, Tool, Netzwerk und externe Datenquellen. Wenn nur eine Schicht loggt, fehlt der eigentliche Ablauf.
Ein Minimum-Log für produktive MCP-Nutzung:
Ohne diese Daten kann ein Unternehmen weder Angriffe rekonstruieren noch falsche Agentenentscheidungen verbessern.
Agent Run-ID MCP-Client und Server Tool-Name und Tool-Version Scope und Rolle Input-Klasse, nicht zwingend kompletter Payload Approval-Status Downstream-System Ergebnisstatus und Fehlerklasse Approval ist kein UX-Detail OpenAI dokumentiert für MCP-Tools Approval-Controls wie `require_approval` und `allowed_tools`. Das ist kein Komfortfeature, sondern eine Sicherheitsgrenze. Ein Agent darf riskante Tools sehen, aber nicht automatisch jede Aktion ausführen.
Die bessere Architektur trennt Tool-Sichtbarkeit, Tool-Aufruf und Tool-Ausführung.
Remote MCP verschärft diese Grenze. OpenAI beschreibt Remote MCP Server als öffentlich erreichbare Server, deren Tools per `mcp_list_tools` importiert werden. Damit wird Tool-Discovery selbst Teil der Angriffsoberfläche: Welche Tools ein Agent sieht, wann er sie sieht und welche Beschreibungen er vertraut, muss kontrolliert werden.
Secure Build statt nur Secure Prompt NISTs SSDF-Profil für Generative AI passt gut zu MCP: sichere Entwicklung bedeutet hier nicht nur besseren Prompt schreiben, sondern Komponenten, Abhängigkeiten, Modellzugriffe, Testdaten, Logs und Release-Prozesse absichern.
Für MCP heisst das konkret: Server als Softwareprodukt führen, Abhängigkeiten prüfen, Tool-Schemas versionieren, Missbrauchstests automatisieren und Produktion von Experimenten trennen.
Der SYSTEMS-Blick Wir sehen MCP als Infrastruktur-Schicht, nicht als Plugin-Spielzeug. Ein guter MCP-Server hat ein klares Rechtedesign, wenig Oberfläche, nachvollziehbare Logs und getrennte Umgebungen für Test und Produktion.
Dann kann MCP Agenten wirklich stärker machen, ohne unkontrollierte Zugriffe zu öffnen.
