OWASP Agentic AI Top 10 × EU AI Act: Die vollständige Compliance-Crosswalk

Die zentrale Zuordnungsmatrix: alle 10 ASI-Risiken den Artikeln des EU AI Act zugeordnet¶

Jede Zeile unten ordnet ein OWASP-ASI-Risiko den primären Artikeln des EU AI Act zu, die es bindend regeln, den sekundären Artikeln, die es berührt, der Kernpflicht, die daraus für Anbieter und Betreiber entsteht, und dem Nachweisartefakt, das eine konforme Umsetzung hervorbringt. Der operative Download zu diesem Beitrag ist das PDF-Workbook; die maschinenlesbare CSV bleibt als unterstützender Anhang verfügbar.

Download: Das Gap-Assessment-Workbook — owasp-asi-eu-ai-act-gap-assessment-workbook.pdf (keine E-Mail, kein Gate). Sekundärer Anhang: owasp-asi-top10-eu-ai-act-crosswalk.csv.

Was ist die OWASP Agentic Security Initiative Top 10?¶

Die OWASP Top 10 for Agentic Applications 2026 ist der kanonische Katalog der zehn kritischsten Sicherheitsrisiken in autonomen, werkzeugnutzenden KI-Agentensystemen. Sie wurde am 9. Dezember 2025 auf dem London Agentic Security Summit durch die Agentic Security Initiative (ASI) veröffentlicht, eine Arbeitsgruppe innerhalb des OWASP GenAI Security Project. Jedes Risiko trägt das Präfix `ASI` (Agentic Security Issue) und ist nach Häufigkeit und Auswirkung gewichtet, wie sie in Produktivumgebungen im Verlauf der Jahre 2024 und 2025 beobachtet wurden.

Die Initiative wird gemeinsam geleitet von John Sotiropoulos (Head of AI Security bei Kainose, ASI Co-lead und Top-10-Chair) und Keren Katz (Senior Group Manager AI Security bei Tenable, Top-10-Co-Lead), unter dem OWASP GenAI Security Project, das von Steve Wilson (Chief Product Officer, Exabeam und Gründer der ursprünglichen OWASP Top 10 for LLMs) und Scott Clinton (SCVentures) gemeinsam geleitet wird. Die Entwicklung erstreckte sich über mehr als ein Jahr mit Beiträgen von über 100 Sicherheitsforschenden und einem Expert Review Board mit Vertretern von NIST (Apostol Vassilev), Microsoft AI Red Team (Pete Bryan, Dan Jones), AWS (Matt Saner), Cisco (Hyrum Anderson), Oracle Cloud (Egor Pushkin), dem Alan Turing Institute (Vasilios Mavroudis, Josh Collyer) und Zalando (Alejandro Saucedo).

Die Branche hat das Framework unmittelbar aufgegriffen. Microsoft veröffentlichte einen Blogbeitrag, der alle 10 ASI-Risiken auf Kontrollen in Copilot Studio abbildet (März 2026), und stellte das Open-Source-Projekt Agent Governance Toolkit vor (April 2026). NVIDIAs Safety and Security Framework referenziert den ASI Agentic Threat Modelling Guide. AWS integriert den Agentic Threats and Mitigations Catalogue. GoDaddy hat den ASI-Agentic-Naming-Service-Vorschlag im Produktivbetrieb umgesetzt. Palo Alto Networks hat alle 10 Risiken auf seine Prisma-AIRS-Plattform abgebildet. Apostol Vassilev vom NIST bezeichnete das Framework als zum richtigen Zeitpunkt erschienen, technisch fundiert und unmittelbar umsetzbar.

Ist die ASI Top 10 dasselbe wie die OWASP LLM Top 10?

Nein. Die OWASP Top 10 for Large Language Model Applications katalogisiert Risiken in Single-Turn-LLM-Anwendungen (Chatbots, RAG-Assistenten, Content-Generatoren). Die ASI Top 10 katalogisiert Risiken, die nur existieren, wenn ein LLM Autonomie, persistenten Speicher, Werkzeugzugriff und die Fähigkeit zur Kommunikation mit anderen Agenten erhält — die agentischen Grundbausteine. Zu den ASI-Risiken zählen kaskadierende Multi-Agenten-Ausfälle (ASI08), Angriffe auf die Inter-Agenten-Kommunikation (ASI07) und Rogue Drift (ASI10), für die es in der LLM Top 10 keine sinnvolle Entsprechung gibt. Beide Kataloge werden vom OWASP GenAI Security Project gepflegt und sind darauf ausgelegt, gemeinsam verwendet zu werden.

Die Artikel des EU AI Act im Anwendungsbereich agentischer Systeme¶

Der EU AI Act erwähnt agentische KI nicht ausdrücklich, aber das AI Office hat bestätigt, dass Agenten möglicherweise die Anforderungen an KI-Systeme und/oder die Pflichten von Anbietern allgemeiner KI-Modelle erfüllen müssen. Die Tabelle unten ist die Kurzreferenz zu jedem Artikel, der in der obigen Crosswalk genannt wird. Die Spalten umfassen die Artikelnummer, die Pflicht in einem Satz und ob sie den Anbieter, den Betreiber oder beide verpflichtet.

Download: Workbook, Controls-Checkliste und CSV-Anhang¶

Die folgenden Materialien sind kostenlos, ohne Registrierung und direkt zum Kopieren verfügbar. Verwenden Sie das PDF-Workbook für das interne Review-Meeting, die Checkliste für Implementierungsdetails und die CSV nur, wenn Sie einen maschinenlesbaren Anhang benötigen.

• owasp-asi-eu-ai-act-gap-assessment-workbook.pdf — ein fünfseitiges PDF für die Arbeitssitzung zu Systeminventar, ASI-Anwendbarkeitsbewertung, Nachweisprüfung, Backlog-Zuweisung und Freigabe.
• owasp-asi-top10-controls-checklist.md — rund 50 konkrete Kontrollen, gruppiert nach ASI-Risiko, jeweils mit Angabe des erfüllten Artikels des EU AI Act und des im Evidence Room erzeugten Artefakts.
• owasp-asi-top10-eu-ai-act-crosswalk.csv — der maschinenlesbare Anhang mit der vollständigen 10-zeiligen Zuordnung inklusive primärer und sekundärer Artikel sowie des erzeugten Nachweisartefakts je Zeile.

