MCP · 10 Min.
MCP Security Top 10: 2026-Einordnung fuer 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 muessen.
Kurzfassung
MCP macht Tools fuer Agenten standardisierter verfuegbar. Jede MCP-Verbindung ist auch eine neue Angriffs- und Berechtigungsflaeche. Unternehmen brauchen Scope-Design, Token-Management, Tool-Freigaben und Monitoring.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknuepfe es mit den naechsten 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 ueber 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 uebersetzt die aktuellen OWASP-Risiken in Unternehmensentscheidungen fuer 2026: Protokoll, Tooling, Client, Betrieb und Governance muessen zusammen betrachtet werden.
Warum MCP so stark ist Das Model Context Protocol gibt Agenten eine strukturierte Moeglichkeit, auf Tools, Daten und Systeme zuzugreifen. Statt fuer jedes Modell eigene Integrationen zu bauen, koennen Unternehmen Server bereitstellen, die Funktionen sauber beschreiben.
Das ist ein grosser Schritt fuer 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 muessen:
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 fuer welche Rolle sichtbar? Welche Daten oder Aktionen sind pro Tool erlaubt? OWASP-MCP-Risiken in Unternehmenssprache Die OWASP-MCP-Risiken lassen sich fuer Entscheider so uebersetzen:
Das klingt abstrakt, wird aber konkret, sobald ein Agent Daten suchen, Tickets veraendern oder Nachrichten senden darf.
Model Misbinding: Der falsche Agent oder Client bekommt Zugriff. Context Spoofing: Der Agent vertraut Kontext, der nicht vertrauenswuerdig 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 ungepruefte Server ausserhalb der Governance. Context Injection und Over-Sharing: Kontext wird zu breit geteilt oder als versteckter Instruktionskanal missbraucht. Die praktische Top-10-Liste fuer 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 ungepruefte 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 unnoetig 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 muessen den richtigen Resource-Kontext mitsenden; Server muessen pruefen, ob ein Token wirklich fuer 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 Angriffsoberflaeche.
Token und Secrets MCP-Server duerfen keine Secret-Sammelstelle werden. Tokens muessen kurzlebig, eng begrenzt und nicht in Logs oder Modellkontext landen. Ein Agent darf ein Secret nicht "wissen", nur weil er ein Tool ausfuehrt.
Die Architektur sollte Zugriff delegieren, nicht Geheimnisse verteilen.
Tool Poisoning und Prompt Injection Ein weiteres Risiko: Tools koennen falsch beschrieben, manipuliert oder ueber Kontext angegriffen werden. Wenn ein Agent Tool-Beschreibungen oder Datenquellen unkritisch vertraut, koennen 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 fuer 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 fuer 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 ausfuehren.
Die bessere Architektur trennt Tool-Sichtbarkeit, Tool-Aufruf und Tool-Ausfuehrung.
Remote MCP verschaerft diese Grenze. OpenAI beschreibt Remote MCP Server als oeffentlich erreichbare Server, deren Tools per `mcp_list_tools` importiert werden. Damit wird Tool-Discovery selbst Teil der Angriffsoberflaeche: 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 fuer Generative AI passt gut zu MCP: sichere Entwicklung bedeutet hier nicht nur besseren Prompt schreiben, sondern Komponenten, Abhaengigkeiten, Modellzugriffe, Testdaten, Logs und Release-Prozesse absichern.
Fuer MCP heisst das konkret: Server als Softwareprodukt fuehren, Abhaengigkeiten pruefen, 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 Oberflaeche, nachvollziehbare Logs und getrennte Umgebungen fuer Test und Produktion.
Dann kann MCP Agenten wirklich staerker machen, ohne unkontrollierte Zugriffe zu oeffnen.
