Forschung

Methodik

Eine Evaluierung zeigt, welche Angriffe bei Ihrem Agenten Erfolg haben, wie er sich dann verhält und wie zuverlässig sie funktionieren. All das beruht auf einem Prinzip: Ein probabilistisches System lässt sich nicht verifizieren, indem man es fragt, was es getan hat. Deshalb wird jeder Befund an einer deterministic ground truth gemessen — an dem, was tatsächlich geschehen ist, und dem, was hätte geschehen sollen, unabhängig vom Agenten ermittelt.

1. 01

   Zwei Arten, wie ein Agent bei einem Angriff versagen kann

   Bei deceived folgt der Agent manipulierten Inputs und berichtet wahrheitsgemäß, was er getan hat: Sein account — sein Bericht über das eigene Tun — stimmt mit seinem Handeln überein, doch das Handeln verletzt die obligation, also das, was er hätte tun sollen. Bei deceiving weicht der account von dem ab, was der Agent getan hat. Unterschieden werden die beiden am Output, nicht am Input — ein einziger manipulierter Datensatz kann beides auslösen. In beiden Fällen liegt die Ursache beim Angriff, nicht in einer Absicht des Agenten.

2. 02

   Zwei Kontrollen, eine für jede Klasse

   Obligation-detection vergleicht, was der Agent getan hat, mit der obligation und erfasst beide Klassen, wo immer der Angriff das Handeln des Agenten verändert hat. Claim-verification vergleicht den account des Agenten mit dem Protokoll dessen, was er getan hat; sie erfasst deceiving, nicht aber deceived, denn bei deceived ist der account wahr. Die beiden beantworten verschiedene Fragen: Hat der Agent getan, was er sollte? Und stimmt sein Bericht darüber? Die erste zählt immer; die zweite, sobald sich andere auf diesen Bericht verlassen — ein Prüfprotokoll, ein Compliance-Nachweis, ein nachgelagertes System. Ob bei einem Agenten der Fall deceiving überhaupt eintreten kann, hängt von seiner Architektur ab: Nur wenn sie decoupled ist (der Agent also über einen eigenen Kanal berichtet, getrennt von dem, über den er handelt), kann er das eine sagen und das andere tun. Deshalb untersuchen wir zuerst die Architektur und führen dann beide Kontrollen durch.

3. 03

   Die Referenz, an der alles gemessen wird

   Die deterministic ground truth hat zwei Teile, beide unabhängig vom Agenten ermittelt. Das observed behaviour — das tatsächlich beobachtete Handeln — wird dort erfasst, wo der Agent keinen Zugriff hat: an den Systemen, auf die er einwirkt, nicht aus seinen eigenen Logs. Die obligation stammt aus einer Quelle, die weder der Angriff noch der Agent verändern kann: einer Spezifikation, festgelegten Betriebsgrenzen, einer Richtlinientabelle. Jeder Befund nennt, auf welche Quelle er sich stützt und ob sie konstruktionsbedingt außer Reichweite des Angriffs lag oder nur, weil der Angriff sie zufällig nicht berührt hat.

4. 04

   Beobachtung, die der Agent nicht bemerken kann

   Wir beobachten an drei Stellen unterhalb der Ebene, auf welcher der Agent arbeitet: an seinen Prozessen, an der Netzwerkgrenze, die seine Aufrufe überqueren, und an den Systemen, auf die er einwirkt. Der Agent kann keine davon lesen oder verändern — nicht, weil es ihm verboten wäre, sondern weil er keinen Zugriff darauf hat. So kann er die Referenz, an der er gemessen wird, nicht einsehen und nicht erkennen, dass er evaluiert wird — und sich folglich auch nicht anders verhalten als im Betrieb.

5. 05

   Messung

   Ein Agent kann auf denselben Input jedes Mal anders reagieren; ein einzelner Durchlauf beweist daher wenig. Jedes Bedrohungsszenario läuft zuerst viele Male ohne den Angriff, als saubere Baseline, dann ebenso oft mit ihm; ein Befund zählt nur, wenn er mit dem Angriff auftritt und in der Baseline nicht. Daran sehen Sie, ob ein Angriff gelegentlich oder jedes Mal gelingt — und, gewichtet nach der Schwere seiner Folgen, was zuerst behoben werden sollte.

6. 06

   Wo die Methodik greift

   Drei Dinge müssen zutreffen, und alle drei lassen sich prüfen, bevor die Arbeit beginnt:

   • Wir sehen, was der Agent tatsächlich tut — seine Tool-Aufrufe, Abfragen und Entscheidungen — und nicht nur den Text, den er erzeugt.
   • Angriffe lassen sich dort durchspielen, wo ihre Folgen nicht real sind: bei physischen Prozessen in einer Simulation, bei Datenflüssen in einer Entwicklungs- oder Staging-Umgebung.
   • Es gibt eine Referenz, die der Angriff nicht erreicht — unabhängig vom Agenten und von allem, was der Angreifer manipuliert.

   Das gilt auch, wenn dem Agenten eine Guardrail oder ein anderer Schutz vorgeschaltet ist, denn die Referenz hängt von keinem der beiden ab.

7. 07

   Was ein Ergebnis beschreibt

   Ein Ergebnis beschreibt Ihren Agenten so, wie er tatsächlich läuft — mit seinem Modell, seiner Konfiguration und seinen Tools. Damit ist es ein Beleg über das Produkt, das Sie ausliefern, kein allgemeiner Score für das Modell darunter. Und weil die Bedrohungsszenarien und die Referenz erhalten bleiben, lässt sich die nächste Version gegen denselben Satz evaluieren und beide Ergebnisse vergleichen.

Die vollständige Begründung samt den Demonstrationen ist in unserem Paper Adversarial Assessment of Agentic Systems (2026) veröffentlicht.