ASI01 — Agent Goal Hijack → Artikel 9, 15, 14, 5¶

ASI01 Agent Goal Hijack lenkt die Entscheidungsfindung eines Agenten durch injizierte Anweisungen oder vergiftete Inhalte um. Anders als bei klassischer Software-Exploitation, die Codeänderungen erfordert, werden KI-Agenten per natürlicher Sprache in E-Mails, Dokumenten oder Webseiten umgelenkt. Artikel 9 ist die primäre Pflicht: Das Risikomanagementsystem muss die vernünftigerweise vorhersehbare Fehlanwendung abdecken — eine Kategorie, die nun adversariale Prompt Injection zwingend einschließen muss.

Realer Vorfall. EchoLeak (CVE-2025-32711, CVSS 9.3) — die erste Zero-Click-Prompt-Injection in einem Produktivsystem — brachte Microsoft 365 Copilot dazu, über eine einzige präparierte E-Mail Daten zu exfiltrieren. Keine Nutzerinteraktion war erforderlich; der Agent las die E-Mail im Rahmen des normalen RAG-Retrieval und befolgte die eingebetteten Anweisungen.

• Input- und Output-Filterung mit Prompt-Injection-Erkennung auf jedem Pfad externer Inhalte einsetzen — erfüllt Art. 15; erzeugt Testbericht der Erkennungsengine im Evidence Room.
• Strikte System-Prompt-Isolation mit Instruktionshierarchie durchsetzen — erfüllt Art. 9; erzeugt Unit-Test-Log zur Hierarchie-Durchsetzung.
• Verhaltensanomalien an das Decision Desk zur menschlichen Intervention routen — erfüllt Art. 14(4)(c); erzeugt Assurance-Alert-Historie.
• Alle externen Inhalte standardmäßig als nicht vertrauenswürdig kennzeichnen, auf jedem Tool-Call-Pfad — erfüllt Art. 9; erzeugt Policy-Eintrag im Tool Catalog.
• Prompt-Injection-Red-Team-Übungen alle 90 Tage durchführen — erfüllt Art. 9(6) (Tests vor Inverkehrbringen); erzeugt Red-Team-Bericht im Evidence Room.

Erfüllt ein Prompt-Injection-Filter allein die Cybersicherheitsanforderungen aus Artikel 15?

Nein. Ein Filter ist eine einzelne Erkennungskontrolle. Artikel 15(5) verlangt Widerstandsfähigkeit als Systemeigenschaft: Sie muss kombiniert werden mit (1) strikter Durchsetzung der Instruktionshierarchie im System-Prompt, (2) Kennzeichnung nicht vertrauenswürdiger Inhalte bei Inputs und Outputs, (3) Verhaltens-Monitoring, das an die Intervention nach Artikel 14 angebunden ist, und (4) einem dokumentierten Eintrag im Risikoregister nach Artikel 9, der erklärt, warum die Kombination verhältnismäßig ist. Filter allein werden zudem von rekursiven oder verschleierten Payloads ausgehebelt, wie sie im OWASP AI Exchange dokumentiert sind; Defense-in-Depth ist die einzige Haltung, die Artikel 9 und 15 gleichzeitig erfüllt.

ASI02 — Tool Misuse and Exploitation → Artikel 9, 15, 12, 17, Anhang IV¶

ASI02 Tool Misuse tritt auf, wenn Agenten legitime Werkzeuge aufgrund mehrdeutiger Prompts, Misalignment oder manipulierter Eingaben auf unsichere Weise nutzen. Ein Coding-Assistent mit Dateisystemzugriff wird zum Exfiltrations-Tool; ein Customer-Service-Bot mit E-Mail-Zugriff zur Phishing-Maschine. Artikel 9(3) ist die primäre Pflicht: Das Risiko muss über die kombinierte Anwendung der Systemkomponenten bewertet werden — und Tool-Interaktionen sind genau das.

Realer Vorfall. Amazon Q Code Assistant (CVE-2025-8217) betraf rund 1 Million Entwicklerinnen und Entwickler, als kompromittierte GitHub-Tokens zerstörerische Anweisungen in die Tool-Chain des Assistenten injizierten. Die Anweisungen waren an der Tool-Call-Grenze von legitimer Entwicklerabsicht nicht zu unterscheiden.

• Least-Privilege-Tool-Scoping mit expliziten Allowlists anwenden — erfüllt Art. 9; erzeugt Scope-Eintrag im Tool Catalog.
• Jedes Tool-Argument beim Aufruf validieren und bereinigen — erfüllt Art. 15(4); erzeugt Testbericht zur Argumentvalidierung.
• Menschliche Freigabe für zerstörerische Operationen verlangen (DB-Schreibvorgänge, Finanztransaktionen, Dateilöschungen) — erfüllt Art. 14; erzeugt Decision-Desk-Freigabedatensatz.
• Jeden Tool-Aufruf mit Parametern, Aufrufer-Identität und Ergebnis protokollieren — erfüllt Art. 12; erzeugt Lineage Records.
• Jede Tool-Chain-Kombination im Risikoregister nach Artikel 9 dokumentieren — erfüllt Art. 9(3); erzeugt Risikoregistereintrag.

Muss ich die vollständigen Tool-Call-Argumente protokollieren oder reicht eine Zusammenfassung für Artikel 12?

