Sicherheit
KI-Agenten-Angriffserfolgsrate: ein CVSS für Ihr Risikoregister

Jahrelang war das Risiko eines KI-Agenten ein Absatz voller Vagheit. Am 28. Mai 2026 änderte sich das: Die System Card zu Claude Opus 4.8 von Anthropic berichtete, dass ein browser-nutzender Agent in 31,5 % der Fälle durch einen Prompt-Injection-Angriff gekapert wurde, ohne Schutzmaßnahmen, und in 0,5 % mit ihnen. Das ist eine Angriffserfolgsrate, und sie tut für einen KI-Agenten, was CVSS für ein Firewall-CVE tut. Sie verwandelt eine vage Sorge in einen Wert, den Sie ins Risikoregister setzen, einem Verantwortlichen zuweisen und behandeln können. Wenn Sie ein reguliertes Netz betreiben, ist das die Entwicklung, die ändern sollte, wie Sie Agenten in diesem Quartal steuern.
Ich bewerte seit siebzehn Jahren Risiken in Enterprise- und KRITIS-regulierten Beständen, und das Muster ändert sich nie: Gemanagt werden die Risiken, neben denen eine Zahl steht. Ein Firewall-CVE landet mit einem CVSS, also kommt es in die Triage, bekommt eine Patch-SLA und taucht im Audit-Trail auf. Ein KI-Agent, der ins selbe Netz verdrahtet ist, kam mit nichts, also blieb er ganz außerhalb des Registers. Anthropic hat diese Ausrede gerade beseitigt. Der Agent ist nun ein messbares, privilegiertes Asset, und die Disziplin, die Sie bereits auf Firewall-Änderungen anwenden, ist die, die er braucht.
Was sich geändert hat: KI-Agenten-Risiko bekam eine Zahl
Die Schlagzeile ist die Browser-Angriffserfolgsrate von 31,5 % ohne Schutzmaßnahmen, aber der nützliche Teil ist die Spannweite. Mit aktiven Schutzmaßnahmen fiel dieselbe Messung auf 0,5 %, eine Reduktion um mehr als das 60-Fache. In einer Coding-Werkzeug-Umgebung gegen einen adaptiven Angreifer berichtete Anthropic 7,03 % ohne und 2,09 % mit Schutzmaßnahmen. Laut der System Card zu Anthropic Opus 4.8 wurden diese Werte gegen zurückgehaltene Injection-Angriffe über definierte Agenten-Umgebungen gemessen, und die Karte veröffentlicht sogar eine Red-Team-Kennzahl, bei der das neue Modell schlechter abschnitt als sein Vorgänger. Genau diese Bereitschaft, eine Verschlechterung zu drucken, macht die Zahl vertrauenswürdig genug, um danach zu steuern.
Für einen Netzbetreiber zählt nicht der konkrete Wert. Es zählt, dass eine Angriffserfolgsrate jetzt existiert, so wie ein CVSS-Wert existiert. Sie können zwei Agentenplattformen daran vergleichen, im Einkauf eine Schwelle setzen und die Zahl von jedem Anbieter verlangen, der innerhalb Ihres Perimeters sitzen will. Prompt Injection steht seit 2023 an erster Stelle der OWASP Top 10 für LLM-Anwendungen. Was fehlte, war eine Möglichkeit, die eigene Exposition dagegen zu quantifizieren. Jetzt gibt es eine.
Warum ein KI-Agent ins Firewall-Risikoregister gehört
Ein KI-Agent mit Werkzeugen ist ein privilegiertes Asset. Er liest nicht vertrauenswürdige Eingaben, hält Anmeldedaten und kann auf Systemen handeln, was genau das Profil eines Firewall-Management-Pfads oder eines Automatisierungskontos ist. Diese verfolgen Sie bereits im Risikoregister, weil sie erreichbar und mächtig sind und Schaden anrichten können, wenn sie unterwandert werden. Ein Agent, der browsen, APIs aufrufen oder Code ausführen kann, besteht denselben Test. Ihn aus dem Register zu lassen ist keine kleinere Entscheidung, als ein Management-Interface auszulassen.
Das Bedrohungsmodell ist jenes, über das ich im Kontext der Bedrohungsmodellierung für KI-Agenten geschrieben habe: Der Agent wird über die Inhalte manipuliert, die er verarbeitet, nicht über den Code, den er ausführt. CVE-2026-0300 lehrte die Firewall-Welt in diesem Frühjahr dieselbe Lektion von der anderen Seite, dass eine unauthentifizierte Eingabe zur vollen Kontrolle werden kann, und die Antwort darauf war ein Change-Management-Problem, kein Coding-Problem. Diesen Fall habe ich ausführlich in wenn eine Root-RCE landet, ist Ihr Änderungsmanagement Ihre Incident Response gemacht. Ein Agenten-Hijack hat dieselbe Form: eine externe Eingabe, die in privilegiertes Handeln übergeht. Er gehört ins selbe Register, gleich bewertet.
CVSS fürs CVE, ASR für den Agenten: die Zuordnung
Die Analogie ist nicht lose. Eine Angriffserfolgsrate fügt sich genau an den Stellen in den Risikomanagement-Workflow ein, an denen es ein CVSS-Wert tut. Die folgende Tabelle ist die Zuordnung, die ich einem Risikoausschuss vorlegen würde.
| Risikoregister-Dimension | Firewall-CVE (CVSS) | KI-Agent (Angriffserfolgsrate) |
|---|---|---|
| Was die Zahl bewertet | Ausnutzbarkeit und Wirkung einer Schwachstelle | Anteil der Injection-Versuche, die den Agenten kapern |
| Woher sie kommt | Hersteller-Advisory, NVD | Hersteller-System-Card oder eigenes Eval-Harness |
| Warum sie sich ändert | Neu bewertet, wenn Ausnutzung beobachtet wird | Verschiebt sich mit Schutzmaßnahmen, Werkzeugen, Bedrohungsmodell |
| Welche Behandlung sie auslöst | Patch-SLA, kompensierende Kontrollen | Schutzmaßnahmen, Werkzeuge mit geringsten Rechten, menschliche Freigabe |
| Restrisiko nach Mitigation | Ungepatchte Exposition, die Sie akzeptieren oder isolieren | Die 0,5 %, die durchkommen, bewertet nach Schadensradius |
| Was ein Auditor will | Nachweis, dass der Patch autorisiert und angewandt wurde | Nachweis, dass der Agent bewertet, behandelt und nachgeprüft wurde |
Die letzte Zeile unterschätzen regulierte Betreiber. Ein Auditor akzeptiert „wir nutzen ein führendes Modell" ebenso wenig als Kontrolle, wie er „wir betreiben eine führende Firewall" als Patch-Nachweis akzeptiert. Er will die Bewertung, die Behandlung und den Beweis, dass sie geprüft wurde. Eine Angriffserfolgsrate liefert Ihnen die erste Spalte dieses Datensatzes.
Wie Sie einen Agenten ins Register aufnehmen
Einen Agenten als Registereintrag zu behandeln ist eine Übung in fünf Schritten, und nichts davon ist neu, wenn Sie Firewall-Änderungen schon richtig betreiben.
Erstens: Identifizieren Sie jeden Agenten, der handeln kann, und schreiben Sie seinen Schadensradius auf: was er lesen, was er aufrufen, was er ändern kann. Diese Reichweite, nicht der Benchmark eines Modells, ist Ihr echtes Risiko. Zweitens: Hängen Sie eine Zahl an, nutzen Sie die veröffentlichte Angriffserfolgsrate des Anbieters, wo es eine gibt, und bauen Sie Ihre eigene Injection-Evaluierung, wo es keine gibt. Drittens: Weisen Sie einen Verantwortlichen zu, so wie jede Firewall-Regel einen haben sollte. Viertens: Definieren Sie die Behandlung, beschränken Sie die Werkzeuge des Agenten auf die Aufgabe, sperren Sie unumkehrbare Aktionen hinter menschliche Freigabe und legen Sie Default-Deny-Egress um die Laufzeit, damit ein erfolgreicher Hijack nichts exfiltrieren kann. Fünftens: Setzen Sie eine Wiederbewertungs-Kadenz, denn die Zahl bewegt sich mit jeder Modell- und Prompt-Änderung.
Der vierte Schritt ist dort, wo die Firewall-Disziplin am direktesten übergeht. Ein Agent, der ohne protokollierten, baseline-getriebenen Änderungsprozess auf Ihrem Netz handeln kann, ist eine nicht autorisierte Änderung, die nur darauf wartet zu passieren, und die Kontrollen, die Policy Drift auf einer Firewall fangen, eine als korrekt bekannte Baseline und ein manipulationssicheres Protokoll, sind dieselben, die Ihnen sagen, wenn ein Agent etwas tat, das er nicht sollte. Die umfassendere Praxis ist die im Leitfaden zum Firewall-Änderungsmanagement: Nichts Privilegiertes handelt ohne Autorisierung, eine protokollierte Baseline und einen getesteten Weg zurück.
NIS2 und ISO 27001 verlangen das bereits
Wenn Sie unter NIS2 stehen, ist das keine freiwillige Hausarbeit. Artikel 21 verlangt Risikomanagement-Maßnahmen, die den Risiken angemessen sind, denen eine Einrichtung gegenübersteht, und ein KI-Agent mit Zugriff auf Netzsysteme ist nun klar eines dieser Risiken. Sie können nicht bewerten, was Sie nicht gemessen haben, weshalb eine veröffentlichte Angriffserfolgsrate mehr ist als eine Marketingzeile: Sie ist die Eingabe, die Ihrer Risikobewertung fehlte. Die Nachweispflichten, die ich in NIS2-Firewall-Nachweisen 2026 behandelt habe, gelten für Agenten-Risiko genauso, dass die Bewertung und ihre Behandlung nachweisbar sein müssen, nicht behauptet.
ISO 27001 rahmt es über seine Klauseln zur Risikobewertung und Risikobehandlung: das Asset identifizieren, das Risiko bewerten, die Behandlung entscheiden und die Aufzeichnungen führen. Ein Agent ist nach jeder Lesart dieser Norm ein Asset. Dieselbe Checklisten-Denkweise hinter einem ISO-27001-Firewall-Audit erstreckt sich sauber auf Agenten: auflisten, bewerten, behandeln, nachweisen. Das deutsche BSI und der weitere NIS2-Rahmen gewähren keine Ausnahme, weil das Asset zufällig ein Sprachmodell betreibt. Wenn überhaupt, zieht ein neuartiges, mächtiges, von außen beeinflussbares Asset mehr Prüfung an, nicht weniger, was der Blickwinkel ist, den ich auf KI im CISO-Leitfaden zur KI-Bedrohungserkennung nehme.
Machen Sie die Zahl zur Beschaffungsanforderung
Die Firewall-Welt lernte längst, keine Box von einem Hersteller zu kaufen, der keine Advisories veröffentlicht. Wenden Sie dieselbe Regel auf Agenten an. Verlangen Sie von jedem Agenten- oder KI-Plattform-Anbieter eine Angriffserfolgsrate unter Prompt Injection, mit angegebenem Harness und angegebenen Schutzmaßnahmen. Kann er keine nennen, hat er sie nicht gemessen, und ein Risiko ohne Zahl erreicht Ihr Register nie. Anthropic setzte den Präzedenzfall durch die Veröffentlichung; Ihre Aufgabe ist, diese Offenlegung zum Mindeststandard zu machen, nicht zur Ausnahme, so wie ein CVSS und ein Security-Advisory für einen Firewall-Hersteller zur Pflicht wurden.
Im eigenen Bestand skaliert die Disziplin so, wie sie es bei einer Multi-Vendor-Firewall-Flotte tut. Sie brauchen kein eigenes Steuerungsmodell pro Agent, ebenso wenig wie eines pro Firewall-Hersteller, ein Punkt, der über die Multi-Vendor-Firewall-Verwaltung hinweg gilt: ein Register, eine Bewertungsmethode, ein Nachweis-Trail, konsequent angewandt.
Bauen Sie die Disziplin auf, bevor Sie sie brauchen
Der unbequeme Teil ist derselbe wie bei jedem CVE. Die Arbeit, die Sie schützt, ist Arbeit, die Sie vor dem Vorfall leisten müssen, nicht währenddessen. Sie können Ihre Agenten nicht in der Stunde inventarisieren, bewerten und ihre Behandlung definieren, in der ein Agent gekapert wird, ebenso wenig wie Sie ein Firewall-Inventar während einer aktiven Root-RCE aufbauen können. Die Teams, die den ersten ernsten Agenten-Kompromiss gut handhaben werden, sind jene, die Agenten jetzt ins Register aufnehmen, solange es die Arbeit eines ruhigen Nachmittags ist statt einer forensischen Rekonstruktion.
Das ist die Disziplin, um die herum FwChange gebaut ist, und sie ist von Natur aus herstellerunabhängig. Das nächste privilegierte Asset in Ihrem Netz wird ein KI-Agent sein, und die Fragen, die eine Aufsichtsbehörde dazu stellt, wo ist er, was kann er, wie wurde das Risiko behandelt und können Sie es beweisen, sind die Fragen, die eine Change-Management-Praxis standardmäßig beantwortet. Wenn Sie wissen wollen, ob Ihr derzeitiger Prozess dem standhält, arbeitet unser kostenloser NIS2-Check genau diese Fragen durch, bevor ein Auditor oder ein Vorfall sie Ihnen aufzwingt. Als Distributions-Notiz: Sie können fwchange.com in Ihren Google-Einstellungen als bevorzugte Quelle festlegen, damit diese Analysen weiter in AI Overviews auftauchen.
Über den Autor
Nick Falshaw ist Principal Security Architect mit über 17 Jahren Erfahrung in Enterprise-Firewall- und Netzwerksicherheit bei Tier-1-Großkunden, KRITIS-regulierten Betreibern und EU-Finanzdienstleistern. Er ist Autor der FwChange-Methodik nach Analyse von mehr als 280 Firewall-Migrationen und arbeitet heute an der Grenze von Netzwerksicherheit und KI-Systemen.

