APort Vault: 4.371 Angriffe gegen simulierte Zahlungsagenten – 0 nicht erlaubte Transfers mit OAP

APort Vault: 4.371 Angriffe gegen simulierte Zahlungsagenten

APort Vault ist ein neues Benchmark für die Zahlungsermächtigung in tool-nutzenden KI-Agenten. Es replayt 4.371 von Menschen geschriebene Angriffe gegen einen live simulierten Zahlungsagenten während eines öffentlichen Capture-the-Flag-Events. Die Angriffe stammen aus 1.128 Sessions eines öffentlichen Wettbewerbs, der von März bis August 2026 lief, und werden gegen 14 Sprachmodelle aus 8 Labs abgespielt, die als simulierte Bankangestellte agieren; echtes Geld bewegt sich dabei nicht. Das Benchmark umfasst fünf Policy-Konfigurationen und zwei Replay-Tracks – mit und ohne deterministische Vorab-Prüfung gemäß der Open-Agent-Passport-Spezifikation (OAP). Insgesamt wurden 225.964 Evaluationen abgeschlossen; der eingefrorene Snapshot vom 10. September 2026 weist 225.964 abgeschlossene von 244.776 geplanten Evaluationen aus.

Frühere Arbeiten zur Sicherheit von KI-Agenten stützten sich auf modellbasierte Ausrichtung (probabilistisch, trainingszeitbasiert) oder nachträgliche Evaluation (retrospektiv, batchweise), die keine deterministische Durchsetzung auf Ebene einzelner Tool-Calls bieten. APort Vault schließt diese Lücke, indem es erstmals von Menschen geschriebene Angriffe unter zwei Bedingungen – mit und ohne deterministische Vorab-Prüfung – systematisch replayt und vergleicht. Jede Evaluation berichtet fünf getrennte Ereignisse, weil das Zusammenfassen zu einer einzelnen Kennzahl nach Angaben der Autoren ein Ergebnis erzeugt, das einer Überprüfung nicht standhält. Der Datensatz ist öffentlich zugänglich, unterliegt jedoch Zugriffsbedingungen: Er enthält Social-Engineering-Angriffsprompts und Modell-Transkripte, die manipulative oder schädliche Texte enthalten können; Nutzer müssen die Bedingungen akzeptieren und dürfen keine Teilnehmer zu identifizieren versuchen.

Messung: 140 nicht erlaubte Transfers ohne OAP, 0 mit OAP

Pro Evaluation werden fünf getrennte Ereignisse berichtet: eine Zahlungsanfrage, eine erfolgreiche Zahlung, eine Autorisierungsentscheidung, die Zugehörigkeit des Empfängers und ein Transfer an einen nicht erlaubten Empfänger. Die Anfragehäufigkeit unterscheidet sich stärker zwischen den Konfigurationen als zwischen den Modellen. Auf Level 1 stellen 10,9 Prozent der Model-alone-Evaluationen eine Zahlungsanfrage, auf Level 2 sind es 3,0 Prozent, auf Level 3 nur 0,1 Prozent und auf Level 4 79,4 Prozent. Diese starke Variation zwischen den Konfigurationen ist darauf zurückzuführen, dass jeder Angriff genau einer Konfiguration zugeordnet ist: Policy und Angriffskohorte variieren gemeinsam. Die Unterschiede spiegeln daher die jeweilige Policy-Strenge und die darauf zugeschnittenen Angriffe wider, nicht die Fähigkeiten der Modelle. Level 4 erlaubt dokumentierte Überweisungen an einen festgelegten Empfänger, sodass viele Angriffe dort Anfragen auslösen; Level 3 ist offenbar so restriktiv, dass kaum ein Angriff eine Anfrage provoziert. Auf den 1.293 Level-4-Prompts, die für jedes Modell ausgewertet wurden, liegen die Anfragehäufigkeiten zwischen 71,2 und 84,3 Prozent. 809 Prompts – 62,6 Prozent – lösten bei allen 14 Modellen eine Anfrage aus, die jeweils in einer erfolgreichen Zahlung an den für dieses Level erlaubten Empfänger endete. Level 4 autorisiert dokumentierte Überweisungen an diesen Empfänger, daher handelt es sich hier um geteiltes Verhalten und nicht um eine Zahl von Prompts, die die Modelle überwunden haben.