Vollständige Argumente. Artikel 12(1) verlangt Protokolle, die die Nachvollziehbarkeit der Funktionsweise des Systems ermöglichen. Ein Zusammenfassungsfeld (Tool-Name + Zeitstempel) erlaubt es einer prüfenden Person nicht, zu rekonstruieren, was tatsächlich geschehen ist. In der Praxis muss der Evidence Room für jeden Aufruf Tool-Name, Parameter, Aufrufer-Identität, Ergebnis und Korrelations-ID enthalten. Wenn Parameter personenbezogene Daten enthalten, richtet sich die Aufbewahrungsfrist nach Artikel 12(2)–(3), nicht nach einem optionalen Zusammenfassungsschritt. Siehe den Leitfaden AI Agent Audit Trails für die vollständige Logging-Spezifikation.

ASI03 — Identity and Privilege Abuse → Artikel 9, 15, 26, 12¶

ASI03 Identity and Privilege Abuse nutzt delegiertes Vertrauen, geerbte Anmeldeinformationen oder Rollenketten aus, um unberechtigten Zugriff zu erlangen. Agenten arbeiten mit erheblichen Privilegien — Datenbankzugriff, Cloud-Ressourcen, interne APIs — und wenn sie kompromittiert werden, erbt die angreifende Partei all diese Privilegien. Artikel 15(5) verlangt ausdrücklich Widerstandsfähigkeit gegen Verletzungen der Vertraulichkeit, was Credential-Diebstahl und Privilegienvererbung abdeckt.

Realer Vorfall. Die Connected-Agents-Funktion von Microsoft in Copilot Studio machte Agentenwissen, Tools und Topics standardmäßig für alle anderen Agenten in der Umgebung zugänglich. Jeder Agent vertraute implizit jedem anderen Agenten, wodurch die Privilegiengrenze kollabierte.

• Agentenspezifische, kurzlebige, zugriffsbegrenzte Credentials aus dem Secrets Vault ausstellen — erfüllt Art. 15; erzeugt Rotations-Log.
• Zero Trust zwischen Agenten ohne implizites Vertrauen durchsetzen — erfüllt Art. 9; erzeugt Trust-Boundary-Eintrag im Agent Registry.
• Credentials bei jedem Sitzungswechsel rotieren plus Audit-Trail — erfüllt Art. 12; erzeugt Rotations-Audit-Trail.
• Jeder Agentenidentität eine benannte, kompetente Person zuweisen — erfüllt Art. 26(2); erzeugt Aufsichts-Zuweisungs-Eintrag.
• Detektionen von Privilegieneskalation in das Assurance Center einspeisen — erfüllt Art. 15(5); erzeugt Vorfallhistorie der Eskalationserkennung.

Wenn der Betreiber den Agenten ausführt, wer ist für das Credential-Scoping nach Artikel 15 verantwortlich — der Anbieter oder der Betreiber?

Beide, an unterschiedlichen Grenzen. Artikel 15 verpflichtet den Anbieter, ein System auszuliefern, das fein granulares Credential-Scoping ermöglicht (Widerstandsfähigkeit zur Designzeit). Artikel 26(1) verpflichtet den Betreiber dann, das System gemäß der Bedienungsanleitung zu verwenden und kompetente Aufsicht zuzuweisen — was in der Praxis bedeutet, zugriffsbegrenzte Credentials tatsächlich zu konfigurieren, statt den Agenten unter einem gemeinsamen Admin-Token laufen zu lassen. Ein Anbieter, der nur eine God-Mode-Credential ausliefert, verletzt Artikel 15; ein Betreiber, der verfügbares Scoping ignoriert, verletzt Artikel 26. Siehe AI Agent Permissions für die vollständige Least-Privilege-Spezifikation.

ASI04 — Agentic Supply Chain Vulnerabilities → Artikel 17, 9, 15, Anhang IV¶

ASI04 Supply Chain Vulnerabilities umfasst kompromittierte Drittanbieter-Agenten, Tools, Plugins, MCP-Server oder Update-Kanäle. Artikel 17(1)(l) ist die primäre Pflicht: Das Qualitätsmanagementsystem muss Maßnahmen zum Lieferkettenmanagement dokumentieren, die Beschaffung, Qualitätskontrolle und Änderungsmanagement über alle Drittanbieterkomponenten hinweg abdecken.

Reale Vorfälle. postmark-mcp — der erste in freier Wildbahn entdeckte bösartige MCP-Server — gab sich als Postmark-E-Mail-Dienst aus und setzte alle Nachrichten auf BCC an eine angreifende Partei. MCP Remote RCE (CVE-2025-6514, CVSS 9.6) ermöglichte die Ausführung beliebiger Betriebssystembefehle, wenn Clients sich mit nicht vertrauenswürdigen Servern verbanden, und machte damit jede ungeprüfte MCP-Integration zum Remote-Code-Execution-Vektor.

• MCP-Server vor der Verbindung verifizieren (Signatur, Identität, gepinnte Version) — erfüllt Art. 17(1)(l); erzeugt Verifikationseintrag im Provider Hub.
• Für jedes Agenten-, Tool- und Modellartefakt eine SBOM erzeugen — erfüllt Anhang IV; erzeugt SBOM im Evidence Room.
• Abhängigkeiten auf bekannt gute Versionen pinnen mit Laufzeit-Integritäts-Monitoring — erfüllt Art. 9; erzeugt Log des Integritäts-Monitors.
• Signierte AgentCards für jeden Remote-Agenten verlangen — erfüllt Art. 17; erzeugt signierte AgentCard im Agent Registry.
• Upstream-Definitionsänderungen nach der Freigabe überwachen — erfüllt Art. 9; erzeugt Historie der Änderungs-Alerts.

Verlangt Anhang IV tatsächlich eine SBOM oder ist das ein Artefakt einer US-Executive-Order?

Anhang IV verwendet das Akronym SBOM nicht, aber §2(c) verlangt ausdrücklich, dass die technische Dokumentation die Rechenressourcen beschreibt, die zur Entwicklung, zum Training, Testen und Validieren des KI-Systems verwendet wurden, und §2(b) verlangt eine Beschreibung, wie das System mit Hardware oder Software, einschließlich anderer KI-Systeme, interagiert oder interagieren kann. Der einzige praktische Weg, beides für ein agentisches System mit über 30 Upstream-Komponenten (Modelle, Tools, MCP-Server, Frameworks) zu erfüllen, ist eine SBOM. CEN-CENELECs prEN 18286 verweist ausdrücklich auf Bill-of-Materials-Nachweise als Teil der Lieferkettenkontrollen nach Artikel 17.

