Jedes MCP-Credential, das Ihr Team ausgegeben hat, war an dem Tag, an dem Sie es vergeben haben, wahrscheinlich eine gute Entscheidung. Seitdem hat niemand mehr nachgeprüft. Das ist die Lücke, die Angreifer nutzen, nicht ein Fehler im Protokoll selbst.
Das Model Context Protocol (MCP) von Anthropic ging Ende 2024 in Produktion. Es verbreitete sich danach rasant. Seitdem sind Tausende von MCP-Servern entstanden. Microsoft, Google und OpenAI haben es übernommen. Die Pflege des Protokolls wurde an die Linux Foundation übergeben. Heute gilt MCP als kritische Infrastruktur. Es vermittelt zwischen einem KI-Agenten und den Tools und Daten, mit denen dieser Agent interagiert. Für die meisten Teams wurde es implementiert wie jeder andere Integrationsstandard: Man installierte es und vertraute den Standardeinstellungen.
Was sich 2026 als wahr herausstellte, ist, dass das Problem nicht in der Infrastruktur lag. Das Problem liegt in den Berechtigungen unterhalb dieser Infrastruktur.
Das ist entscheidend, weil es beeinflusst, wie Menschen über die Lösung von MCP-Sicherheitsproblemen denken. Ein Patch löst ein spezifisches Problem auf einem bestimmten Server. Die Berechtigungsänderung erfordert eine kompliziertere Frage: Warum brauchte dieser bestimmte Server überhaupt Zugriff auf etwas, das er nie benötigte? Laut der SANS-2026-Umfrage zu Identitätsbedrohungen, bei der mehr als 500 Sicherheitsexpertinnen und -experten befragt wurden, verzeichneten 76 Prozent der Unternehmen einen Anstieg nicht-menschlicher Identitäten. 74 Prozent der Unternehmen nutzen KI-Systeme, die auf dauerhaften Credentials beruhen, um eigenständig zu arbeiten. Dieselbe Umfrage ergab, dass keine der Schutzmaßnahmen, wie Freigabeprozesse, Sandboxing oder Logging, von mehr als 40 Prozent der Unternehmen genutzt wird.
Blickt man über die einzelnen Vorfälle hinaus, zeigt sich immer wieder dieselbe Grundursache. Im Mai 2025 nutzte ein Angreifer Prompt-Injection gegen den GitHub-MCP-Server, um private Repository-Daten abzuziehen, nicht weil der Server einen klassischen Bug hatte, sondern weil das dahinterliegende Personal-Access-Token weit über die Aufgabe hinaus berechtigt war. Wenige Tage später ermöglichte ein Logikfehler in einer Asana-MCP-Integration mandantenübergreifenden Zugriff, weil die Isolationsgrenze zwischen Kunden nie auf Berechtigungsebene durchgesetzt wurde.
Sicherheitsforschende fassen dies inzwischen unter ein paar erkennbaren Mustern zusammen: Tool Poisoning, bei dem die eigene Tool-Beschreibung eines Servers versteckte Anweisungen trägt, und das Confused-Deputy-Problem, bei dem ein Agent mehr Vertrauen erbt, als die vorliegende Aufgabe erfordert.
Was eine Berechtigungsüberarbeitung tatsächlich von Ihnen verlangt zu prüfen
Die Lösung, die sich immer wieder zeigt, ist nicht ein besserer Scanner, sondern die Kompartimentierung von Zugriff. Der Engineering-Blog von GitHub, der die Entwicklung sicherer Remote-MCP-Server behandelt, schlägt Folgendes vor: Jede Instanz muss ihre Secrets entsprechend der jeweiligen Aufgabe erhalten, alle Anfragen müssen auf die handelnde Nutzerin oder den handelnden Nutzer beschränkt sein, und die Autorisierung muss Aktion für Aktion erfolgen, statt sie nach der Nutzerauthentifizierung anzunehmen. Feste, dauerhafte Tokens sollten durch dynamische, temporäre Credentials ersetzt werden, die bei Bedarf generiert werden.
Diese Lösung ist gestuft und funktioniert bislang. Bei Webflow behandeln wir MCP-Integrationen genauso wie andere Drittanbieter-Komponenten mit Zugriff auf Kundendaten.
Der Umfang ändert sich nicht. Ob ihn jemand überprüft, das schon.
Derselbe Tag-Null-Grant, zwei Gewohnheiten – nur eine davon wird je überprüft.
Beide Spuren starten mit demselben Grant, beschränkt auf die Aufgabe, die ihn angefordert hat. Die geplante Überprüfung stellt dieselben Fragen, die dieser Beitrag bereits aufwirft: Was kann das Credential jetzt erreichen, verglichen mit dem, wofür es beschränkt wurde; wird die Autorisierung pro Site oder pro Workspace vergeben statt alles-oder-nichts; erhält der Agent ein eigenes Credential statt eines vererbten breiteren; gibt es Logging, das Verantwortlichkeit zuordnet; durchläuft eine Änderung weiterhin ein Review vor der Produktion. Ein Credential, dem niemand diese Fragen stellt, wird mit der Zeit nicht sicherer – es behält einfach, welchen Zugriff es zu Beginn hatte, was die Form hinter sowohl dem GitHub-MCP-Token, das breiter wurde als die Aufgabe erforderte, als auch der Asana-Integration ist, die ihre Mandantengrenze nie durchgesetzt hat.
Jedes Credential, das das Team einem KI-Agenten gibt, war wahrscheinlich eine gute Idee, als es vergeben wurde. Die schwierige Frage ist nicht, ob der Zugriff zu diesem Zeitpunkt eine gute Idee war. Sie ist, ob er es noch ist, und die meisten Teams haben es nicht zur Gewohnheit gemacht, das zu prüfen.
Einiges, das bei der Integration jedes MCP zu bedenken ist:
Was kann dieses Credential jetzt erreichen, verglichen mit dem Umfang, für den es gedacht war. Der Zugriffsumfang wird sich wahrscheinlich still und leise ausweiten. Es wird keine geplante Überprüfung geben, bis etwas kaputt geht.
Wird die Autorisierung pro Site, pro Repository oder pro Workspace vergeben, oder alles-oder-nichts? Seien Sie misstrauisch gegenüber jeder Integration, die nur organisationsweiten Zugriff bietet. Wenn eine Integration Ihnen zum Verbindungszeitpunkt keine Kontrolle über den Umfang gibt, ist das der eigentliche Befund, keine Fußnote.
Erbt der KI-Agent die bestehenden Credentials der Person, oder erstellt er ein völlig neues Credential, das diese Berechtigungen umgeht? Letzteres ist der Grund, warum ein GitHub-Personal-Access-Token mehr Zugriff auf Repos haben kann als die Person, die es autorisiert hat.
Gibt es Logging, das dem Agenten Verantwortlichkeit zuordnet, so wie es das bei einem Menschen tun würde? Wenn die Aktivitäten des Agenten unsichtbar oder nicht zuordenbar sind, beginnt die Incident Response bei null.
Gehen Änderungen des Agenten direkt in die Produktion, oder durchlaufen sie zuerst einen überprüfbaren Prozess wie Draft, Branch, Freigabe-Warteschlange?Das wendet lediglich die Sicherheitsdisziplin, die das Team bereits bei menschlichen Zugriffskontrollen hat, auf eine neuere Klasse von Entitäten an.
Identität kommt vor Zugriff
Bevor man darüber sprechen kann, was ein Agent tun darf, muss man eine schwierigere Frage beantworten: Was ist ein Agent, identitätstechnisch betrachtet? Die ehrliche Antwort für die meisten der Branche ist derzeit: „Das OAuth-Token eines Menschen im Trenchcoat.“ Der Agent hat keine eigene Identität. Er erbt den Umfang, den Explosionsradius und oft das buchstäbliche Credential der Person, die ihn gestartet hat.
Das wird zum Problem, sobald Agenten aufhören, kurzlebig zu sein. Die meisten Agenten leben heute Minuten bis Stunden: Eine Aufgabe beginnt, der Agent läuft, er stirbt. Aber das ändert sich. Wir bewegen uns auf Agenten zu, die Wochen oder Monate laufen, und etwas, das so lange lebt, braucht eine eigene Identität, keine geliehene, mit Berechtigungen, die mit wachsender Lebensdauer strenger werden, nicht lockerer.
Stellen Sie sich den Unterschied vor zwischen einem Auftragnehmer, den Sie für einen Nachmittag hinzuziehen, und einer Leiharbeitskraft, die ein Quartal lang in Ihre Systeme eingebettet ist. Sie würden dem Nachmittags-Auftragnehmer keinen dauerhaften Ausweis geben, und Sie sollten dem Quartals-Agenten nicht denselben Zugriff geben wie einem Fünf-Minuten-Skript.
OAuth wurde nicht dafür gebaut, und das ist nicht nur ein fehlendes Feature, es ist ein struktureller Bruch, im Kern ein UX-Versagen: ein Consent-Modell, das für einen Menschen im Loop gebaut wurde, angewendet auf einen Prozess, der keinen hat. Das gesamte Modell geht davon aus, dass ein Mensch vor einem Scope-Dialog sitzt und eine informierte Entscheidung trifft, und wir alle wissen, wie das läuft: Niemand liest die Scope-Liste, alle klicken auf Erlauben. Diese schon fragile Annahme bricht vollständig zusammen, wenn niemand mehr etwas liest.
Die Basisspezifikation kennt kein Konzept von „dieser Client ist ein Agent“ oder „dieser Grant soll sechs Monate laufen“, nur eine vom Server nachträglich gesetzte Ablaufzeit. Ein paar IETF-Entwürfe beginnen, eine Lösung zu skizzieren, die die Token-Lebensdauer an den tatsächlichen Lebenszyklus einer Aufgabe bindet und Agenten mit stabilen Identitäten kennzeichnet, die sich von der Person unterscheiden, die sie aufgerufen hat, aber das sind alles frühe Vorschläge, keine implementierten Standards.
Wir haben keine saubere Antwort darauf, wo die Grenze zwischen „kurzlebige Aufgabe, eher breiter Zugriff“ und „langlebiger Agent, streng abgeschlossen“ liegt. Webflows Sicherheitsteam arbeitet aktiv daran, und wir tauschen uns mit Kolleginnen und Kollegen in der Branche aus, statt vorzugeben, wir hätten es gelöst. Aber die Rahmung selbst ist entscheidend: Behandeln Sie die Lebensdauer eines Agenten als erstrangigen Faktor in Ihrem Berechtigungsmodell, nicht als nachträglichen Gedanken.
Berechtigungen sind keine Checkbox bei der Vergabe
Eine Berechtigungsüberarbeitung, ein Protokoll-Update und ein Identitätsmodell stellen drei unterschiedliche Ebenen desselben Problems dar. Damit jede Ebene wirksam bleibt, müssen auch die anderen beiden wirksam sein. Wenn Sie am ersten Tag ein Credential mit dem richtigen Umfang erstellen, aber niemand je überprüft, ob es weiterhin gültig ist, war Ihre Mühe vergeblich. Ebenso: Wenn Sie ein neues Protokoll entwickeln, das endlich einen Agenten von der Person hinter ihm unterscheidet, aber alle Integrationen weiterhin standardmäßig dauerhaften Alles-oder-nichts-Zugriff bieten, haben Sie wenig erreicht. Keiner dieser Ansätze adressiert die tiefere Frage, die beiden zugrunde liegt: Was ein Agent tun darf, sollte davon abhängen, wie lange er existieren wird. Derzeit weiß nahezu keine Komponente des Technologie-Stacks, wie man diese Frage überhaupt stellt, geschweige denn beantwortet. Die Teams, die das richtig machen, werden nicht diejenigen sein, die einen effizienteren Scanner entwickelt haben. Es werden vielmehr die Teams sein, die aufgehört haben, Umfang, Identität und Lebensdauer als drei getrennte, einmal pro Agenteninstanz durchgeführte Bewertungen zu betrachten, und begonnen haben, sie als eine einzige Einstellung zu behandeln, die jedes Mal neu bewertet werden muss, wenn sich Funktion oder Existenz des Agenten ändern.
