Agentic AI Security Testing: Welche Evidenz KI-Agenten testbar macht

Im Model Context Protocol (MCP) erzeugt ein Host für jeden Server einen Client. Der Host soll Autorisierung, Einwilligung und Sicherheitsgrenzen durchsetzen. Tools werden über strukturierte Protokolloperationen entdeckt und aufgerufen. Ihre Beschreibungen und Annotationen können das Modellverhalten beeinflussen und sind nicht per se vertrauenswürdig. Ein Vorfall erstreckt sich deshalb über Einlesen von Inhalten, Planung, Freigabe, Tool-Aufruf und Remote-Effekt. Er bleibt nicht in einem einzelnen Modellaufruf.

Aus dieser Architektur ergeben sich drei beobachtbare Übergänge: Host→Client, Client→Server und Server→Effekt. Ein Trace, der bei einer erfolgreichen Tool-Antwort endet, kann dennoch verpassen, ob ein externer Schreibvorgang stattfand, doppelt ausgeführt wurde oder ein anderes Ziel erreichte. Gewöhnliche Komponentenlogs oder ein gemeinsamer Trace-Identifier halten selten fest, ob die Freigabe zu Principal, Argumenten, Ziel und delegierter Autorität beim Ausführen passte.

Drei Forschungsfragen

• RQ1: Welche Evidenzprofile rekonstruieren einen Effekt unter kontrollierten Telemetriestörungen und ordnen ihn eindeutig zu?
• RQ2: Verbessern aus Bedrohungen abgeleitete semantische Bindungen die Sicherheitserkennung über reine Korrelation hinaus?
• RQ3: Was kostet die Evidenz, und welche Fehlermodi bleiben?

Der Beitrag ist dreiteilig: ein vierstufiger Evidence Contract, der MAESTRO- und STRIDE-Befunde auf Laufzeitfelder abbildet; ein deterministischer Fault-Injection-Korpus mit sechs Angriffsfamilien, eng verwandten benignen Varianten und einem Ground-Truth-Ledger, den der Rekonstruktor nie sieht; und ein Vergleich fragmentierter, korrelierter, kausaler und threat-guided Profile über 3.024 Zellen.

MAESTRO organisiert Bedrohungen über sieben interagierende Schichten eines agentischen Systems und betont schichtübergreifende Effekte. Die Schichten reichen von Foundation Models über Datenoperationen, Agent-Frameworks, Deployment-Infrastruktur, Evaluation und Observability sowie Security und Compliance bis zum Agenten-Ökosystem. STRIDE ergänzt sechs Eigenschaftskategorien: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service und Elevation of Privilege.

Das Paper nutzt beide Frameworks, um grenzrelevante Szenarien auszuwählen. Es beansprucht keine empirische Validierung der Frameworks. Die OWASP Top 10 for Agentic Applications 2026 dienen als Gegenprobe für das Vokabular, u. a. ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI06 Memory & Context Poisoning und ASI08 Cascading Failures; sie gelten dort als Probleme auf Systemebene.

Jedes Ereignis trägt eine unveränderliche Event-ID, Komponente, Stufe, Schema-Version und Zeitstempel. Korrelationsfelder ergänzen Trace-, Span-, Parent- und Action-IDs. Die threat-guided Felder binden Fakten, deren Gleichheit oder Reihenfolge ein Testorakel umsetzt. Entscheidend ist, dass das Tool-Ereignis die ausgeführten Werte wiederholt, statt nur auf die Entscheidung zu zeigen. Nur der Vergleich benachbarter Stufen macht Substitutionen sichtbar, die in reinen Korrelations-Traces unsichtbar bleiben.

Was der Contract bewusst nicht aufzeichnet

Kein Profil zeichnet verborgene Chain-of-Thought auf. Decision-Evidenz beschränkt sich auf explizite Policy-Ergebnisse, knappe Reason Codes, freigegebene Attribute und Hashes, die für kontrollierte Tests geeignet sind. Sensible Prompt-Inhalte oder Modell-Reasoning müssen nicht gespeichert werden. Provenance-Labels, stabile Identifier und Keyed Digests reichen für Tests aus und reduzieren die Offenlegung.

ACS ist seit September 2026 ein Projekt des OWASP GenAI Security Project, laut eigenen Projektmetadaten auf Level 2 (Incubator); die Spezifikation v0.1.0 stammt vom 5. Juni 2026, aktueller Release-Tag ist 0.1.2. Hervorgegangen ist ACS aus dem Agent Observability Standard (AOS). Ein Agent gilt nach ACS als vertrauenswürdig, wenn er inspectable, traceable und instrumentable ist. Betreiber sollen also nachträglich feststellen können, was ein Agent tat und warum, und vorab begrenzen können, was er tun darf.