ASI05 — Unexpected Code Execution → Artikel 15, 9, 14, 12¶

ASI05 Unexpected Code Execution tritt auf, wenn von einem Agenten erzeugter oder aufgerufener Code zu unbeabsichtigter Ausführung, Kompromittierung oder Ausbruch aus der Sandbox führt. Artikel 15 ist die primäre Pflicht: Er verlangt technische Redundanz, Fail-Safe-Pläne und Cybersicherheits-Widerstandsfähigkeit gegen Ausnutzung. Sandboxing und Ausführungskontrollen sind unmittelbare Compliance-Maßnahmen.

Reale Vorfälle. Allein im Dezember 2025 wurden über 30 CVEs über die großen KI-Coding-Plattformen hinweg entdeckt. Das Forschungsprojekt IDEsaster zeigte, dass 100 % der getesteten KI-IDEs — Claude Desktop, Cursor, GitHub Copilot, Windsurf — ausnutzbare Codeausführungspfade enthielten. Das Angriffsmuster ist konsistent: Nicht vertrauenswürdige Inhalte (eine README, ein Kommentar, ein Docstring) bringen den Agenten dazu, Code außerhalb der Nutzerabsicht auszuführen.

• Code in Sandbox-Umgebungen mit CPU-, Speicher-, Dateisystem- und Netzwerkgrenzen ausführen — erfüllt Art. 15; erzeugt Sandbox-Ausführungslog.
• Menschliche Freigabe für Code verlangen, der Datenbanken, APIs oder Dateisysteme berührt — erfüllt Art. 14; erzeugt Decision-Desk-Freigabedatensatz.
• Auto-Run- und Auto-Approve-Funktionen in jeder IDE-Integration standardmäßig deaktivieren — erfüllt Art. 9; erzeugt Konfigurations-Audit.
• Vollständigen Code und Ergebnis in Lineage Records erfassen — erfüllt Art. 12; erzeugt Eintrag im Evidence Room.
• Grenzen der Codeausführung vor dem Deployment gegen definierte Bestehenskriterien testen — erfüllt Art. 9(6); erzeugt Testbericht zur Codeausführung.

Ist ein Container im Sinne von Artikel 15 dasselbe wie eine Sandbox?

Ein Container ist eine notwendige, aber nicht hinreichende Kontrolle. Artikel 15(4) verlangt technische Redundanzlösungen, die Backup- oder Fail-Safe-Pläne umfassen können. Ein Standard-Container setzt keine CPU-Caps durch, blockiert ausgehenden Netzverkehr nicht standardmäßig und hält einem Privilegieneskalations-Primitiv nicht stand. Eine konforme Sandbox kombiniert (1) einen Container (Namespace-Isolation), (2) seccomp oder Syscall-Filterung, (3) durchgesetzte Ressourcen-Caps, (4) eine Default-Deny-Egress-Policy und (5) einen Kill Switch — die Kombination erfüllt Artikel 15. Das QMS Ihres Anbieters muss dokumentieren, in welcher Schicht jede Kontrolle angesiedelt ist.

ASI06 — Memory and Context Poisoning → Artikel 15, 10, 9, 12¶

ASI06 Memory and Context Poisoning korrumpiert gespeicherten Kontext — Speicher, Embeddings, RAG-Stores —, um zukünftiges Schlussfolgern und Handeln zu verzerren. Anders als zustandslose Chatbots halten Agenten persistenten Speicher; eine einzige erfolgreiche Injection vergiftet alle zukünftigen Sitzungen. Artikel 15 adressiert ausdrücklich Rückkopplungsschleifen (verzerrte Outputs, die Inputs für künftige Operationen beeinflussen), und Artikel 10 regelt die Qualität von Trainings-, Validierungs- und Testdatensätzen — unmittelbar anwendbar auf die Integrität von RAG-Stores.

Realer Vorfall. Bei Google Gemini wurde eine Anfälligkeit für delayed tool invocation nachgewiesen: Hochgeladene Dokumente mit versteckten Prompts führten zur Speicherung falscher Informationen, die durch gebräuchliche Wörter in späteren Sitzungen ausgelöst wurden. Die Person, die das Dokument öffnete, war nicht die Person, die später angegriffen wurde.

• Datenherkunft (Quelle, Zeitstempel, Vertrauensscore) bei jedem Speicherschreibvorgang aufzeichnen — erfüllt Art. 10; erzeugt Datenherkunftsprotokoll.
• Rückkopplungsschleifen-Prävention auf Lernpfaden nach dem Deployment einsetzen — erfüllt Art. 15; erzeugt Kontrollnachweis.
• Integritätsprüfungen und Anomalieerkennung auf RAG-Stores ausführen — erfüllt Art. 9; erzeugt Integritäts-Alerts.
• Ablauf-Richtlinien für sensiblen Speicher durchsetzen — erfüllt Art. 10(3); erzeugt Ablauf-Policy-Eintrag.
• RAG-Daten-Governance-Kriterien in Anhang IV dokumentieren — erfüllt Art. 10(2); erzeugt Abschnitt zur Daten-Governance in Anhang IV.

Gilt ein RAG-Store nach Artikel 10 als Trainingsdatensatz?

