Five-Eyes-Agenturen warnen: Die meisten Agentic-AI-Implementierungen sind bereits zu permissiv

Am 1. Mai 2026 veröffentlichten CISA, die NSA und ihre Pendants aus dem Vereinigten Königreich, Australien, Kanada und Neuseeland die erste koordinierte, mehrere Regierungen umfassende Sicherheitsrichtlinie für Agentic AI: "Careful Adoption of Agentic AI Services." Die Kernaussage ist klar – Organisationen der kritischen Infrastruktur und Verteidigung bewerten nicht ein zukünftiges Risiko, sie betreiben bereits Agenten mit mehr Zugriff, als ihre eigenen Sicherheitsteams nachvollziehen können, und die Richtlinie existiert, weil diese Lücke aufgehört hat, theoretisch zu sein.

Was dieses Dokument auch dann lesenswert macht, wenn Sie nicht im Bereich der kritischen Infrastruktur tätig sind, ist, dass es der erste Versuch von Sicherheitsbehörden ist, formal zu kategorisieren, was bei einem KI-Agenten schiefgehen kann – im Gegensatz zu einer traditionellen Anwendung – und die Kategorien decken sich klar mit Fehlern, die die meisten Teams, die derzeit Agenten einsetzen, bereits machen.

Fünf Risikokategorien – und warum sie sich nicht auf "Prompt Injection" reduzieren lassen

Die Richtlinie unterteilt das Risiko von Agentic AI in fünf Kategorien: Privilegien, Gestaltung und Konfiguration, Verhalten, Struktur und Verantwortlichkeit. Das ist bewusst breiter gefasst als der übliche Fokus der Sicherheitsbranche auf Prompt Injection und Jailbreaks, und die Begründung ist einfach – ein Agent mit eng definierten, korrekt abgesteckten Privilegien ist selbst bei erfolgreicher Manipulation weit weniger gefährlich, weil die Manipulation nirgendwohin führen kann.

Privilegienrisiko betrifft Agenten, die dauerhaften Zugriff auf Systeme, Daten oder Aktionen haben, die weit über das hinausgehen, was eine einzelne Aufgabe erfordert – das KI-Äquivalent eines Service-Kontos mit Domain-Admin-Rechten, weil niemand dazu kam, es einzuschränken. Gestaltungs- und Konfigurationsrisiko umfasst Agenten, die in Toolchains und externe Datenquellen eingebunden sind, ohne dass jemand kartiert hat, was diese Verbindung tatsächlich offenlegt. Verhaltensrisiko ist, wenn der Agent auch ohne externe Manipulation etwas Unbeabsichtigtes tut – eine emergente Aktion, die niemand explizit programmiert hat. Strukturrisiko betrifft die geschichteten Abhängigkeiten, die Agenten einführen (ein kompromittiertes Tool oder eine kompromittierte Datenquelle wird zu einem kompromittierten Agenten). Verantwortlichkeitsrisiko ist am schwersten nachzurüsten: Wenn ein Agent eine folgenreiche Aktion ausführt, kann dann jemand rekonstruieren, warum, und wer dafür verantwortlich ist, dass es passiert ist.

Das Problem der vernetzten Angriffsfläche

Die Richtlinie macht deutlich, dass das zentrale Sicherheitsproblem von Agentic AI nicht das Modell ist – es ist die Anzahl der Komponenten, die ein Agent typischerweise berührt. Ein einzelner Kundenservice-Agent könnte eine CRM-API, eine Knowledge Base, ein Ticketsystem und ein E-Mail-Tool aufrufen, jedes mit eigenen Credentials und Fehlermodi. Das Dokument warnt, dass dies "eine vernetzte Angriffsfläche schafft, die böswillige Akteure ausnutzen können," weil die Kompromittierung eines einzelnen Glieds in dieser Kette die effektiven Berechtigungen des Agenten über alle hinweg vererben kann.

Genau dieses Muster liegt den schwerwiegenderen KI-Agenten-Sicherheitsvorfällen zugrunde, die in diesem Jahr bekannt wurden – Angreifer müssen das Modell selbst nicht brechen, wenn sie eine schwach gesicherte Tool-Integration kompromittieren und den Zugriff erben, der dem Agenten gewährt wurde.

Was die Richtlinie Ihnen tatsächlich zu tun rät

Entfernt man den Rahmen, bleibt ein operativer Kern von fünf Regeln, die heute alle mit bestehenden Identity- und Access-Tooling durchsetzbar sind:

Gewähren Sie Agenten niemals breiten oder uneingeschränkten Zugriff. Wenn das Servicekonto eines Agenten mehr kann, als seine dokumentierte Aufgabenliste erfordert, ist das die Lücke, die Angreifer nutzen werden – und es ist normalerweise eine Lücke, die aus Bequemlichkeit bei der ersten Bereitstellung entstanden ist, nicht aus einer bewussten Entscheidung.

Beschränken Sie Agenten standardmäßig auf risikoarme, nicht sensible Aufgaben und verlangen Sie eine explizite, geprüfte Ausnahme zur Erweiterung des Umfangs – das kehrt das übliche Muster um, zunächst breiten Zugriff zu gewähren und später einzuschränken (was selten tatsächlich geschieht).

Durchsetzen Sie Least Privilege mit Authentifizierung pro Anfrage, nicht mit einer einzigen dauerhaften Anmeldeinformation, die der Agent für seine gesamte Lebensdauer besitzt. Jeder Tool-Aufruf sollte unabhängig authentifiziert und abgegrenzt werden, sodass eine kompromittierte Sitzung keine pauschalen Berechtigungen erbt.

Verlangen Sie menschliche Genehmigung für Aktionen mit hoher Auswirkung – Finanztransaktionen, Datenlöschungen, Zugriffskontrolländerungen, alles, was teuer oder schwer rückgängig zu machen ist. Die Richtlinie behandelt dies als nicht verhandelbar und nicht als nettes Extra für frühe Bereitstellungen.

Verwalten Sie die Sicherheit von KI-Agenten innerhalb bestehender Cybersicherheits-Frameworks, nicht als paralleles, maßgeschneidertes Programm. Agenten sollten in denselben Asset-Inventaren, Zugriffsprüfungen und Incident-Response-Playbooks auftauchen wie jede andere Systemkomponente mit Credentials und Netzwerkzugriff.

Die Kernerkenntnis für Teams, die in diesem Quartal Agenten ausliefern

Wenn Sie einen KI-Agenten in Produktion bringen und nicht beantworten können "Wie groß ist der maximale Schadensradius, wenn die Sitzung dieses Agenten jetzt kompromittiert wird?", dann sagt die Five-Eyes-Richtlinie, dass Sie ein Privilegienproblem haben, kein Modellproblem. Führen Sie vor Ihrer nächsten Agentenbereitstellung eine Zugriffsprüfung durch: Listen Sie jedes Tool, jede API und jede Datenquelle auf, die der Agent erreichen kann, und fragen Sie dann, ob jede auf die engste aufgabenspezifische Berechtigung abgestimmt ist, nicht auf eine breite dienstleistungsbezogene Gewährung. Diese einzige Übung schließt die Lücke, die die meisten Incident-Post-Mortems dieses Jahr gemeinsam haben.