💻 computer science

Safety Invariants for Agents Orchestrating Irreversible State Transitions: A Four-Dimensional Formalism Evaluated on Public Ledgers

Dieses Paper führt ein vierdimensionales Formalismusmodell und sieben abgeleitete Sicherheitsinvarianten ein, um die „Ausführungstreue“ (execution fidelity) für autonome Agenten zu garantieren, die irreversible Zustandsübergänge auf öffentlichen Ledgern durchführen, wobei sichergestellt wird, dass die realisierten Effekte entweder null oder exakt dem vom Nutzer gerenderten Übergang entsprechen – ein Framework, das empirisch validiert wurde, um die Sicherheit gegenüber Standard-Baselines in adversen Umgebungen signifikant zu verbessern.

Ursprüngliche Autoren: Zhaoming Yin

Veröffentlicht 2026-08-04

📖 8 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Zhaoming Yin

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie übergeben einem sehr intelligenten, aber etwas zerstreuten Roboter-Butler eine Liste von Aufgaben. Sie sagen: „Bitte verschiebe mein Taschengeld von meinem Sparschwein in mein Sparglas.“ In der Welt der Informatik ist dies der Bereich der autonomen Agenten: Softwareprogramme, die künstliche Intelligenz nutzen, um selbstständig Entscheidungen zu treffen und Handlungen auszuführen. Normalerweise sind diese Agenten großartig darin, Fragen zu beantworten oder Geschichten zu schreiben, aber sie beginnen gerade erst zu lernen, wie man die reale Welt berührt – wie etwa Geld zu bewegen, Dateien zu speichern oder das Licht einzuschalten. Das Problem ist, dass einige dieser Handlungen irreversibel sind. Sobald Sie Geld an einen Fremden überwiesen oder eine Datei gelöscht haben, können Sie nicht einfach auf „Rückgängig“ drücken. Wenn der Roboter Ihren Auftrag missversteht oder wenn es ein Internetfehler gibt, könnten Sie alles verlieren. Dieses Paper befasst sich mit der beängstigenden Frage: Wie stellen wir sicher, dass ein Roboter nicht versehentlich Ihr Geld verbrennt, während er versucht, Ihnen zu helfen?

Der Autor dieses Papers baut ein Sicherheitssystem für diese digitalen Butler, speziell für die Welt der Blockchains (öffentliche Register, in denen Geld und Vermögenswerte leben). Er stellte fest, dass bestehende Sicherheitsprüfungen zu vage waren. Anstatt einfach nur darauf zu hoffen, dass der Roboter „es richtig macht“, hat er eine strikte mathematische Regelwerk erstellt. Er hat bewiesen, dass wir zwar nicht erzwingen können, dass ein Roboter die menschliche Absicht perfekt versteht (da Sprache unordentlich ist), wir aber garantieren können, dass der Robbot entweder gar nichts tut oder genau das tut, was er versprochen hat, und zwar nur einmal. Sie nennen dies „Ausführungstreue“ (Execution Fidelity). Stellen Sie sich das wie einen magischen Vertrag vor: Wenn der Roboter sagt, er wird 10 $ bewegen, dann bewegt er entweder genau 10 $ oder er bewegt 0 $. Er kann nicht 100 $ bewegen, er kann die 10 $ nicht zweimal bewegen und er kann die 10 $ nicht an die falsche Person senden. Wenn der Roboter verwirrt ist, zwingt das System ihn dazu, anzuhalten und um Hilfe zu bitten, anstatt zu raten und potenziell eine Katastrophe zu verursachen.

Die vierdimensionale Landkarte

Um diese Garantie möglich zu machen, hat der Autor eine neue Art und Weise erfunden, ein digitales Wallet zu betrachten. Anstatt nur darüber nachzudenken, „wie viel Geld ich habe“, bildet er jede Transaktion auf einem vierdimensionalen Gitter ab. Stellen Sie sich eine riesige Tabelle vor, in der jede Zeile einen spezifischen Zustand Ihres Geldes darstellt, definiert durch vier Koordinaten:

Wallet: Welcher Satz von Schlüsseln (Ihre Identität) das Geld besitzt.
Chain: Welche digitale Autobahn das Geld nutzt (wie Ethereum, Bitcoin oder Solana).
Address: Der spezifische Briefkasten auf dieser Autobahn.
Protocol: Die spezifische Art des Assets oder des Spiels, in dem das Geld agiert (wie USDC, ein Bridge-Token oder ein gestaktes Derivat).

Das Paper argumentiert, dass man Geld nicht sicher bewegen kann, wenn man nicht alle vier dieser Koordinaten kennt. Wenn man nur drei kennt, könnte man versehentlich sein Bitcoin an eine Bitcoin-Adresse senden, die auf der Ethereum-Chain gar nicht existiert, oder es an die völlig falsche Wallet senden. Indem man die Transaktion als präzise Bewegung auf diesem 4D-Gitter behandelt, kann das System den „Vorher“- und „Nachher“-Zustand mit mathematischer Gewissheit prüfen.

Die sieben Sicherheitsregeln (Die Invarianten)

Der Kern des Papers ist eine Reihe von sieben Sicherheitsregeln (genannt Invarianten), denen der Roboter folgen muss. Dies sind keine bloßen Vorschläge; es sind hartcodierte Tore, die den Roboter stoppen, falls die Regeln nicht erfüllt sind. So funktionieren sie im Alltag:

Das „Zeig mir“-Tor: Bevor der Roboter Ihr Geld anfasst, muss er Ihnen eine Vorschau der exakten Bewegung zeigen, die er plant zu machen. Sie (oder eine strikte automatisierte Prüfung) müssen dieser spezifischen Vorschau zustimmen („Ja“ sagen). Der Roboter darf nicht einfach sagen „Ich mache es“ und dann etwas anderes tun.
Das „Prüfe den Kontostand“-Tor: Unmittelbar bevor der Roboter die Transaktion signiert, muss er den echten Kontostand auf der Blockchain prüfen, nicht eine zwischengespeicherte oder veraltete Zahl. Wenn das Geld nicht da ist, stoppt der Roboter. Dies verhindert, dass der Roboter versucht, Geld auszuge außen, das in der Zwischenzeit verschwunden ist.
Die „Warte und sieh nach“-Regel: Nachdem der Roboter eine Transaktion gesendet hat, sagt er nicht sofort „Erfolg!“, wenn er das Ergebnis noch nicht auf der Blockchain sehen kann. Wenn das Internet langsam ist oder die Blockchain beschäftigt ist, sagt der Roboter „Ich bin mir nicht sicher“, anstatt „Es ist erledigt!“. Dies verhindert, dass der Roboter in Panik gerät und versucht, das Geld erneut zu senden, nur weil er keine sofortige Antwort erhalten hat.
Die „Kein Geistererfolg“-Regel: Wenn der Roboter einen Beleg erhält (eine Transaktions-ID), die Blockchain die Bewegung aber nie tatsächlich registriert, gibt der Roboter zu, dass es fehlgeschlagen ist. Er weigert sich zu lügen und „Gesendet!“ zu sagen, wenn das Geld noch in Ihrer Tasche steckt.
Die „Ausweis“-Regel: Wenn ein Roboter in Ihrem Namen handelt (wie ein automatisierter Spar-Bot), muss er ein digitales Ausweisdokument tragen, das genau besagt, was er tun darf. Wenn der Ausweis „Nur Transfer“ besagt, darf der Roboter kein Geld „tauschen“ oder „bridgen“, selbst wenn er durch einen kniffligen Prompt verwirrt wird.
Die „Verifizieren vor Wiederholung“-Regel: Wenn der Roboter glaubt, dass eine Bewegung fehlgeschlagen ist, darf er nicht einfach sofort wieder versuchen. Er muss zuerst auf der Blockchain nachsehen, um zu beweisen, dass die Bewegung nicht stattgefunden hat. Wenn die Bewegung tatsächlich stattgefunden hat (der Roboter es aber nicht wusste), ist der Roboter verboten, sie ein zweites Mal zu senden. Dies verhindert, dass er Ihr Geld versehentlich „doppelt ausgibt“.
Die „Eine Nachricht“-Regel: Wenn das Internet versehentlich dieselbe Anfrage zweimal sendet (wie ein Doppelklick), erkennt das System dies als Duplikat und ignoriert das zweite. Dies stellt sicher, dass der Roboter selbst bei Netzwerkfehlern nur einmal handelt.