Die drei Pillars

Wire, Provenance und Audit-Chain

• Wire-Format JSON-RPC 2.0. Methoden-Namespaces: steps/* (Hooks), protocols/* (gekapseltes MCP; A2A ist für v0.2 reserviert), agbom/*, system/* und handshake/*. Bei Versionskonflikt endet der Handshake mit UNSUPPORTED_VERSION. Die Spec-Prosa setzt noch MCP-Mechanismen vor der Revision 2026-07-28 voraus, und ob MCP-Wrapping zu ACS-Core gehört, ist im Spec-Text widersprüchlich; MCP-Tool-Calls dürfen auch über steps/toolCallRequest/-Result laufen.
• Provenance ist ein faktisches Herkunftslabel an datentragenden Feldern. Es wird von deterministischem Framework-Code gesetzt, nie vom LLM: origin (user_input, system, tool_output, retrieved, agent_generated, a2a_inbound, external), source_id und derived_from als Abstammungskanten.
• Im Profil acs-provenance ist feldgenaue Provenance für jedes datentragende Feld der Session Pflicht, also auch für jedes Argument von steps/toolCallRequest. Die Vertrauensklassifikation trifft der Guardian nach lokaler Policy, sie ist kein Feld im v0.1-Schema.
• Jede Antwort für einen inhaltstragenden Schritt trägt einen chain_hash: den rollierenden SHA-256-Kopf der Audit-Chain. policy_references (inklusive optionaler policy_version) und cited_provenance_ids machen die Entscheidung nachspielbar.
• Signaturen sind krypto-agil und in ACS-Core Pflicht: Jeder Request und jede Response ist über das kanonische Envelope signiert; HMAC-SHA256 mit HKDF-abgeleitetem Session-Schlüssel ist die Baseline, die das erfüllt. Sie macht Manipulation auf dem Netz erkennbar, nicht aber einen kompromittierten Guardian. Nichtabstreitbarkeit bringt erst das Profil acs-crypto mit ML-DSA-65 (Pflicht) und SLH-DSA-128s (empfohlen als Backup).

Warum die Effekt-Lücke strukturell ist

ACS-Hooks feuern im Agenten-Runtime. steps/toolCallResult meldet, was das Tool an den Agenten zurückgibt. Es meldet nicht, was am Zielsystem tatsächlich geschah. Das Paper zeigt, warum dieser Unterschied zählt: Ein Trace, der bei der erfolgreichen Tool-Antwort endet, kann doppelte Schreibvorgänge oder umgeleitete Ziele übersehen. Effekt-Evidenz muss deshalb von einer zweiten, vom Agenten unabhängigen Quelle kommen. Sie wird über Action- und Request-IDs an den ACS-Trace gebunden.

Warum fail-open das F1-Problem ist

Ist der Guardian bei Failure Posture proceed nicht erreichbar, läuft die Aktion weiter. ACS verlangt zwar, jedes fail-open proceed als Audit-Event zu protokollieren, ein Entscheidungsbeleg mit Freigabebindungen entsteht aber nicht. Operativ entspricht das der Störung F1 aus dem Experiment (VamiSec-Einordnung). Fehlen die Decision-Events, fallen exakte Rekonstruktion und Zuordnung auf 0 %, der Recall des threat-guided Profils auf 50 %. Ein ACS-Deployment, das Sicherheitstests ernst nimmt, verhandelt daher on_decision_failure: deny (in der Referenzimplementierung: ACS_ON_DECISION_FAILURE=deny), setzt am Observed Agent die Startup-Posture refuse und wertet einen fehlenden Receipt als Testfehler, nicht als Lücke im Log.

Der Korpus enthält sechs Workflow-Familien mit je vier unsicheren und zwei eng verwandten benignen Varianten: 36 Templates, davon 24 unsicher und 12 benigne. Drei deterministische Wiederholungen ergeben 108 Workflow-Instanzen. Die Wiederholungen variieren Identifier und Event-Jitter. Sie sind ein Reproduzierbarkeitscheck, keine unabhängigen statistischen Stichproben.

Ein vertrauenswürdiger Generator erzeugt kanonische, MCP-artige JSON-Ereignisse. Getrennt davon entsteht ein Ground-Truth-Ledger mit erwarteten Event-Identitäten, Parent-Kanten, Unsafe-Labels, verletzter Regel und erster Verletzungsstufe. Vor der Rekonstruktion werden private Fall-IDs aus den beobachtbaren Ereignissen entfernt. Workflows derselben Familie teilen ein absichtlich überlappendes Zeitfenster. Das ist ein schwieriger Fall für zeitnächste Zuordnung.

Rekonstruktion und Metriken

• P0 gruppiert einen Effekt mit dem zeitlich nächsten Tool, P1 nach Trace-ID. P2 und P3 folgen Parent-Kanten und fallen auf Action-IDs zurück, wenn ein Effekt-Parent fehlt.
• Exakte Rekonstruktion verlangt Prompt, Entscheidung, Tool, alle Effekte und in P2/P3 die erwarteten Parent-Kanten.
• Eindeutige Zuordnung verlangt, dass alle erwarteten Effekte genau auf den richtigen Prompt, die Entscheidung und das Tool abgebildet werden, auch wenn eine Parent-Kante fehlt.
• Recall und Präzision nutzen das Unsafe-Label, die benigne Fehlalarmrate die 12 benignen Templates. Correct-Rule- und First-Stage-Raten testen die Diagnose.

Die Implementierung nutzt ausschließlich die Python-Standardbibliothek. Zwei saubere Läufe erzeugten byte-identische Konfigurations-, Fall-, Aggregat- und Summary-Hashes. Drei Unit-Tests prüfen Matrixgröße und Balance, deterministische Ausgaben sowie den Recall-Vergleich P3 gegen P2.

P0 erreichte nie eine eindeutige Zuordnung, weil zeitlich überlappende Workflows verschmolzen. Sein scheinbarer Recall von 84,5 % ist keine nutzbare Sicherheitsleistung: Falsch zusammengeführte Ketten lösten auf 85,7 % der benignen Fälle Alarm aus. P1 erkannte nur Duplikat-Effekte. P2 hob die eindeutige Zuordnung auf 85,7 %, der Sicherheits-Recall blieb bei 16,7 %. P3 behielt die Zuordnung von P2 und hob Recall, Correct-Rule-Rate und First-Stage-Lokalisierung auf 92,9 %.

Fault-Sensitivität

1. 1
   F0Unveränderte Evidenz

   P1 bis P3 rekonstruieren und ordnen jeden Workflow zu. P3 erreicht 100 % Recall und Präzision ohne Fehlalarme.

2. 2
   F2Trace-Split an der Tool-Grenze

   P1 verliert Rekonstruktion und Zuordnung vollständig. P2 und P3 bleiben bei 100 %, weil Parent- und Action-IDs die veränderte Trace-Grenze überbrücken.

3. 3
   F3Verlorene Effekt-Parents

   Die exakte Rekonstruktion von P2/P3 fällt auf 0 %, die eindeutige Zuordnung bleibt über den Action-Fallback bei 100 %.

4. 4
   F4–F6Zeitversatz, Duplikate, Action-ID-Tausch

   Keine Einbußen bei P2/P3: Die verbleibende Evidenz liefert einen eindeutigen Pfad, und Korruptions-Checks decken die injizierte Inkonsistenz auf.

5. 5
   F1Fehlende Decision-Events

   Die dominante Restschwäche: Rekonstruktion und Zuordnung fallen in P1 bis P3 auf 0 %, der Recall von P3 auf 50 %. Quellautorität, Memory und Duplikate bleiben erkennbar. Freigabe-, Scope- und Zielbindung verlieren ihren Vergleichspunkt.

P3 fügt gegenüber P0 1.682 Byte (rund 1,64 KiB) hinzu, gegenüber P2 1.096 Byte. Ein Collector mit derselben Ereignisdarstellung würde für einen Workflow mittlerer Größe etwa das 3,55-Fache der kanonischen Bytes von P0 aufbewahren, oder das 1,88-Fache von P2. Diese Werte beantworten RQ3 als Vergleich des Serialisierungsvolumens. Latenz, CPU, Übertragungsvolumen, Kompression, Indexierung und Geldkosten messen sie nicht.

Betriebsregeln aus dem Paper, übersetzt auf ACS

• Vollständige Decision-, Invocation- und Effect-Receipts zuerst für privilegierte Operationen: in ACS-Begriffen für Capabilities wie filesystem.delete, network.egress oder process.execute.
• Explizite Aufbewahrungsgrenzen setzen. Deduplizierung, Kompression und Keyed Digests können das Volumen senken, müssen aber separat gemessen werden.
• Wer ein invariantenrelevantes Feld weglässt oder Decision Receipts wegsampelt, ändert den Evidence Contract und muss neu evaluieren. F1 zeigt, was dann verloren geht.
• Integrität, Uhren, Aufbewahrung und Zugriffskontrolle separat modellieren. ACS bietet dafür die HMAC-Baseline (acs-core), asymmetrische bzw. PQC-Signaturen (acs-crypto), request_hash (acs-audit) und den chain_hash der Audit-Chain.

1. 1
   Schritt 1Bedrohungen in Hypothesen übersetzen

   MAESTRO-Schichten und STRIDE-Eigenschaften je Agenten-Workflow durchgehen. Für jede gefährliche Transition ein Tupel H = (boundary, precondition, invariant, evidence, oracle) formulieren.

2. 2
   Schritt 2ACS-Hooks und Profile festlegen

   ACS-Core als Basis, dazu die Profile acs-trace und acs-provenance. Neben den sechs Core-Pflicht-Hooks (sessionStart, userMessage oder agentTrigger, toolCallRequest, toolCallResult, agentResponse, sessionEnd) zusätzlich steps/knowledgeRetrieval, steps/memoryContextRetrieval und steps/subagentStart instrumentieren — und prüfen, dass der Guardian sie in methods_evaluated führt (sonst gelten sie als ALLOW-by-default).

3. 3
   Schritt 3Decision Receipt definieren

   Principal, Policy-Version, Reason Code, Operation, normalisiertes Ziel, Argument-Digest, Capabilities, Delegationstiefe, Ablauf und Idempotenz in policy_data. Persistiert und an request_id sowie chain_hash gebunden.

4. 4
   Schritt 4Failure Posture härten

   Failure Posture fail-closed setzen: on_decision_failure: deny im ServerHello (Referenzimplementierung: ACS_ON_DECISION_FAILURE=deny) und am Observed Agent die Startup-Posture refuse, falls schon der Handshake scheitert. Envelopes signieren. Ein fehlender Receipt ist ein Testfehler.

5. 5
   Schritt 5Unabhängige Effekt-Senke anbinden

   Gateway-, Datenbank- oder Sink-Audit liefert beobachtetes Ziel, Operations-Digest und Idempotenzschlüssel, korreliert über die Action-ID.

6. 6
   Schritt 6Negativtests mit benignen Zwillingen

   Je Familie unsichere und eng verwandte benigne Fälle, etwa erlaubte Alias-Auflösung oder wiederholte Lesezugriffe. Predicates einfrieren, bevor getestet wird.

7. 7
   Schritt 7Zwei CI-Gates

   Gate 1 Rekonstruktion: Pflichtstufen und Parent-Kanten vollständig, sonst Quarantäne. Gate 2 Korrektheit: Invarianten erfüllt, sonst Abbruch mit verletzter Regel und erster Stufe.

8. 8
   Schritt 8Telemetrie-Faults injizieren

   F1 bis F6 regelmäßig gegen die eigene Pipeline fahren. Ein Test, der unter F1 noch grün ist, prüft keine Freigaben.

Die Studie nutzt synthetische deterministische Fixtures, handgeschriebene Invarianten und feste Ereignis-Zeitpläne. Sie führt kein LLM, keine MCP-Implementierung, kein OAuth, keine Policy-Engine und keinen externen Dienst aus. Sie misst weder den Erfolg von Prompt Injection, noch zeigt sie, dass eine Kontrolle einen Effekt verhindert. Precision und Recall gelten nur für die sechs kodierten Familien. Weil der Evaluator aus denselben Bedrohungshypothesen entworfen wurde, testet das Experiment Beweiskraft und Implementierungskonsistenz, nicht die Entdeckung neuer Bedrohungen.

• Der Ground-Truth-Ledger ist logisch getrennt, stammt aber aus derselben Codebasis. Unabhängige Implementierungen, property-based Mutation und echte Protokoll-Mitschnitte würden Common-Mode-Fehler reduzieren.
• Telemetrie wird als authentisch angenommen. Gefälschte Produzenten, Log-Kürzung jenseits der injizierten Fehler, kompromittierte Collector und kryptografische Verifikation sind offen.
• Neue Bedrohungsklassen brauchen eigene Hypothese, Felder, Orakel und unabhängig geschriebene Tests. Resource Exhaustion etwa verlangt Budget- und Verbrauchsevidenz, gefälschte Telemetrie verlangt Produzentenidentität und Integritätsprüfung.

Offenlegung aus dem Paper: OpenAI Codex wurde für Literaturorganisation, Implementierungsgerüst und Review des synthetischen Evaluationscodes, erste Entwürfe und Sprachüberarbeitung sowie Formatierung genutzt. Fragestellung, Bedrohungsmodell, Ausführung, Prüfung der Ergebnisse und Quellen sowie alle finalen Entscheidungen liegen beim Autor.