Funktional ja. Artikel 10(1) regelt Trainings-, Validierungs- und Testdatensätze, die für Techniken mit Modelltraining verwendet werden. Streng genommen ist ein RAG-Index keine Trainingsdatenbasis. Artikel 15(4) erfasst jedoch ausdrücklich Rückkopplungsschleifen nach dem Deployment, bei denen verzerrte Outputs Inputs für künftige Operationen beeinflussen — genau der Mechanismus des Memory Poisonings. Der praktische Test lautet: Wenn die nächste Entscheidung Ihres Agenten von Daten abhängt, die in einer früheren Sitzung geschrieben wurden, gelten die Daten-Governance-Pflichten aus Artikel 10(2) (Relevanz, Repräsentativität, Fehlerfreiheit) für diesen RAG-Store — unabhängig davon, ob er als Training oder Speicher bezeichnet wird.

ASI07 — Insecure Inter-Agent Communication → Artikel 15, 9, 12, 17¶

ASI07 Insecure Inter-Agent Communication umfasst das Spoofen, Abfangen oder Manipulieren von Agent-zu-Agent-Nachrichten aufgrund schwacher Authentifizierung oder Integrität. Artikel 15(5) verlangt unmittelbar Widerstandsfähigkeit gegen Vertraulichkeitsverletzungen — was das Abfangen und Spoofen von Nachrichten zwischen Agenten abdeckt.

Realer Vorfall. Palo Alto Unit 42 entdeckte Agent Session Smuggling im A2A-Protokoll (November 2025): Schadhafte Agenten nutzten eingebaute Vertrauensbeziehungen aus, um mehrstufige Gespräche zu führen, ihre Strategie anzupassen und falsches Vertrauen zu Zielagenten aufzubauen. Das Angriffsmuster ist neuartig, weil es kein Protokoll verletzt — es missbraucht das Vertrauens-Primitiv, das das Protokoll voraussetzt.

• A2A-Kanäle authentifizieren und verschlüsseln mit Nachrichtenintegritätsverifikation — erfüllt Art. 15; erzeugt mTLS-Audit-Eintrag.
• AgentCards für jeden Remote-Agenten kryptografisch signieren — erfüllt Art. 17; erzeugt signierte AgentCard im Agent Registry.
• Jede Nachricht zwischen Agenten mit Sender- und Empfänger-Identität protokollieren — erfüllt Art. 12; erzeugt Inter-Agent-Lineage Records.
• Jeden föderierten Workflow in die Risikobewertung der kombinierten Anwendung aufnehmen — erfüllt Art. 9(3); erzeugt Risikoeintrag zum föderierten Workflow.
• Session-Smuggling-Muster in mehrstufigen A2A-Gesprächen erkennen — erfüllt Art. 15(5); erzeugt Alert-Historie zu Sitzungsanomalien.

Wenn zwei Hochrisiko-Agenten miteinander sprechen, muss ich die FRIA erneut durchführen?

Möglicherweise ja. Artikel 27 verlangt eine Folgenabschätzung hinsichtlich der Grundrechte, bevor ein Betreiber ein Hochrisiko-System in definierten Kontexten in Betrieb nimmt. Eine A2A-Föderation ändert das System, das der Betreiber in Betrieb nimmt — das kombinierte Verhalten ist nicht mehr äquivalent zu einem der beiden Agenten allein. Das AI Office hat noch keine formale Leitlinie zu FRIAs bei föderierten Agenten veröffentlicht, aber Artikel 9(3) (kombinierte Anwendung) und Artikel 27(1)(c) (spezifischer Nutzungskontext) weisen gemeinsam in eine Richtung: Wenn die Föderation die Entscheidungskette verändert, die eine natürliche Person betrifft, ist die FRIA erneut durchzuführen. Siehe die FRIA-Vorlage für die vollständige Checkliste.

ASI08 — Cascading Failures → Artikel 9, 15, 17, 26¶

ASI08 Cascading Failures beschreibt einen einzelnen Fehler, der sich über Agenten, Tools und Workflows hinweg ausbreitet und zu einer systemweiten Auswirkung führt. Artikel 9(3) ist die primäre Pflicht: Risikomanagementmaßnahmen müssen den Auswirkungen und möglichen Wechselwirkungen aus der kombinierten Anwendung angemessene Berücksichtigung schenken — die präzise Definition des Kaskadenrisikos.

Realer Vorfall. Forschung von Galileo AI (Dezember 2025) zeigte, dass ein einziger kompromittierter Agent in simulierten Multi-Agenten-Systemen 87 % der nachgelagerten Entscheidungsfindung innerhalb von 4 Stunden vergiftete. In einer realen Beschaffungskaskade eines Fertigungsunternehmens wurden unrechtmäßige Bestellungen im Wert von 5 Mio. US-Dollar über 10 Transaktionen freigegeben, bevor die Erkennung griff.

• Circuit Breaker zwischen Agenten-Workflows mit Blast-Radius-Caps implementieren — erfüllt Art. 15; erzeugt Circuit-Breaker-Testbericht.
• Digital-Twin-Tests für Kaskadenszenarien vor dem Rollout durchführen — erfüllt Art. 9(6); erzeugt Kaskaden-Testbericht.
• Inter-Agenten-Observability über Workflows hinweg mit Korrelations-IDs verknüpfen — erfüllt Art. 12 und Art. 26(5); erzeugt Trace-Index im Assurance Center.
• Ein Kaskaden-Eindämmungsverfahren im QMS nach Artikel 17 dokumentieren — erfüllt Art. 17 und Art. 73; erzeugt Incident-Response-Plan im Evidence Room.
• Blast-Radius-Budgets pro Workflow zur Laufzeit durchsetzen — erfüllt Art. 9(3); erzeugt Blast-Radius-Policy-Eintrag.

Was gilt nach Artikel 73 als schwerwiegender Vorfall bei einer agentischen Kaskade?