Was sie herausgefunden haben (und was nicht)

Der Autor hat diese Regeln mit einem „Bösewicht“-Simulator getestet, der versuchte, den Roboter zu Fehlern zu verleiten. Er nutzte einen Datensatz von 60 kniffligen Szenarien und testete sie gegen vier verschiedene KI-Modelle.

Der große Sieg: Bei zwei KI-Modellen, die bereitwillig handeln (genannt „write-aggressive“), verbesserte das Hinzufügen dieser sieben Sicherheitsregeln die Erfolgsrate um etwa 74 Prozentpunkte. Der ungeschützte Roboter (ohne Regeln) scheiterte fast an allem, während der geschützte Roboter meistens erfolgreich war.
Die Einschränkung: Bei einem KI-Modell, das von Natur aus vorsichtig und zögerlich beim Handeln war, brachten die Sicherheitsregeln nur eine Verbesserung von etwa 3 Prozentpunkten. Dies lehrte den Autor eine entscheidende Lektion: Die Sicherheit eines Agenten hängt stark davon ab, welches KI-Gehirn unter ihm arbeitet. Eine Sicherheitsebene kann kein Gehirn reparieren, das zu eifrig ist, und sie muss auch kein Gehirn korrigieren, das bereits zu vorsichtig ist.
Realwelt-Beweis: Das System ist nicht nur Theorie. Der Autor hat es in der realen Welt eingesetzt und 108 tatsächliche Schreibvorgänge über 8 verschiedene Blockchains hinweg verfolgt. Er beobachtete reale Fehler (wie „Phantom-Erfolge“, bei denen das Internet über eine Transaktion log) und zeigte, wie seine Regeln diese abfing. Zum Beispiel fand er einen Fall, in dem ein Roboter fast 200 $ doppelt ausgegeben hätte, weil er glaubte, eine Transaktion sei fehlgeschlagen, obwohl sie eigentlich erfolgreich war; die Sicherheitsregeln stoppten den zweiten Versuch.

Die Grenzen der Magie

Das Paper ist sehr ehrlich darüber, was es nicht kann. Es stellt explizit fest, dass es nicht garantieren kann, dass der Roboter verstanden hat, was Sie meinten. Wenn Sie sagen „Schicke mein ganzes Geld zum Mond“ und der Roboter es an einen Scammer schickt, wird das System immer noch perfekt funktionieren: Es wird genau das senden, was Sie verlangt haben, und zwar genau einmal. Das Sicherheitssystem stellt sicher, dass der Roboter ein getreuer Ausführer ist, kein weiser Berater. Es stellt sicher, dass der Roboter keine technischen Fehler macht, aber es verhindert nicht, dass der Roboter einem schlechten Befehl folgt.

Der Autor gibt auch zu, dass seine Sicherheitsgarantie endet, wenn die Internetverbindung zu lange unterbrochen ist oder wenn das KI-Modell selbst sein Verhalten auf eine Weise ändert, die das System nicht erwartet hat. Er hat bewiesen, dass seine sieben Regeln ausreichen, um den Roboter vor technischen Fehlern (wie dem doppelten Senden oder dem Senden an die falsche Adresse) zu schützen, aber die endgültige Verantwortung für die Frage „Ist das eine gute Idee?“ liegt weiterhin beim Menschen.

Kurz gesagt: Dieses Paper löst nicht das Problem „Wie erschaffe ich einen Roboter, der wie ein Mensch denkt?“. Stattdessen löst es das Problem: „Wie sorge ich dafür, dass ein Roboter wie ein Roboter handelt, aber dabei niemals einen Fehler macht?“. Indem er die unordentliche Welt des digitalen Geldes in eine präzise vierdimensionale Karte verwandelt und sieben unzerbrechliche Tore errichtet, hat er ein System geschaffen, in dem das Einzige, was schiefgehen kann, ist, dass Sie von vornherein etwas Schlechtes verlangen. Und das, so argumentiert er, ist die beste Sicherheit, auf die wir hoffen können.

