Stand: 28. September 2026
Das Model Context Protocol, kurz MCP, hat sich innerhalb kurzer Zeit von einer Entwickleridee zu einer wichtigen Integrationsschicht für Agentic AI entwickelt. Über MCP können KI-Assistenten standardisiert auf Dateien, Datenbanken, Unternehmensanwendungen, APIs und andere Tools zugreifen. Genau darin liegt der geschäftliche Wert – und gleichzeitig die neue Sicherheitsherausforderung. Denn ein Sprachmodell, das nicht nur antwortet, sondern mit echten Berechtigungen Aktionen in realen Systemen ausführt, verändert das Risikomodell grundlegend.
Die im Juli 2026 veröffentlichte MCP-Spezifikation 2026-07-28 enthält deshalb umfangreiche Härtungen rund um Autorisierung, Token-Bindung, Issuer-Prüfung und Client-Metadaten. Auch OWASP behandelt MCP inzwischen als eigenständige Angriffsfläche. Unternehmen sollten MCP daher nicht wie ein normales Plugin-System behandeln, sondern wie eine neue Ebene zwischen Identität, KI und produktiven Unternehmenssystemen.
Warum MCP-Sicherheit 2026 so wichtig geworden ist
Bei einer klassischen API entscheidet eine Anwendung meist deterministisch, welchen Endpunkt sie mit welchen Parametern aufruft. Bei einem KI-Agenten kann ein Modell dagegen aus natürlicher Sprache ableiten, welches Tool es benutzen möchte. Dadurch wird die Entscheidungskette dynamischer. Ein kompromittierter Kontext, ein manipuliertes Dokument oder ein bösartiger MCP-Server kann das Modell dazu bringen, andere Aktionen auszuführen als ursprünglich beabsichtigt.
Der Sicherheitsunterschied ist entscheidend: Ein Chatbot ohne Tools kann falsche Informationen ausgeben. Ein Agent mit Tool-Zugriff kann unter Umständen Dateien verändern, Tickets schließen, Daten exportieren, Repository-Inhalte modifizieren oder externe APIs aufrufen. Deshalb hängt das Risiko eines MCP-Systems weniger von der Intelligenz des Modells ab als von den Rechten, die ihm technisch zur Verfügung stehen.
Die wichtigsten MCP-Angriffsflächen
1. Zu breite OAuth-Scopes
Ein häufiges Architekturproblem entsteht, wenn ein MCP-Server mehr Rechte erhält, als der eigentliche Use Case benötigt. Ein Assistent, der Termine lesen soll, braucht nicht automatisch Schreibrechte. Ein Analyse-Agent, der Daten aus einer Anwendung abfragt, sollte nicht ohne Grund administrative Funktionen erhalten. Die Regel ist einfach: Jeder MCP-Server und jedes Tool benötigt die kleinstmögliche Berechtigung, und diese Rechte müssen getrennt von der Identität des Endbenutzers nachvollziehbar bleiben.
2. Token Passthrough und falsche Zielgruppe
Die MCP-Spezifikation 2026-07-28 betont die Bindung von Access Tokens an die vorgesehene Ressource. Ein MCP-Server darf nicht einfach Tokens akzeptieren, die für einen anderen Dienst ausgestellt wurden. Ebenso sollte ein Server ein erhaltenes Token nicht ungeprüft an nachgelagerte APIs weiterreichen. Für Upstream-Dienste sind separate Tokens und klar definierte Vertrauensbeziehungen erforderlich. Sonst kann aus einem scheinbar kleinen Integrationsfehler ein seitlicher Zugriff auf weitere Systeme entstehen.
3. Authorization Server Mix-up
Aktuelle MCP-Sicherheitsregeln verlangen eine strengere Prüfung des ausstellenden Authorization Servers. Der Client muss sicherstellen, dass Autorisierungscode und Token tatsächlich vom erwarteten Issuer stammen. Solche Prüfungen wirken technisch klein, verhindern aber Angriffe, bei denen Authentifizierungsflüsse auf einen falschen oder manipulierten Autorisierungsdienst umgeleitet werden.
4. Prompt Injection über externe Inhalte
Ein MCP-Agent kann Informationen aus Dokumenten, Webseiten, Tickets oder Repositories verarbeiten. Darin können versteckte oder absichtlich formulierte Anweisungen enthalten sein. Das Modell kann diese Inhalte fälschlicherweise wie legitime Arbeitsanweisungen behandeln. Besonders gefährlich wird das, wenn ein Tool anschließend Schreibzugriff oder externe Netzwerkverbindungen besitzt. Prompt Injection muss deshalb als Daten- und Berechtigungsproblem behandelt werden, nicht nur als Prompt-Engineering-Thema.
5. Tool Poisoning und manipulierte Tool-Beschreibungen
Agenten wählen Tools anhand von Namen, Beschreibungen, Parametern und Kontext. Ein bösartiger oder kompromittierter MCP-Server kann versuchen, das Modell durch irreführende Tool-Metadaten zu beeinflussen. Unternehmen benötigen deshalb eine vertrauenswürdige Registry zugelassener MCP-Server und sollten Änderungen an Tool-Definitionen versionieren und überwachen.
6. Confused Deputy
Ein Agent kann zum „verwirrten Stellvertreter“ werden: Er besitzt legitime Rechte, wird aber durch manipulierten Input dazu gebracht, diese Rechte für einen unberechtigten Zweck zu verwenden. Das ist ein klassisches Sicherheitsproblem, erhält durch natürliche Sprache und dynamische Tool-Auswahl jedoch eine neue Dimension. Schutz entsteht vor allem durch kontextabhängige Autorisierung, geringe Rechte und zusätzliche Freigaben für kritische Aktionen.
Was die MCP-Spezifikation 2026-07-28 verbessert
Die aktuelle Spezifikation bringt mehrere Härtungen für produktive Umgebungen. Dazu gehören unter anderem strengere Issuer-Validierung, eine stärkere Trennung von Client-Credentials nach Authorization Server und Vorgaben zur sicheren Nutzung von OAuth. MCP-Clients sollen außerdem PKCE verwenden und Ressourcen explizit angeben, damit Tokens nicht für falsche Ziele eingesetzt werden können. Gleichzeitig entwickelt sich die Architektur in Richtung besser skalierbarer, stateless HTTP-basierter Kommunikation.
Für Unternehmen bedeutet das: Alte MCP-Implementierungen sollten nicht einfach unverändert weiterbetrieben werden. Sicherheitsanforderungen des aktuellen Protokolls müssen aktiv in Clients, Gateways und Servern umgesetzt werden. Eine Versionsnummer im SDK allein beweist noch nicht, dass die gesamte OAuth- und Token-Konfiguration korrekt ist.
Enterprise Managed Authorization: zentrale Kontrolle statt OAuth-Wildwuchs
Im Juni 2026 wurde Enterprise-Managed Authorization als stabile MCP-Erweiterung vorgestellt. Die Idee ist für Unternehmen interessant: Zugriffe auf MCP-Server können zentral über den Identity Provider verwaltet werden, statt dass Benutzer für jede einzelne Integration eigene OAuth-Freigaben erteilen. Dadurch wird der Lebenszyklus kontrollierbarer – von Onboarding über Rollenwechsel bis Offboarding.
Das ersetzt jedoch nicht die Prüfung einzelner Tools. Auch ein zentral autorisierter MCP-Server kann riskante Funktionen anbieten. Unternehmen sollten deshalb zwei Ebenen unterscheiden: Wer darf sich mit einem Server verbinden? Und welche konkrete Aktion darf der Agent innerhalb dieses Servers ausführen?
Eine sichere MCP-Zielarchitektur
Zentraler MCP-Katalog
Jeder produktive MCP-Server sollte registriert sein. Der Katalog enthält Owner, technische Kontaktperson, Version, Datenkategorien, OAuth-Scopes, verwendete Upstream-Dienste, Netzwerkziele und erlaubte Tools. Nicht registrierte Server sollten in verwalteten Unternehmensumgebungen nicht produktiv genutzt werden.
Identity- und Policy-Gateway
Zwischen Agent und Backend sollte eine Kontrollschicht stehen, die Tokens validiert, Zielressourcen prüft, Scopes auswertet und Policies durchsetzt. Kritische Operationen wie Löschen, Überweisen, Berechtigungsänderungen oder Deployment können zusätzliche Genehmigungen verlangen.
Netzwerk-Egress begrenzen
Ein MCP-Prozess sollte nicht beliebig ins Internet kommunizieren können. Allowlisting, Proxy-Kontrollen und DNS- beziehungsweise Firewall-Regeln reduzieren das Risiko der Datenexfiltration. Dabei muss berücksichtigt werden, dass nicht jede Agentenplattform denselben Netzwerkpfad oder dieselben Sandbox-Regeln verwendet.
Tool-Level Logging
Audit Logs sollten nicht nur zeigen, dass ein Agent aktiv war, sondern welches Tool mit welchen sicherheitsrelevanten Parametern aufgerufen wurde, welches Resultat zurückkam und welche Identität die Aktion ausgelöst hat. Sensible Inhalte müssen dabei maskiert oder minimiert werden.
Human-in-the-Loop für irreversible Aktionen
Nicht jede Aktion benötigt eine manuelle Bestätigung. Aber alles, was finanziellen, rechtlichen, produktiven oder sicherheitskritischen Schaden verursachen kann, sollte höhere Kontrollstufen haben. Gute Systeme unterscheiden lesen, vorschlagen, vorbereiten und tatsächlich ausführen.
MCP Security Checkliste für Unternehmen
Inventar: Sind alle MCP-Server, Tools und Owner bekannt?
Authentifizierung: Wird ein zentral verwalteter Identity Provider verwendet?
Token Security: Werden Audience, Issuer und Scope konsequent validiert?
PKCE: Sind moderne OAuth-Schutzmechanismen tatsächlich aktiviert?
Least Privilege: Hat jedes Tool nur die minimal notwendigen Rechte?
Secrets: Liegen keine dauerhaften Tokens oder API-Keys in Konfigurationsdateien oder Prompts?
Tool Trust: Sind Tool-Definitionen versioniert und Änderungen nachvollziehbar?
Egress: Sind externe Netzwerkziele begrenzt?
Logging: Lassen sich kritische Tool-Aufrufe einem Benutzer oder Agenten zuordnen?
Approval: Gibt es Freigaben für irreversible oder privilegierte Aktionen?
Incident Response: Kann ein MCP-Server oder einzelnes Tool kurzfristig zentral gesperrt werden?
Warum ein klassischer API-Pentest allein nicht genügt
Ein normaler Web- oder API-Pentest bleibt wichtig, erfasst aber nicht automatisch die agentische Ebene. Zusätzlich sollten Security-Tests prüfen, ob manipulierte Tool-Beschreibungen, indirekte Prompt Injections, bösartige Dokumente oder unerwartete Tool-Chains zu gefährlichen Aktionen führen. Red Teaming muss also die Kombination aus Modellverhalten, Berechtigungen, Kontext und Backend-Funktionen untersuchen.
OWASP stellt 2026 sowohl einen praktischen Leitfaden zur sicheren MCP-Server-Entwicklung als auch eine eigene MCP-Sicherheitsübersicht bereit. Diese Ressourcen zeigen, dass sich MCP Security zu einem eigenständigen Teilbereich der Application- und AI-Security entwickelt.
Was kleine und mittlere Unternehmen jetzt tun sollten
KMU müssen nicht sofort ein großes MCP-Gateway kaufen. Entscheidend sind fünf erste Schritte: nur genehmigte MCP-Server einsetzen, OAuth-Rechte minimieren, technische Konten trennen, externe Netzwerkzugriffe beschränken und alle schreibenden Tools protokollieren. Sobald mehrere Agenten und Plattformen produktiv eingesetzt werden, sollte daraus ein zentraler Governance-Prozess werden.
Fazit
MCP macht Agentic AI praktisch – und bringt die KI damit näher an produktive Systeme als frühere Chatbot-Architekturen. Die größte Gefahr entsteht nicht durch ein einzelnes Protokollproblem, sondern durch die Kombination aus dynamischer Tool-Auswahl, starken Berechtigungen und untrusted Content. Unternehmen sollten MCP deshalb wie eine sicherheitskritische Integrationsschicht behandeln: mit klarer Identität, strikter Autorisierung, begrenztem Netzwerkzugriff, vollständiger Nachvollziehbarkeit und kontrollierten Freigaben.
Weiterführende Quellen
Model Context Protocol: Spezifikation 2026-07-28
MCP: Authorization Security Considerations
OWASP: A Practical Guide for Secure MCP Server Development
OWASP MCP Security Cheat Sheet
MCP: Enterprise-Managed Authorization
Titelbild: Taylor Vick / Unsplash
Autor: Salman Dolatpanah Gortlar