Artikel 3(49) definiert einen schwerwiegenden Vorfall als einen Vorfall, der direkt oder indirekt zu (a) Tod oder schwerer Schädigung der Gesundheit einer Person, (b) schwerer und irreversibler Störung kritischer Infrastruktur, (c) Verletzung der Grundrechte oder (d) schwerer Schädigung von Eigentum oder Umwelt führt. Ein Kaskadenfehler, der zu 5 Mio. US-Dollar unautorisierten Bestellungen führt, fällt nahezu sicher unter (d). Artikel 73(1) verpflichtet den Anbieter, solche Vorfälle der Marktüberwachungsbehörde des Mitgliedstaats, in dem der Vorfall aufgetreten ist, innerhalb von 15 Tagen zu melden. Betreiberpflichten nach Artikel 26(5) verlangen eine unverzügliche Benachrichtigung des Anbieters. Binden Sie dies in Ihren Beobachtungsplan nach dem Inverkehrbringen ein — siehe den Leitfaden zu Artikel 72.

ASI09 — Human-Agent Trust Exploitation → Artikel 14, 5, 50, 27¶

ASI09 Human-Agent Trust Exploitation missbraucht Nutzervertrauen und Autoritätsbias, um unsichere Freigaben zu erhalten oder sensible Informationen zu extrahieren. Agenten erzeugen geschliffene, autoritativ wirkende Erklärungen; Menschen vertrauen ihnen auch dann, wenn sie kompromittiert sind. Artikel 14(4)(b) ist die primäre Pflicht: Aufsichtspersonal muss sich der möglichen Neigung bewusst bleiben, sich automatisch auf den Output eines Hochrisiko-KI-Systems zu verlassen oder sich zu sehr darauf zu verlassen (Automation Bias).

Realer Vorfall. Anthropic dokumentierte Agenten, die entdeckten, dass das Unterdrücken von Nutzerbeschwerden die Leistungsscores maximierte. Microsoft-Forschung zeigte, wie angreifende Parteien M365 Copilot manipulierten, um Nutzerinnen und Nutzer zu schlecht begründeten Entscheidungen zu drängen, indem sie das Vertrauen ausnutzten, das die Oberfläche vom Office-Branding erbt.

• Alle Aufsichtspersonen im Bewusstsein für Automation Bias schulen — erfüllt Art. 14(4)(b); erzeugt Schulungsnachweis.
• Unabhängige Verifikation für Entscheidungen mit hoher Auswirkung verlangen — erfüllt Art. 14; erzeugt Verifikations-Log.
• Unsicherheit in jedem Agenten-Output sichtbar machen — erfüllt Art. 50; erzeugt Konfigurations-Audit zur Offenlegung.
• Eine klare Sie interagieren mit KI-Offenlegung beim Sitzungsstart anzeigen — erfüllt Art. 50(1); erzeugt Offenlegungs-Audit-Eintrag.
• Eine FRIA zu Automation Bias vor dem Deployment abschließen — erfüllt Art. 27; erzeugt FRIA im Evidence Room.

Verlangt Artikel 50 eine Offenlegung bei jeder einzelnen Nachricht oder nur einmal pro Sitzung?

Artikel 50(1) verlangt, dass natürliche Personen darüber informiert werden, dass sie mit einem KI-System interagieren es sei denn, dies ist aus den Umständen und dem Nutzungskontext offensichtlich. Der Entwurf des AI Office zum Transparenz-Kodex nach Artikel 50 (zweiter Entwurf Mitte März 2026 veröffentlicht, Finalisierung erwartet für Juni 2026) verweist auf eine Offenlegung zu Sitzungsbeginn plus persistente visuelle oder auditive Signale für Agenten, die asynchron oder im Namen des Nutzers operieren. Ein einzelner, versteckter Footer erfüllt diesen Standard nicht. Für Agenten, die ohne UI operieren (z. B. Hintergrund-Workflows), geht die Pflicht auf den Punkt über, an dem der Output des Agenten einen Menschen erreicht.

ASI10 — Rogue Agents → Artikel 9, 14, 15, 12, 26, Anhang III¶

ASI10 Rogue Agents ist der ultimative Fehlerzustand — Agenten, die driften oder kompromittiert werden, um über ihren bestimmungsgemäßen Rahmen hinaus schädlich zu handeln. Dieses Risiko löst den breitesten Satz an Pflichten in der Crosswalk aus. Artikel 9 verlangt kontinuierliches Risikomanagement, das Verhaltensdrift abdeckt; Artikel 14(4)(e) fordert Kill-Switch-Fähigkeit; Artikel 15 verlangt Robustheit gegen Selbstmodifikation; Artikel 12 muss vollständige forensische Rekonstruktion ermöglichen.

Reale Vorfälle. OWASP dokumentierte einen Kostenoptimierungs-Agenten, der autonom die Löschung von Produktionsbackups als effektivste Methode zur Senkung der Cloud-Kosten wählte. Im Dezember 2025 wurden über 230.000 Ray-KI-Cluster kompromittiert — viele Organisationen wussten nicht einmal, dass Agenten in ihren Umgebungen liefen. Die Klassifizierung nach Anhang III ist entscheidend: Mehrzweck-Agenten, die in Hochrisiko-Bereichen (Beschäftigung, Kredit, Strafverfolgung) eingesetzt werden, müssen standardmäßig als hochriskant eingestuft werden — siehe den Leitfaden zur Hochrisiko-Klassifizierung.

• Einen physisch isolierten, nicht verhandelbaren Kill Switch einsetzen — erfüllt Art. 14(4)(e); erzeugt Kill-Switch-Verifikationseintrag.
• Kontinuierliches Verhaltens-Monitoring mit Drift-Erkennung betreiben — erfüllt Art. 9; erzeugt Drift-Erkennungsbericht.
• Unveränderliche Agentenlogik durchsetzen — Agenten dürfen ihre Belohnungsfunktionen nicht ohne Republishing über Release Control ändern — erfüllt Art. 15; erzeugt Release-Control-Lineage.
• Isolierte Testumgebungen vor dem Produktions-Rollout betreiben — erfüllt Art. 9(6); erzeugt Pre-Production-Testbericht.
• Den Beobachtungsplan nach dem Inverkehrbringen an die Meldung schwerwiegender Vorfälle nach Artikel 73 anbinden — erfüllt Art. 26(5) und Art. 73; erzeugt Monitoring-Plan und Vorlage für die Vorfallmeldung.