Die Autorisierungsgrenze wird im Benchmark dadurch bestimmt, dass für dieselben Prompts und Modelle die Ergebnisse der beiden Replay-Tracks verglichen werden: Im Track ohne OAP kann das Modell eigenständig entscheiden, im Track mit OAP wird jeder Tool-Call vor der Ausführung gegen die deklarative Policy geprüft. Die Grenze liegt dort, wo die Bedingungen auseinanderlaufen – also bei der Frage, ob ein Transfer an einen nicht erlaubten Empfänger ausgeführt wird. Auf den Levels 2 bis 4 zeigt sich diese Divergenz in den Zahlen: Bei Modellen allein gingen 140 von 76.842 Transfers an Empfänger, die der Passport nicht erlaubte; hinter der OAP-Schicht waren es 0 von 69.297. Auf 68.970 gematchten Tripeln aus Modell, Prompt und Track – also direkten Vergleichen desselben Prompts und Modells in beiden Bedingungen – betrug das Verhältnis 105 zu 0. Die Null hinter der OAP-Schicht erstreckt sich über 790 Quell-Sessions, was die Robustheit des Ergebnisses über viele verschiedene Angriffssitzungen hinweg belegt.

Open Agent Passport als deterministische Schutzschicht

Der Open Agent Passport (OAP) ist eine offene Spezifikation und Referenzimplementierung, die Tool-Calls synchron vor der Ausführung abfängt, gegen eine deklarative Policy prüft und einen kryptographisch signierten Audit-Datensatz erzeugt. Anders als modellbasierte Ausrichtung, die probabilistisch und trainingszeitbasiert ist, oder nachträgliche Evaluation, die retrospektiv und batchweise erfolgt, erzwingt OAP Autorisierungsentscheidungen deterministisch auf der Ebene einzelner Tool-Calls. Die deterministische Vorab-Prüfung verhindert nicht erlaubte Transfers vollständig, weil sie jeden Tool-Call unabhängig von der Absicht des Modells gegen die Policy prüft: Ein Transfer an einen Empfänger, der nicht in der Policy erlaubt ist, wird bereits vor der Ausführung blockiert. Selbst wenn das Modell durch Social Engineering dazu gebracht wird, einen solchen Transfer anzufordern, kann der Tool-Call nicht ausgeführt werden. Die gemessene mediane Latenz liegt bei 53 Millisekunden (N=1.000), sodass der Overhead minimal ist. In einem Live-Adversarial-Testbed mit 4.437 Autorisierungsentscheidungen aus 1.151 Sessions und einer Prämie von 5.000 Dollar war Social Engineering gegen das Modell unter einer permissiven Policy in 74,6 Prozent der Fälle erfolgreich. Unter einer restriktiven OAP-Policy erreichte eine vergleichbare Angreiferpopulation über 879 Versuche eine Erfolgsrate von 0 Prozent. Die Autoren unterscheiden die Vorab-Autorisierung von Sandbox-Ausführung, die den Schadensradius begrenzt, aber unautorisierte Aktionen nicht verhindert, und von modellbasiertem Screening, das probabilistisch bleibt. Beide Ansätze sind komplementär; dieselbe Infrastruktur, die Sicherheitsbeschränkungen wie Ausgabenlimits und Fähigkeits-Scoping durchsetzt, erzwingt auch Qualitäts-Gates.

Sicherheitsbedenken bei persönlichen KI-Agenten wachsen

Die Ergebnisse treffen auf ein Umfeld, in dem die Sicherheitsbedenken bei persönlichen KI-Agenten wachsen. Metas persönlicher KI-Agent Muse ist ein Beispiel für Systeme, die zunehmend Zugriff auf sensible Handlungen erhalten; bei fünf großen Anbietern nehmen die Sicherheitsbedenken zu. Die wachsenden Bedenken sind begründet, weil die bisherigen Sicherheitsarchitekturen auf probabilistischer Modellausrichtung beruhen: KI-Agenten haben heute Passwörter, aber keine Erlaubnisscheine. Der Live-Adversarial-Test des OAP-Papiers zeigt, dass Social Engineering unter permissiver Policy in 74,6 Prozent der Fälle erfolgreich ist – ein Beleg dafür, dass Modellverhalten allein keine Sicherheit bietet. Eine deterministische Autorisierungsschicht ist notwendig, weil sie jede Aktion vor der Ausführung gegen eine feste Policy prüft und damit unabhängig von der Manipulierbarkeit des Modells verhindert, dass nicht erlaubte Transfers ausgeführt werden. Betroffen sind die Anbieter der 14 getesteten Modelle, die nun über eine systematische Evaluation ihrer Zahlungsfreigaben verfügen, sowie Nutzer von KI-Agenten, die Zahlungen autorisieren können. Für die Entwickler des Open Agent Passport belegt das Benchmark, dass ihre Schicht die nicht erlaubten Transfers auf null reduziert – und zwar über 790 Quell-Sessions hinweg. Das Benchmark verwendet kein echtes Geld, aber die Angriffe stammen aus einem öffentlichen Wettbewerb und zeigen, dass eine deterministische, vor der Ausführung greifende Policy verhindern kann, dass Social Engineering zu unautorisierten Überweisungen führt. Damit liefert APort Vault einen praktischen Beleg dafür, dass eine Vorab-Autorisierungsschicht nicht nur theoretisch wünschenswert, sondern für den sicheren Einsatz persönlicher KI-Agenten mit Zahlungsfunktionen unverzichtbar ist.