Technisches Resümee: Sicherheitsinvarianten für Agenten, die irreversible Zustandsübergänge orchestrieren

Problemstellung

Autonome Agenten auf Basis probabilistischer Planer (LLMs) werden zunehmend mit der Erzeugung irreversibler Effekte auf externe Systeme betraut, wie etwa dem Transfer von Geldern auf öffentlichen Ledgern, dem Schreiben in dauerhaften Speicher oder der Aktuierung von Hardware. Bestehende Frameworks (z. B. ReAct, Reflexion, MCP) optimieren auf Aufgabenerfolg in Benchmarks, ignorieren jedoch weitgehend die Sicherheit irreversibler Seiteneffekte.

Die zentrale Herausforderung besteht darin, dass eine Laufzeitschicht nicht definitiv bestimmen kann, ob ein generierter Übergang tatsächlich die natürliche Nutzerintention („Intent-Mapping-Problem“) korrekt abbildet. Das Paper argumentiert jedoch, dass die Ausführung dieser Intention kontrollierbar ist, selbst wenn das Mapping der Intention ungelöst bleibt. Ohne solche Kontrollen leiden Agenten unter spezifischen Fehlermodi:

RPC-Ebene: „Phantom-Erfolg“ (RPCs geben Hashes zurück, die später zurückgezogen werden) oder „Phantom-Fehler“ (legitime Transaktionen landen auf der Chain, werden aber aufgrund kurzer Verifizierungsfenster als fehlgeschlagen gemeldet).
LLM-Ebene: „Stale-Context Drift“ (Veraltung des Kontexts), bei dem Agenten veraltete Schlussfolgerungen wiederholen (z. B. „Nutzer hat kein Konto“), selbst nachdem sich der Grundzustand geändert hat.
Exchange/API-Ebene: „Documented-Atomicity Drift“, bei dem als atomar spezifizierte Aktionen (z. B. Cancel-and-Replace) bei einer Ablehnung nur teilweise ausgeführt werden, was den Nutzer in unsichere Zustände versetzt.
Operativ: Doppelte Lieferungen und falsch gemappte Wallet-Auswahlen, die zu unbeabsichtigten Double-Spends führen.

Methodik und Formalismus

Vierdimensionaler Zustandsraum

Das Paper formalisiert Wallet-Operationen als Zustandsübergänge in einem vierdimensionalen Raum $S = W \times C \times A \times P$ :

$W$ (Wallet): Das Mnemonic/Seed, welches die Gelder kontrolliert.
$C$ (Chain): Das Blockchain-Netzwerk.
$A$ (Address): Die spezifische Adresse auf dieser Chain.
$P$ (Protocol): Der spezifische Token, Contract oder das Off-Chain-Konto (z. B. USDC auf Arbitrum vs. perp-USDC auf Hyperliquid).

Ein Übergang $\tau$ ist eine partielle Funktion, die die Bestände an einer begrenzten Menge von Quadrupeln modifiziert. Entscheidend ist, dass das Formalismus den Wallet ( $W$ ) als festen Koordinatenpunkt für einen einzelnen Übergang behandelt. Dies ermöglicht es dem System, zwischen „unzureichenden Mitteln“ (einem gültigen Check-Fehler des Zustands) und einer „falschen Wallet-Auswahl“ (einem fatalen Fehler, bei dem der Agent das falste $W$ gewählt hat) zu unterscheiden – eine Unterscheidung, die in niederdimensionalen Modellen verloren geht.

Ausführungstreue (Execution Fidelity)

Das Paper definiert Execution Fidelity als die Garantie, dass für jede Session $\sigma$ der realisierte Effekt auf dem Ledger, $real(\sigma)$ , entweder:

Nichts ( $\emptyset$ ) ist, oder
Exakt der Übergang $\tau_p$ ist, der dem Nutzer gerendert wurde, und zwar exakt einmal.