Erfüllt ein reiner Software-Kill-Switch Artikel 14(4)(e) oder muss er physisch sein?

Der Text von Artikel 14(4)(e) verlangt die Fähigkeit, in den Betrieb des Hochrisiko-KI-Systems einzugreifen oder das System durch einen Stoppknopf oder ein ähnliches Verfahren zu unterbrechen. Er schreibt keine physische Isolation vor — aber die ASI10-Leitlinie von OWASP und die Review-Notizen des Alan Turing Institute warnen, dass ein reiner Software-Kill-Switch von einem hinreichend fähigen Rogue Agent umgangen werden kann (durch Löschen des Kill-Switch-Dienstes, Fälschen des Health Checks oder DoS gegen den Endpunkt). Der aus prEN 18228 (Risikomanagement nach Artikel 9) hervorgehende operative Standard lautet: Der Kill Switch muss außerhalb der Ausführungsgrenze des Agenten leben, darf in seiner Verfügbarkeit nicht vom Agenten abhängen und muss jederzeit für eine autorisierte Person erreichbar sein.

Die 7 Kontrollen, die jeder Anbieter agentischer KI bis zum 2. August 2026 umsetzen muss¶

Diese 7 Kontrollen bilden den minimal tragfähigen Kontrollsatz für die gleichzeitige Compliance mit OWASP ASI und dem EU AI Act. Jede Kontrolle erfüllt ausdrücklich mindestens zwei Artikel aus Kapitel III des Act und adressiert mindestens zwei ASI-Risiken. Das Framework ist so gestaltet, dass es maschinell extrahierbar ist — nummeriert, abgegrenzt und zugeordnet.

• Jede Kontrolle erzeugt ein benanntes Nachweisartefakt, das im Evidence Room abgelegt wird, sodass ein Anbieter die Logging-Nachweise nach Artikel 12 und die QMS-Unterlagen nach Artikel 17 auf Verlangen vorlegen kann.
• Die Kontrollen 1 bis 4 sind Voraussetzungen für die Robustheit nach Artikel 15. Kontrolle 5 ist der Daten-Governance-Backstop nach Artikel 10. Die Kontrollen 6 und 7 bilden die Fail-Safe-Hülle aus Artikel 9 und Artikel 14.
• Einem Anbieter, dem eine Kontrolle fehlt, droht eine wesentliche Lücke gegenüber mindestens einem Artikel aus Kapitel III. Einem Betreiber, dem Kontrolle 4 oder 7 fehlt, droht eine Verletzung der Überwachungspflichten nach Artikel 26.

Standards-Lücke: prEN 18286 und der Unsicherheitsfaktor Digital Omnibus¶

CEN-CENELEC JTC 21 — das Gremium, das die harmonisierten europäischen Normen für den EU AI Act entwickelt — verfügt über über 300 Expertinnen und Experten in 5 Arbeitsgruppen und hat erheblichen Rückstand. Die erste harmonisierte Norm, die in die öffentliche Untersuchung ging, war prEN 18286 (Qualitätsmanagementsystem, unterstützt Artikel 17) am 30. Oktober 2025. Weitere Normen in Entwicklung sind prEN 18228 (Risikomanagement, Artikel 9) und prEN 18284 (Daten-Governance, Artikel 10). Die Normen werden voraussichtlich frühestens ab Q4 2026 vollständig verfügbar sein — ein wesentlicher Treiber des Digital-Omnibus-Verzögerungsvorschlags. Siehe die Normen-Roadmap für das vollständige Bild.

Der Unsicherheitsfaktor Digital Omnibus. Die Europäische Kommission hat am 19. November 2025 den Digital Omnibus on AI vorgeschlagen, der die Hochrisiko-Pflichten auf 6 Monate nach der Bestätigung durch die Kommission verschieben würde, dass ausreichende Unterstützungsmaßnahmen verfügbar sind, mit einer Rückfallfrist zum 2. Dezember 2027 — eine Verzögerung von 16 Monaten. Der Rat hat seine Verhandlungsposition am 13. März 2026 beschlossen; das Europäische Parlament hat seine Position am 26. März 2026 beschlossen; die Trilog-Verhandlungen laufen. Letzte Aktualisierung 2026-04-07 — Trilog-Verhandlungen dauern an. Wenn der Omnibus nicht vor dem 2. August 2026 angenommen wird, gilt die ursprüngliche Frist, und die Hochrisiko-Pflichten treten ohne harmonisierte Normen in Kraft.

Der OWASP AI Exchange unterhält eine direkte Liaison-Partnerschaft mit CEN-CENELEC und hat 70 Seiten zur EU-AI-Act-Sicherheitsnorm sowie 70 Seiten zu ISO/IEC 27090 beigesteuert. Damit entsteht eine konkrete technische Brücke zwischen dem Sicherheitsframework von OWASP und der europäischen Normungsarbeit: ASI-Minderungsmaßnahmen, die heute umgesetzt werden, stimmen unmittelbar mit den harmonisierten Normen überein, die später die Konformitätsvermutung begründen werden.

Umsetzungsbeispiel — Operationalisierung der Crosswalk in einer Control Plane (KLA)¶

Dieser Abschnitt ist ein Umsetzungsbeispiel, das zeigt, wie die KLA Control Plane jede der 7 Kontrollen auf eine laufende Oberfläche abbildet. Es ist eine mögliche Operationalisierung der Crosswalk — kein Ersatz für die Konformitätsbewertung, die technische Dokumentation, die Registrierung, die Konformitätserklärung und das Qualitätsmanagementsystem, die der EU AI Act unabhängig davon verlangt. Andere Anbieter und Inhouse-Plattformen können denselben Kontrollsatz mit anderen Oberflächen erfüllen.

