Chatbots beraten. Copiloten schlagen vor. Agenten handeln.
Genau dieser Unterschied ist der Grund, warum die Sicherheitsmodelle, die wir für klassische Software und die erste Generation generativer KI aufgebaut haben, für agentische Systeme nicht mehr ausreichen. Ein KI-Agent, der eigenständig E-Mails versendet, Code ausführt, Datenbanken pflegt oder Bestellungen auslöst, ist kein Chatbot mit Zusatzfunktionen. Er ist ein autonom handelnder Akteur in Ihrer IT-Landschaft – mit eigenen Berechtigungen, eigenem Gedächtnis und eigenen Fehlermodi.
OWASP hat darauf reagiert und mit der Top 10 for Agentic AI Applications 2026 erstmals ein Risikoframework speziell für autonome KI-Agenten veröffentlicht. Zehn Risikokategorien, ASI01 bis ASI10, plus ein Leitprinzip: Least Agency – so viel Autonomie wie nötig, so wenig wie möglich.
In diesem Beitrag ordne ich das Framework aus der Perspektive ein, die mir im Alltag als ISO-27001- und NIS-2-Auditor begegnet: Was heißt das konkret für Ihr Risikomanagement, Ihre SoA und Ihre Nachweispflichten?
Was agentische Risiken anders macht
In klassischer Software sind Schwachstellen lokalisierbar: eine SQL-Injection in einem Formularfeld, eine fehlerhafte Zugriffskontrolle an einem Endpunkt. Man findet sie, man patcht sie, man dokumentiert sie.
Agentische Risiken sind dagegen kombinatorisch. Eine für sich genommen harmlose Manipulation der Eingabe wird erst gefährlich, wenn sie auf einen Agenten mit weitreichendem Werkzeugzugriff trifft. Fehlt dann noch eine Validierung der Ausgaben oder eine Authentifizierung zwischen Agenten, entsteht aus drei „mittleren” Einzelrisiken ein kritisches Gesamtrisiko.
Für Auditoren und Risikomanager ist das eine unbequeme Nachricht: Die Risikoanalyse pro Einzelkomponente greift zu kurz. Sie müssen Wirkketten betrachten – so wie Sie es aus der Business-Impact-Analyse im BCM eigentlich schon kennen.
Ein zweiter struktureller Unterschied: Sprachmodelle sind statistische Vorhersagemaschinen. Sie erzeugen Token für Token nach Wahrscheinlichkeiten – ohne Verständnis für die Konsequenzen ihrer Ausgaben. Selbst bei identischen Eingaben ist das Verhalten nicht vollständig reproduzierbar; schon unterschiedliche Hardware-Konfigurationen können Ergebnisse verschieben. Für die Compliance heißt das: Ein bestandener Test ist kein dauerhafter Nachweis. Wer agentische Systeme absichert, braucht kontinuierliche Kontrollen statt einmaliger Abnahmen.
Die zehn Risiken im Überblick
OWASP gruppiert die zehn Kategorien entlang der Verarbeitungskette – Eingabe, Verarbeitung, Ausgabe – plus übergreifende Infrastrukturrisiken:
Eingabe
- ASI01 – Agent Goal Hijack: Angreifer manipulieren nicht nur einzelne Antworten, sondern die Ziele und Pläne des Agenten selbst. Die Vektoren reichen von indirekter Prompt Injection über präparierte Dokumente bis zu gefälschten Nachrichten zwischen Agenten.
- ASI09 – Ausnutzung des Mensch-Agent-Vertrauens: Der Agent wird selbst zum Social-Engineering-Werkzeug. Menschen genehmigen, was ein überzeugend formulierender Agent empfiehlt – und tragen im Zweifel die forensische Verantwortung.
Verarbeitung
- ASI03 – Identitäts- und Privilegienmissbrauch: Agenten erben häufig dauerhaft die vollen Rechte ihrer Nutzer. Delegationsketten („Agent A bittet Agent B”) werden zum Angriffspfad.
- ASI06 – Memory und Context Poisoning: Manipulierte Inhalte in persistenten Speichern, Embeddings oder RAG-Datenbanken vergiften das Verhalten über Sitzungen hinweg. Besonders tückisch: selbstverstärkende Effekte, wenn der Agent eigene kompromittierte Schlussfolgerungen später als Beleg wieder abruft.
- ASI10 – Fehlgeleitete Agenten: Der Kontrollverlust nach der ersten Kompromittierung. Ein Agent, der Cloud-Kosten minimieren soll und dafür Produktions-Backups löscht, erfüllt sein Ziel – nur eben katastrophal.
Ausgabe
- ASI02 – Toolmissbrauch: Der Agent nutzt legitime Werkzeuge innerhalb seiner Berechtigungen auf schädliche Weise – der Moment, in dem aus Manipulation realer Schaden wird.
- ASI07 – Unsichere Inter-Agenten-Kommunikation: Verschlüsselung allein reicht nicht. Natürlichsprachige Kommunikation zwischen Agenten verliert mit jedem Schritt an Präzision – nötig sind typisierte, schema-validierte Schnittstellen.
Infrastruktur (phasenübergreifend)
- ASI04 – Supply-Chain-Schwachstellen: Agentische Systeme bauen ihre Abhängigkeiten zur Laufzeit auf. Eine klassische SBOM greift ins Leere, wenn der Agent Werkzeuge und Pakete dynamisch nachlädt.
- ASI05 – Unbeabsichtigte Codeausführung: Agenten, die Code generieren und ausführen dürfen, sind strukturell RCE-anfällig. Codegenerierung und -ausführung gehören getrennt.
- ASI08 – Kaskadierende Ausfälle: Das vermutlich am meisten unterschätzte Risiko. Ein einzelner Fehler pflanzt sich durch autonome Folgeentscheidungen fort – schneller, als Menschen reagieren können.
Die Compliance-Brücke: ASI Top 10 trifft ISO 27001 und NIS-2
Und jetzt die gute Nachricht: Sie fangen nicht bei null an. Die meisten Gegenmaßnahmen sind keine KI-Exotik, sondern konsequent angewandte Klassiker – Least Privilege, Zero Trust, Segmentierung, Protokollierung. Was fehlt, ist die systematische Übersetzung in Ihr bestehendes Managementsystem. Eine erste Zuordnung:
| OWASP-Risiko | ISO 27001:2022 (Annex A) | NIS-2 (Art. 21 Abs. 2) |
|---|---|---|
| ASI01 Goal Hijack | 8.26 Anforderungen an Anwendungssicherheit, 5.14 Informationsübertragung | lit. e – Sicherheit in Entwicklung und Beschaffung |
| ASI02 Toolmissbrauch | 8.2 Privilegierte Zugriffsrechte, 8.18 Nutzung privilegierter Dienstprogramme | lit. i – Zugriffskontrolle |
| ASI03 Identitätsmissbrauch | 5.16 Identitätsmanagement, 5.18 Zugriffsrechte, 8.5 Sichere Authentifizierung | lit. i/j – Zugriffskontrolle, MFA |
| ASI04 Supply Chain | 5.19–5.22 Lieferantenbeziehungen | lit. d – Sicherheit der Lieferkette |
| ASI05 Codeausführung | 8.28 Sichere Codierung, 8.31 Trennung von Umgebungen | lit. e – sichere Entwicklung |
| ASI06 Memory Poisoning | 8.12 Verhinderung von Datenlecks, 5.33 Schutz von Aufzeichnungen | lit. c – Aufrechterhaltung des Betriebs |
| ASI07 Inter-Agenten-Kommunikation | 8.20/8.21 Netzwerksicherheit und -dienste, 8.24 Kryptografie | lit. h – Kryptografie |
| ASI08 Kaskadierende Ausfälle | 5.29/5.30 Kontinuität, 8.14 Redundanz | lit. b/c – Incident-Handling, BCM |
| ASI09 Mensch-Agent-Vertrauen | 6.3 Awareness, 5.3 Aufgabentrennung | lit. g – Cyberhygiene und Schulung |
| ASI10 Fehlgeleitete Agenten | 8.16 Überwachung, 5.25 Bewertung von Ereignissen | lit. b – Incident-Handling |
Diese Tabelle ist bewusst eine Erstannäherung – die genaue Zuordnung hängt von Ihrer Architektur ab. Aber sie zeigt das Prinzip:
Agentische KI ist kein neues Managementsystem. Sie ist ein neuer Geltungsbereich für Ihr bestehendes.
Wer zusätzlich unter den AI Act fällt, findet in der Agenteninventarisierung und der Protokollierungspflicht ohnehin alte Bekannte wieder: Ein sauberes Verzeichnis der eingesetzten KI-Systeme inklusive Fähigkeiten, Datenzugriffen und Verantwortlichkeiten ist die gemeinsame Grundlage für beide Welten.
Warum „wir schreiben es in den Systemprompt” nicht reicht
Ein Befund aus der aktuellen Sicherheitsforschung sollte jede Diskussion über KI-Guardrails prägen: Promptbasierte Verteidigungen versagen systematisch gegen adaptive Angreifer. Wer sein Sicherheitskonzept darauf aufbaut, dem Modell im Systemprompt Regeln mitzugeben, verlässt sich auf eine Komponente, die per Definition manipulierbar ist.
Die Konsequenz ist ein architektonisches Prinzip, das jedem ISB vertraut vorkommen dürfte: Kontrolle gehört nach außen. Konkret bedeutet das:
- Externe Reference Monitors, die jede Agentenaktion vor der Ausführung deterministisch gegen eine Policy prüfen – nicht das Modell fragt sich selbst, ob es darf.
- Sandboxing und Umgebungstrennung, sodass ein kompromittierter Agent nicht automatisch die Rechte seines Nutzers hat.
- Typisierte, validierte Kommunikation zwischen Agenten statt freier natürlicher Sprache.
- Human-in-the-Loop für irreversible Aktionen – Löschen, Überweisen, Veröffentlichen, Deployen.
Hilfreich als Faustregel ist die „Rule of Two”: Von den drei Eigenschaften (a) Zugriff auf vertrauliche Daten, (b) Verarbeitung nicht vertrauenswürdiger Inhalte und (c) Kommunikation nach außen sollte ein einzelner Agent höchstens zwei gleichzeitig besitzen. Alle drei zusammen – manchmal „Lethal Trifecta” genannt – sind eine Einladung zur Datenexfiltration.
Fünf Maßnahmen, die Sie innerhalb einer Woche starten können
- Agenteninventar anlegen. Alle agentischen Systeme erfassen – auch Experimente und Schatten-Deployments aus Fachabteilungen. Pro Agent: Zweck, Fähigkeiten, Datenzugriffe, Berechtigungen, Verantwortlicher. Das ist zugleich Ihre Vorarbeit für den AI Act.
- Least Agency durchsetzen. Jede Fähigkeit, die der Agent nicht zwingend braucht, entfernen. Autonomie ist Angriffsfläche.
- Irreversible Aktionen identifizieren und mit Freigaben versehen. Welche Aktionen Ihrer Agenten sind nicht rückholbar? Diese Liste ist kurz – und jede Position darauf braucht einen menschlichen Genehmigungsschritt.
- Observability aufbauen. Unveränderliche, signierte Audit-Logs für Agentenaktionen. Ohne Nachvollziehbarkeit keine Absicherung – und nebenbei: keine Auditfähigkeit.
- Bedrohungsmodell erweitern. Agentenketten, Memory Poisoning und kaskadierende Ausfälle in bestehende Risikoanalysen und Incident-Response-Playbooks aufnehmen. Ihre heutigen Playbooks decken kompromittierte Agentenketten mit hoher Wahrscheinlichkeit nicht ab.
Fazit
Agentische KI verschiebt die Sicherheitsfrage von „Was kann das Modell sagen?” zu „Was kann das System tun?”. Das OWASP-Framework liefert dafür erstmals eine gemeinsame Sprache – und die zentrale Botschaft ist ausgesprochen kompatibel mit dem, was gute Informationssicherheit immer war: Misstraue Eingaben. Begrenze Berechtigungen. Protokolliere Aktionen. Erzwinge Kontrollen deterministisch von außen.
Neu ist nicht die Toolbox. Neu ist der Geltungsbereich.
Sie setzen bereits KI-Agenten ein oder planen es – und fragen sich, wie das in Ihr ISMS, Ihre NIS-2-Umsetzung oder Ihre AI-Act-Vorbereitung passt? Genau an dieser Schnittstelle arbeite ich. Sprechen Sie mich an.