Das Theorem behauptet explizit nicht, dass $\tau_p$ der natürlichen Sprache des Nutzers entspricht. Stattdessen reduziert es die ungebundene semantische Frage „Hat der Agent verstanden?“ auf eine gebundene, entscheidbare Prüfung: „Entspricht das vier-koordinatige Tupel und der Betrag dem, was in der Vorschau angezeigt wurde?“

Die sieben Sicherheitsinvarianten

Abgeleitet durch eine Fallanalyse der Fidelity-Bedingung (Verhinderung von ungerenderten Ausführungen, doppelter Ausführung und abgeleiteten, aber abweichenden Ausführungen), erzwingt das System sieben Invarianten:

Confirm Gate (Executor-lokal): Kein Signing-Key wird abgeleitet, bis eine explizite Bestätigung gegen einen gerenderten Übergangs-Tupel aufgezeichnet wurde. Dies zwingt das System, sich vor irreversiblen Schritten auf einen einzigen Punkt in $S$ festzulegen.
Pre-state Sufficiency (Executor-lokal): Unmittelbar vor dem Signieren wird eine Ground-Truth-Saldoprüfung (unter Umgehung von Eventual-Consistency-Caches) durchgeführt, um sicherzustellen, dass der Übergang zum Zeitpunkt der Broadcast-Ausführung anwendbar ist.
Post-state Observability (Executor-lokal): Wenn ein Broadcast-Ergebnis innerhalb eines begrenzten Zeitfensters nicht beobachtet werden kann, meldet das System „Unsicherheit“ statt „Fehler“, um falsche Trigger für Retries zu vermeiden.
No Phantom Success (Executor-lokal): Eine Transaktion wird niemals als erfolgreich gemeldet, es sei denn, ihre Existenz auf der Chain wurde durch einen Indexer oder RPC verifiziert.
Scoped Delegation (Cross-tier): Nicht-menschliche Aufrufer (Avatare) operieren unter expliziten Scope-Sets (z. B. {transfer}), die aus Delegation-Tokens abgeleitet sind. Der Executor lässt Aufrufe nur zu, wenn der Scope den erforderlichen Übergang abdeckt, wodurch Authentifizierung von Autorisierung entkoppelt wird.
Plan-level Retry Safety (Plan-Ebene): Avatare dürfen einen irreversiblen Übergang bei einem gemeldeten Fehler oder einer Unsicherheit nicht erneut ausführen, bis sie mittels Ground-Truth-Zustands positiv verifiziert haben, dass der Effekt des Übergangs abwesend ist.
Idempotent Intent Receiver (HTTP Receiver): Externe Intents, die über At-least-once-Kanäle eintreffen, werden durch Hashing der Sender-ID und der Request-Bytes dedupliziert, um sicherzustellen, dass ein einzelner Nutzer-Intent genau einen Übergangs-Tupel produziert.

Zentrale Beiträge

Formale Risikoreduktion: Das Paper beweist, dass unter einem Fehlermodell, das Planner-Mis-Mapping, ambivalente Ergebnisse und Retries zulässt, die sieben Invarianten das Restrisiko auf das einzige Prädikat des Intent-Mappings einschränken. Alle anderen Fehlermodi führen zwangsläufig zu keinem Effekt.
Ableitung der Invarianten: Im Gegensatz zu bisheriger Arbeit, die Sicherheitsregeln aus der Erfahrung enumeriert, werden diese Invarianten logisch aus der Definition der Execution Fidelity abgeleitet, was die Vollständigkeit gegenüber dem definierten Fehlermodell sicherstellt.
Multi-Tier-Architektur: Das Paper beschreibt cryptitalk-wallet, ein eingesetztes System mit einem Avatar-Tier (persistente Agenten, die im Namen von Nutzern handeln) und einem Executor-Tier (der Wallet-Service). Die Architektur behandelt Avatare und Menschen aus Sicht des Executors als austauschbare Aufrufer, gesichert durch Scoped-Delegation-Tokens.
Methodologisches Argument zur Evaluierung: Das Paper argumentiert, dass Sicherheitsbewertungen stark von dem „Backing Model“ (dem LLM) abhängen. Der Wert eines Safety-Stacks ist eine Funktion der inhärenten Aggressivität des Modells; die Evaluierung eines Stacks auf einem einzelnen Modell zu testen, ist „nahezu unfalsifizierbar“.

