Hintergrund
Die meisten glauben, den Überblick zu haben
Die Cloud Security Alliance hat im Januar 418 IT- und Sicherheitsfachleute gefragt, wie gut sie die KI-Agenten in ihren eigenen Umgebungen kennen. 68 Prozent hatten hohes Vertrauen in den eigenen Überblick. 82 Prozent hatten im vergangenen Jahr Agenten gefunden, von denen niemand wusste, und 41 Prozent mehr als einmal.
Beide Zahlen beschreiben dieselben Organisationen. Das Vertrauen ist nicht gespielt. Es beruht nur auf einem Bild, das entstand, bevor die Agenten Werkzeuge erhielten.
Was sich geändert hat
Die Agenten haben Werkzeuge bekommen, und die Werkzeuge einen Standard
Ein KI-Agent konnte früher nur das, was in ihn hineinprogrammiert war. Heute findet er seine Werkzeuge zur Laufzeit, bei jedem Server, den er erreichen kann. Das Model Context Protocol, kurz MCP, ist zum Standard für diese Verbindung geworden. Anthropic hat es Ende 2024 veröffentlicht und im Dezember 2025 gemeinsam mit OpenAI und Block an die Agentic AI Foundation unter der Linux Foundation übergeben.
Die Verbreitung ging schnell. Wiz fand MCP-Server in mindestens 80 Prozent der Cloud-Umgebungen, die das Unternehmen Anfang 2026 gemessen hat, und in 5 Prozent dieser Umgebungen war mindestens ein Server aus dem Internet erreichbar. In den großen Verzeichnissen sind über 9.400 öffentliche Server erfasst, die Zahl der internen wird auf das Drei- bis Vierfache geschätzt.
Jeder Server ist eine neue Grenze dafür, was der Agent erreichen kann. Und jeder Server wurde von jemandem eingerichtet, ohne dass ein anderer davon wissen muss.
Die vier Fragen
Vier Fragen, die die wenigsten beantworten können
Sie ähneln denen, die eine IGA-Plattform seit Jahren für Mitarbeitende beantwortet. Der Unterschied ist, dass sie für die Werkzeugebene noch niemand gestellt hat.
- Welche MCP-Server haben wir? Eine Entwicklerin fügt einen in ihrem Editor in zwei Minuten hinzu. Es gibt keine Bestellung, keine Genehmigung und keine Stelle, an der er erfasst wird.
- Wem gehört der einzelne Server? Er wurde für ein Projekt eingerichtet. Das Projekt ist beendet, und wer ihn eingerichtet hat, arbeitet inzwischen an etwas anderem.
- Was kann er erreichen? Die Zugangsdaten zu den dahinterliegenden Systemen liegen beim Server, nicht beim Agenten. Die Rechte des Agenten sagen deshalb wenig darüber aus, was tatsächlich möglich ist.
- Wessen Token verwendet er? Wird ein Token von einem System an das nächste weitergereicht, kann ein für einen Zweck ausgestellter Zugriff in Systemen landen, für die er nie gedacht war.
Warum es durchrutscht
Das Protokoll zeigt wer, nicht worüber
Ihre Identitätsplattform weiß, wer eine Anfrage gestellt hat. Sie weiß nicht, über welchen MCP-Server die Anfrage lief, welche Werkzeuge dieser Server bereitgestellt hat und ob die Beschreibung des Werkzeugs, die das Modell gelesen hat, mit der übereinstimmte, die Sie bei der Inbetriebnahme genehmigt haben.
MCP stellt selbst keine Sicherheitsanforderungen. Die Spezifikation beschreibt, wie ein Modell Werkzeuge findet und aufruft, und überlässt Authentifizierung, Autorisierung und Transportsicherheit demjenigen, der den einzelnen Client und Server baut. Ein MCP-Server ist deshalb nur so sicher wie das Team, das ihn eingerichtet hat.
Die Angriffsfläche
Fünf Wege hinein, die OWASP benannt hat
OWASP hat 2025 eine MCP Top 10 veröffentlicht. Der gemeinsame Nenner der meisten Punkte ist Prompt Injection: Anweisungen, die in den Kontext des Modells gelangen und gelesen werden, als kämen sie von Ihnen.
- Der verwirrte Stellvertreter: ein Server mit weitreichenden Rechten wird dazu gebracht, im Auftrag anderer zu handeln. Der Angreifer muss sich nirgends anmelden, sondern nur beeinflussen, was das Modell liest.
- Weitergereichte Token: ein für ein System ausgestelltes Token wird an das nächste weitergereicht, statt gegen ein neues und engeres getauscht zu werden. Wird eine Zwischenstelle kompromittiert, lässt sich das Token anderswo einsetzen.
- Vergiftete Werkzeugbeschreibungen: versteckte Anweisungen in den Metadaten des Werkzeugs selbst. Sie greifen, bevor die Nutzerin überhaupt etwas getan hat, weil die Beschreibung beim Verbindungsaufbau eingelesen wird.
- SSRF über Werkzeuge: eine Adresse, die das Werkzeug selbst liefert, zeigt nach innen, auf interne Endpunkte oder den Metadatendienst der Cloud, den der Agent nie erreichen dürfte.
- Nicht genehmigte Server: ohne Attestierung des Servers und mit schwacher Bindung der Sitzung kann der Agent mit einem Server sprechen, den niemand freigegeben hat.
Zwei Vorfälle
Es ist passiert, und keine Nutzerin hat etwas falsch gemacht
Im September 2025 lieferte ein weit verbreitetes MCP-Paket für E-Mail ein Update aus, das jede vom Agenten versandte Nachricht still in Blindkopie an eine Domäne des Angreifers schickte. Das Paket bestand die Prüfung bei der Installation, weil es sich korrekt verhielt, bis eine spätere Version sein Verhalten änderte.
Ein halbes Jahr zuvor zeigte Invariant Labs ein vergiftetes Rechenwerkzeug, das SSH-Schlüssel auslas und sie codiert in einem Parameter nach außen schickte. Es gab keine Nutzerhandlung, und es gab hinterher keine Spur zu finden.
Beides geschah nicht bei einer Anmeldung. Es geschah, als die Beschreibung des Werkzeugs in den Kontext des Modells eingelesen wurde. Eine Untersuchung von über 500 MCP-Servern ergab, dass 38 Prozent überhaupt keine Authentifizierung hatten.
Was wirkt
Fünf Schritte, die kein Programm erfordern
Die Reihenfolge ist dieselbe wie bei jeder anderen Governance-Arbeit: finden, mit einem Eigentümer versehen und danach begrenzen.
- Finden Sie sie: suchen Sie nach MCP-Servern im Netz, auf den Maschinen und in den Paketen, die Sie hereinholen. Eine Liste, die Sie nicht haben, lässt sich nicht genehmigen.
- Geben Sie jedem Server einen Eigentümer und einen Zweck: dieselbe Disziplin wie bei Servicekonten. Kein Eigentümer, kein Server.
- Tauschen Sie Token, statt sie weiterzureichen: ein Tausch stellt einen neuen Zugriff aus, der nur für das Zielsystem gilt. Damit entfällt die Voraussetzung dafür, dass ein Token an mehreren Stellen greift.
- Sichern Sie die Werkzeugbeschreibungen: hinterlegen Sie bei der Inbetriebnahme einen Abdruck der Beschreibung und prüfen Sie ihn bei jedem Abruf der Liste. Eine Beschreibung, die sich seit der Genehmigung geändert hat, ist ungeprüfter Code mit dem Vertrauen des Modells im Rücken.
- Behandeln Sie einen neuen Server als Änderung: genehmigte Liste, Signierung, feste Version und ein Sicherheitsblick, wie bei jeder anderen Integration.
Die Steuerung
Dieselbe Disziplin, ein neues Objekt
Alles oben Genannte ist die Disziplin, die eine IGA-Plattform seit Jahren beherrscht. Ein Objekt erhält einen Eigentümer und einen Zweck, Rechte werden nach einer Regel vergeben, in festen Abständen überprüft und entzogen, wenn die Grundlage entfällt. Das Objekt ist neu. Die Disziplin ist dieselbe.
Der Druck kommt auch von außen. KI-Verordnung, NIS2 und ISO 42001 fragen dasselbe: wer ist verantwortlich, und was kann das System erreichen. Die NSA hat im Juni 2026 eine Handreichung zur Sicherheit von MCP veröffentlicht. Das geschieht selten bei Themen, die wieder verschwinden.
Zum Schluss eine ehrliche Anmerkung. Kein Scan liefert Ihnen vom ersten Tag an eine vollständige Liste. Ein großer Teil der MCP-Server läuft lokal auf den Rechnern der Entwicklerinnen und Entwickler und berührt das Netz nie. Beginnen Sie mit dem, was von außen erreichbar ist, und mit der genehmigten Liste. Die lokalen brauchen eine Richtlinie und ein Gespräch, kein Werkzeug.
Wissen Sie, wie viele MCP-Server Sie haben?
Ein Healthcheck erfasst Agenten, Server und die Zugriffe, die sie tatsächlich erreichen, und zeigt, wo zuerst anzusetzen ist.