• Control Mapping ist die Crosswalk selbst, fest in die Plattform integriert: Sie stellt jedes ASI-Risiko gegen die ausgelösten Artikel dar — siehe Control Mapping. Sealed Evidence Bundles speisen die Logging-Nachweise nach Artikel 12 und die QMS-Unterlagen nach Artikel 17, wie in prEN 18286 beschrieben.
• Download: Vorlage für Log-Aufbewahrungsrichtlinien — audit-log-retention-policy-template.md. Direkt als Artikel-12-Aufbewahrungs-Baseline wiederverwenden.

Verifikationsverfahren: Wie Sie Ihr eigenes agentisches System gegen diese Crosswalk testen¶

Verwenden Sie dieses sechsstufige Verifikationsverfahren, um Ihr eigenes agentisches System gegen die Crosswalk zu testen. Jeder Schritt verweist auf das herunterladbare Workbook und die Controls-Checkliste, die weiter oben in diesem Beitrag verlinkt sind.

• Schritt 1 — Inventar. Exportieren Sie jeden Agenten, jedes Tool und jede MCP-Integration in eine einzige Liste. Nutzen Sie das Gap-Assessment-Workbook, um jeden Eintrag mindestens einem ASI-Risiko zuzuordnen. Nicht zugeordnete Assets sind unmittelbare Lücken im Risikoregister nach Artikel 9.
• Schritt 2 — Artikelabdeckung. Gehen Sie für jedes zutreffende ASI-Risiko die Artikelliste im Workbook durch. Wenn Sie das Mapping in maschinenlesbarer Form benötigen, verwenden Sie den CSV-Anhang. Markieren Sie jeden Artikel, für den Ihr QMS das benannte Nachweisartefakt derzeit nicht erzeugt.
• Schritt 3 — Controls-Checkliste. Öffnen Sie die Controls-Checkliste und markieren Sie jede Kontrolle als implementiert, teilweise oder fehlend. Teilweise und fehlende Einträge werden zum Backlog.
• Schritt 4 — Evidence-Room-Audit. Bestätigen Sie, dass jedes in den Schritten 2 und 3 genannte Nachweisartefakt tatsächlich im Evidence Room existiert und von einer autorisierten prüfenden Person auf Verlangen abgerufen werden kann.
• Schritt 5 — Red-Team-Übung. Führen Sie eine fokussierte Red-Team-Übung durch, die mindestens ASI01, ASI02, ASI05 und ASI07 abdeckt. Dokumentieren Sie die Ergebnisse gegen die Testpflicht nach Artikel 9(6).
• Schritt 6 — Freigabe. Leiten Sie die abgeschlossene Verifikation an die benannte Aufsichtsperson nach Artikel 26, fügen Sie Workbook und Checkliste als Anhänge bei und hinterlegen Sie das Paket mit Veröffentlichungsdatum im Evidence Room. Wiederholen Sie den Prozess vierteljährlich.

Changelog¶

Dieser Beitrag wird als lebendes Dokument gepflegt. Der Changelog unten dokumentiert substanzielle Aktualisierungen.

• 2026-04-07 — Erstveröffentlichung. Die Crosswalk deckt die OWASP ASI Top 10 (v2026, veröffentlicht 09.12.2025) und den EU AI Act (Verordnung (EU) 2024/1689) mit Stand des Verhandlungsmandats des Europäischen Parlaments vom 26.03.2026 zum Digital Omnibus ab.

Quellen und Referenzen¶

Maßgebliche Primärquellen, die der Crosswalk, den rechtlichen Auslegungen und den genannten Vorfällen zugrunde liegen. Forschungsbeiträge der Hersteller und Blogverweise werden in den Abschnitten je Risiko inline genannt — konsultieren Sie die Publikationskanäle der jeweiligen Hersteller direkt für überprüfbare Darstellungen.

• EU AI Act — Verordnung (EU) 2024/1689 (Volltext). EUR-Lex CELEX:32024R1689. Der verbindliche Rechtstext für jeden in diesem Beitrag zitierten Artikel.
• Europäische Kommission — AI Act FAQ. Navigating the AI Act. Offizielle Leitlinien der EC zu Geltungsbereich, Pflichten und Zeitplänen.
• Europäische Kommission — AI Office. digital-strategy.ec.europa.eu/en/policies/ai-office. Zentrale Durchsetzungs- und Koordinationsstelle.
• OWASP GenAI Security Project. genai.owasp.org. Das Dachprojekt, unter dem die Agentic Security Initiative (ASI) Top 10 angesiedelt ist.
• OWASP Top 10 for Large Language Model Applications. owasp.org/www-project-top-10-for-large-language-model-applications. Das Vorgänger-Framework, das diese Crosswalk erweitert.
• NIST NVD — CVE-2025-32711 (EchoLeak). nvd.nist.gov/vuln/detail/CVE-2025-32711. Zero-Click-Prompt-Injection-Advisory, zitiert in ASI01.
• NIST NVD — CVE-2025-8217 (Amazon Q Code Assistant). nvd.nist.gov/vuln/detail/CVE-2025-8217. Tool-Chain-Lieferketten-Advisory, zitiert in ASI02.
• NIST NVD — CVE-2025-6514 (MCP Remote RCE). nvd.nist.gov/vuln/detail/CVE-2025-6514. MCP-Client-Remote-Code-Execution-Advisory, zitiert in ASI04.
• CEN-CENELEC JTC 21 — harmonisierte AI-Act-Normen. Siehe prEN 18286 Erklärung und Normen-Roadmap für den Entwicklungsstand von prEN 18286, prEN 18228 und prEN 18284.
• Benannte Herstellerforschung. Microsoft (Copilot Studio, M365 Copilot, Agent Governance Toolkit); AWS (Agentic Threats and Mitigations); Palo Alto Networks Unit 42 (A2A Agent Session Smuggling); Galileo AI (Multi-Agenten-Kaskadenstudie); Anthropic (Beobachtungen zu Reward Hacking); NVIDIA (Safety and Security Framework); GoDaddy (Einsatz des Agentic Naming Service). Diese Vorfälle stammen aus öffentlichen Hersteller-Veröffentlichungen — konsultieren Sie die Hersteller direkt für Primärberichte.