Empirische Ergebnisse

Kontrollierte Adversarial Suite ( $N=60$ )

Das System wurde gegen eine gelabelte adversarielle Prompt-Suite evaluiert, die die identifizierten Fehlerklassen adressiert, über vier Backing-Modelle hinweg:

Write-Aggressive Modelle (Claude, MiniMax): Der vollständige Invarianten-Stack steigerte die Erfolgsrate im Vergleich zu einem Baseline-ReAct-Ansatz (z. B. 81,7 % vs. 10,2 % für Claude) um ca. 74 Prozentpunkte.
Write-Cautious Modell (Gemini): Der Stack steigerte die Erfolgsrate nur um ca. 3 Punkte (60,0 % vs. 56,7 %), da das Modell selbst bei ambivalenten Prompts Write-Tools ablehnte.
Ablationsstudien: Das Deaktivieren von Code-Gate-Invarianten (I1, I3, I5, I6, I7) führte dazu, dass die Erfolgsraten bei spezifischen Fehlerklassen auf nahezu Null zusammenbrachen, was bestätigt, dass jede Gate eine tragende Rolle spielt. Tool-Level-Ablationen (I2, I4) zeigten geringere Auswirkungen, da das Agenten-Reasoning einzelne Tool-Entnahmen teilweise kompensierte.

Produktionseinsatz

Das System hat 108 Produktions-Write-Operationen über 8 Chains und 8 Übergangs-Primitive hinweg durchgeführt.

Fehler-Taxonomie: Die Einsatzdaten validierten die Fehler-Taxonomie; Vorfälle wurden bei „Phantom Success“, „Preview Gate Bypass“, „Wrong-Wallet Selection“ und „Duplicate Webhook Delivery“ beobachtet.
Avatar-Flotte: In einer Flotte von 87 DCA-Läufen (Dollar Cost Averaging) waren 32 % erfolgreich, 32 % wurden an Menschen eskaliert, 24 % errederten (korrekt gemeldet) und 11 % wurden abgebrochen. Entscheidend ist, dass nach der Implementierung von Invariant-6 keine duplizierten On-Chain-Übergänge auftraten, im Gegensatz zu einer Fallstudie vor der Implementierung, bei der ein „Phantom Failure“ zu einem realisierten Double-Spend von 400 USDT führte.

Bedeutung und Ansprüche

Das Paper behauptet, dass Execution Fidelity eine handhabbare Sicherheitseigenschaft für autonome Agenten ist, die auf irreversiblen Zuständen agieren, selbst wenn das Intent-Mapping weiterhin ungelöst bleibt. Durch die Formalisierung des Zustandsraums und die Ableitung der Invarianten aus Grundprinzipien stellt das System sicher, dass, wenn ein Agent handelt, er exakt so handelt, wie in der Vorschau dargestellt, und zwar exakt einmal.

Die Bedeutung liegt in:

Reduktion ungebundenen Risikos: Die Umwandlung des unendlichen Problems „Hat der Agent verstanden?“ in einen endlichen, prüfbaren Vergleich eines vier-koordinatigen Tupels.
Praktische Implementierung: Der Nachweis, dass diese formalen Garantien in einem realen Multi-Chain-Wallet-System mit produktiven Geldern implementiert werden können.
Evaluierungsrigorosität: Die Betonung, dass Safety-Stacks nicht isoliert von der Verhalten des zugrunde liegenden LLM evaluiert werden können, und die Forderung, das Backing Model als primäre experimentelle Variable zu behandeln.

Das Paper räumt explizit Einschränkungen ein: Die Garantie endet beim „unattended case“ (wo Scope-Checks die menschliche Bestätigung ersetzen), die Duplikatsunterdrückung ist zeitlich begrenzt ( $\Delta$ ), und das System bietet keine Atomarität für mehrstufige Pläne (nur Präfix-Konsistenz). Es beansprucht nicht, MEV, Smart-Contract-Bugs oder Key-Compromise zu lösen, sondern konzentriert sich strikt auf die Orchestrierungsebene des Agenten.