🤖 AI

RAILS: Verification-Native Clearing For Agentic Commerce

Dieses Paper stellt RAILS vor, ein verifikationsnatives Clearing-Protokoll für agentischen Handel, das eine formale, falsifizierbare Korrektheits-Eigenschaft etabliert, die sicherstellt, dass keine finanziell materielle Abrechnung ohne Beweise stattfindet, welche die Zulässigkeitsschwelle der Verpflichtung erfüllen, wodurch die kritische Lücke zwischen autonomen Agentenaktionen und neutraler Verifizierung von Verpflichtungen geschlossen wird.

Ursprüngliche Autoren: Adrian de Valois-Franklin, Alex Bogdan

Veröffentlicht 2026-06-09

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Adrian de Valois-Franklin, Alex Bogdan

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 eine Welt vor, in der KI-Agenten wie hochqualifizierte, unabhängige Auftragnehmer agieren. Sie können Code schreiben, Teile kaufen, Verträge unterzeichnen und Geld bewegen, ohne dass ein Mensch bei jedem einzelnen Schritt „genehmigen“ drücken muss.

Das Problem ist laut diesem Paper, dass wir zwar die Straßen gebaut haben, auf denen diese Agenten fahren können (Zahlungssysteme, Kommunikationstools, Autorisierungsprüfungen), aber nicht das Verkehrsgericht, das entscheidet, wer eigentlich im Recht ist, wenn etwas schiefgeht.

Wenn ein KI-Agent ein 40.000 $ teures Teil kauft, das sich als das falsche Modell herausstellt, oder wenn ein Coding-Agent einen Bug behebt, aber versehentlich eine Sicherheitslücke einführt, können aktuelle Systeme nicht automatisch klären: Hat der Agent tatsächlich das getan, was er versprochen hat? Ist der Beweis gut genug, um die Zahlung freizugeben? Wer ist schuld?

Das Paper stellt RAILS (Real-Time Agent Integrity & Ledger Settlement) als das fehlende „Verkehrsgericht“ für die KI-Ökonomie vor.

So funktioniert es, erklärt anhand einfacher Analogien:

1. Das Kernproblem: „Autorisierung“ ist nicht „Abwicklung“

Denken Sie an die Autorisierung als einen Chef, der einem Mitarbeiter eine Kreditkarte gibt und sagt: „Geh und kauf einen neuen Stuhl.“

Aktuelle Systeme: Sie prüfen, ob der Mitarbeiter die Karte hatte (Autorisierung) und ob das Geld floss (Zahlung).
Die Lücke: Sie prüfen nicht, ob der Mitarbeiter auch wirklich einen Stuhl gekauft hat, oder ob er einen Stuhl gekauft hat, der sofort zusammenbricht.
Die Behauptung des Papers: Nur weil der Agent erlaubt war zu handeln und das Geld bewegt wurde, bedeutet das nicht, dass die Arbeit korrekt erledigt wurde. Wir brauchen ein System, das das Ergebnis verifiziert, nicht nur die Erlaubnis.

2. Die Lösung: Das RAILS-Protokoll

RAILS ist eine siebenstufige „Integritätsschicht“, die als neutraler Schiedsrichter fungiert. Es fragt nicht nur „Hast du es getan?“, sondern: „Kannst du beweisen, dass du es getan hast, und ist dieser Beweis stark genug, um das Geld freizugeben?“

Hier sind die sieben „Primitiven“ (Werkzeuge), die RAILS verwendet, erzählt als Geschichte:

Das Obligationsobjekt (Der Vertrag): Bevor die Arbeit beginnt, unterzeichnen der Mensch und die KI einen digitalen Vertrag. Es ist nicht nur „Behebe den Bug“. Es ist: „Behebe den Bug, füge keine neuen Bibliotheken hinzu und beweise es mit einem spezifischen Testprotokoll.“ Dies legt die Spielregeln fest.
Der Beweisumschlag (Die Beweiskiste): Nachdem die KI fertig ist, packt sie ihre Arbeit ein. Sie sagt nicht einfach nur „Ich habe es getan“. Sie legt die Codeänderungen, die Testprotokolle und die Sicherheits-Scans in eine versiegelte, unveränderliche digitale Box. Entscheidend ist, dass jedes Element in der Box ein „Vertrauens-Tag“ erhält (z. B. „Dies stammt von einem sicheren Server“ gegenüber „Dies ist nur die Aussage der KI selbst“).
Das Verifizierungsnetz (Die Jury): Anstatt eines einzelnen Richters nutzt RAILS ein Gremium aus verschiedenen „Jurors“.
- Der Roboter-Richter: Prüft, ob der Code strengen Regeln folgt (z. B. „Hast du eine neue Bibliothek hinzugefügt?“).
- Der Belegprüfer: Betrachtet Protokolle aus externen Systemen (wie einem CI-Server).
- Der menschliche Schiedsrichter: Ein echter Mensch, der einspringt, wenn die Roboter verwirrt sind.
- Der semantische Richter: Eine KI, die den Code liest, um zu sehen, ob er das Problem tatsächlich löst.
Die Abwicklungsentscheidung (Das Urteil): Das System kombiniert die Stimmen der Jury. Aber hier kommt die magische Regel: Das Urteil ist nur gültig, wenn der Beweis stark genug ist.
- Die „Boden“-Regel: Wenn der Vertrag besagt: „Wir benötigen einen Nachweis von einem sicheren Server (Hohes Vertrauen)“, die KI aber nur einen Selbstbericht (Niedriges Vertrauen) liefert, lehnt das System das Urteil ab. Es verweigert die Auszahlung bei schwachem Beweis, selbst wenn die KI sagt, sie habe gute Arbeit geleistet.
Die Abwicklungsanweisung (Der Scheck): Sobald das Urteil gültig ist, weist das System die Bank oder den Zahlungsdienstleister an: „Geben Sie das Geld frei“, „Erstatten Sie das Geld zurück“ oder „Bestrafen Sie den Agenten“.
Der Abwicklungspass (Der Reputationswert): Jeder Agent erhält eine Bewertung. Wenn er weiterhin mit starken Beweisen besteht, steigt sein Score. Wenn er versucht zu betrügen oder schwache Beweise nutzt, sinkt sein Score. Dieser Score bestimmt, wie viel Vertrauen er in Zukunft erhält.
Finalitätsregeln (Der Richterhammer): Dies ist der Timer. Die Entscheidung beginnt als „provisorisch“ (vorläufig). Wenn innerhalb einer festgelegten Zeit niemand Einspruch erhebt und die Beweise weiterhin stark sind, wird sie „final“ (endgültig).

3. Das „Soundness“-Versprechen (Die Korrektheitsgarantie)

Das Paper stellt eine sehr spezifische Behauptung auf: RAILS garantiert, dass kein Geld fließt, bevor der Beweis eine Mindestschwelle an „Vertrauen“ erreicht hat.

Stellen Sie sich ein Casino vor.

Der alte Weg: Der Dealer (KI) sagt: „Ich habe gewonnen“, und die Maschine zahlt aus.
Der RAILS-Weg: Der Dealer muss seine Karten zeigen. Wenn die Karten verschwommen sind oder auf eine Serviette gezeichnet wurden (schwacher Beweis), verweigert die Maschine die Auszahlung, selbst wenn der Dealer darauf besteht, dass er gewonnen hat. Die Maschine zahlt nur, wenn die Karten klar sichtbar und durch die Sicherheitskameras verifiziert wurden (starker Beweis).

4. Warum das wichtig ist

Das Paper argumentt, dass ohne diese „Abwicklungs“-Schicht die KI-Ökonomie nicht sicher skalieren kann.

Zahlungssysteme (wie Visa oder Krypto) bewegen Geld, wissen aber nicht, ob die Dienstleistung erbracht wurde.
Escrow-Systeme halten Geld zurück, benötigen aber einen Richter, der sagt, wann es freigegeben werden soll.
LLM-Richter (KI, die KI bewertet) sind anfällig für Bias und können getäuscht werden.

RAILS löst dies, indem es einen neutralen Prozess schafft, der die Qualität des Beweises bewertet, bevor Geld fließt. Es stellt sicher, dass eine KI das System nicht austricksen kann, um sich für eine Arbeit bezahlen zu lassen, die sie gar nicht erledigt hat, indem sie einfach nur behauptet: „Ich habe es getan.“

Zusammenfassung

RAILS ist die fehlende „Vertrauensschicht“ für die KI. Es verwandelt die komplexe Frage „Hat die KI gute Arbeit geleistet?“ in einen strengen, mathematischen Prozess: „Ist der Beweis stark genug?“ Es stellt sicher, dass man in einer Welt autonomer Agenten nicht nur für den Versuch bezahlt, sondern nur für das verifizierte Ergebnis.

Technisches Resümee: RAILS – Verifikations-native Clearing-Verfahren für agentische Kommerz

1. Das Problem: Die agentische Clearing-Lücke

Das Paper identifiziert eine kritische strukturelle Lücke in der aufstrebenden Infrastruktur des autonomen Agenten-Kommerzes. Während bestehende Protokolle effektiv Autorisierung (Gewährung von Berechtigung), Ausführung (Tool-Aufrufe und Kommunikation) und Zahlung (Werttransfer) handhaben, bietet keines einen neutralen Mechanismus zur Bestimmung der Leistungserfüllung.

Aktuelle Systeme stehen vor dem „agentischen Clearing-Problem“:

Autorisierung $\neq$ Clearing: Ein Agent kann autorisiert sein, aber dennoch die falsche Aktion ausführen (z. B. einen Flug für die falsche Woche buchen).
Zahlung $\neq$ Clearing: Eine Zahlungsleitung kann einen Transfer kryptografisch validieren, selbst wenn die Dienstleistung mangelhaft oder nicht erbracht wurde.
LLM-as-Judge $\neq$ Clearing: Während LLMs die semantische Leistung bewerten können, leiden sie unter Bias (Positions-, Verbositäts- und Selbstverbesserungs-Bias) und es fehlt ihnen an einer formalen, falsifizierbaren Garantie, dass ihre Urteile auf zulässigen Beweisen basieren.
Escrow $\neq$ Clearing: Treuhandkonten (Escrow) und Underwriting sind Abwicklungmechanismen, die eine Entscheidung konsumieren; sie erzeugen die Entscheidung selbst nicht.

Der Kern des Problems ist, dass keine bestehende Schicht die zusammengesetzte Frage beantwortet: Was wurde versprochen, was ist passiert, welche Beweise sind zulässig, wer ist verantwortlich, welcher Verlust ist entstanden und welche Abwicklungsmaßnahme ist endgültig? Ohne dies ignorieren Abwicklungssysteme entweder das Risiko oder übertragen es der falschen Partei.

2. Methodik: Das RAILS-Protokoll

RAILS (Real-Time Agent Integrity & Ledger Settlement) wird als verifikations-natives Clearinghouse-Protokoll vorgeschlagen. Es sitzt zwischen der Ausführungsschicht (Agenten, Tools, MCP, A2A) und der Abwicklungsschicht (Zahlungsleitungen, Treuhand, Risikostandards).

2.1 Die sieben Primitiven

Das Protokoll ist definiert durch sieben Datenstrukturen und Funktionen, die eine signierte Absicht in eine abwickelbare Entscheidung umwandeln:

Obligation Object ( $O$ ): Ein signierter, maschinenlesbarer Vertrag, der die natürliche Sprachabsicht in ein strukturiertes Tupel überführt, welches Parteien, Aufgabenstellungen, Akzeptanzkriterien, Beweisanforderungen und eine Zulässigkeitsschwelle ( $\phi_O$ ) enthält.
Evidence Envelope ( $E$ ): Ein hash-verankerter Container für Ausführungshinterlassenschaften (Git-Diffs, Logs, Quittungen, Selbstberichte). Jedes Element trägt eine Provenienz-Kette und eine Zulässigkeitsklasse.
Verification Mesh: Ein konfigurierter Satz heterogener Verifizierer (Constraint-Prüfer, Quittungsverifizierer, semantische Richter, menschliche Schlichter). Jeder liefert ein Urteil, eine Konfidenz und eine deklarierte Beweisbasis ( $B_i$ ).
Clearing Decision ($CD$): Das strukturierte Urteil, das die Outputs des Mesh aggregiert. Es umfasst Status von Leistung/Policy, Schuldzuweisung, Verlustschätzungen und die aggregierte Beweisbasis.
Settlement Instruction ( $S$ ): Eine strukturierte Aktionsliste (Gebühr, Kapital, Sicherheiten, Strafmaßnahmen), die aus der Clearing-Entscheidung abgeleitet und auf spezifische Ausführungsleitungen gerichtet ist.
Clearing Passport: Ein transaktionsübergreifender Zuverlässigkeitsdatensatz für Agenten, Tools und Verifizierer, der nach jedem Clearing-Ereignis aktualisiert wird, um zukünftige Pre-Clearance und Verifizierer-Auswahl zu steuern.
Finality Rules: Ein Prädikat, das bestimmt, wann eine Settlement Instruction von PROVISIONAL (vorläufig) zu FINAL (endgültig) wird, basierend auf Zulässigkeitsschwellen, Konfidenzschwellen, Konfliktlösung und Berufungsfristen.

2.2 Die Admissibility-Graded Verification Mesh

Die Kerninnovation ist die partielle Ordnung der Zulässigkeit ( $\Lambda$ ). Beweise werden nicht durch einen Skalarwert klassifiziert, sondern durch eine partielle Ordnung aus sechs Klassen:

SELF: Unverifizierter Selbstbericht.
SIGN: Kryptografische Signatur (Nicht-Abstreitbarkeit, aber keine Wahrheit).
WIT: Signatur eines Drittzeugen.
REC: Nicht-interessierter externer Beleg/Quittung.
ATT: Attestierung durch eine Trusted Execution Environment (TEE).
PROOF: Kryptografischer Beweis der Korrektheit (z. B. zk-SNARK).

Entscheidend ist, dass WIT und REC inkomparabel sind, was unterschiedliche Vertrauensannahmen widerspiegelt. Die Klasse einer aggregierten Basis ist das Join ihrer Komponenten, während die Klasse der Basis eines einzelnen Verifizierers das Meet der von ihm genutzten Elemente ist.

2.3 Der Aggregator und die Soundness

Der Mesh Aggregator ( $\Gamma$ ) kombert die Verifizierer-Outputs mittels einer admissibility-gewichteten Mehrheit.

Floor Enforcement: Verifizierer, deren deklarierte Beweisbasis ( $B_i$ ) unter der Zulässigkeitsschwelle der Verpflichtung ( $\phi_O$ ) liegt, werden mit dem Gewicht Null zugewiesen.
Declared Basis Contract: Verifizierer müssen ehrlich deklarieren, welche Beweise sie genutzt haben. Fehlberichterstattung (Basis-Wäsche) ist eine adversarielle Klasse.
Soundness Property: Das Protokoll erzwingt eine falsifizierbare Eigenschaft: Keine finanziell materielle Settlement Instruction wird emittiert, es sei aus der aggregierten Beweisbasis die Zulässigkeitsschwelle der Verpflichtung erreicht oder überschritten wird.
$\text{Emit}(S) \implies \text{cls}(B) \succeq \phi_O$

2.4 Exposure-Driven Intensity

In der Pre-Clearance-Phase berechnet das Protokoll einen Exposure Score ( $X$ ) basierend auf Autoritätsrisiko, Value at Risk, Intent-Ambiguität, Irreversibilität, Agentenhistorie und Domänensensitivität. Dieser Score bildet auf eine gestufte Policy ( $K$ ) ab, die bestimmt:

Verifier Set: Von einzelnen deterministischen Verifizierern (LOW) bis hin zu Mesh + menschlichem Schlichter (CRITICAL).
Settlement Timing: Von sofortiger bis verzögerter Finalität.
Margin Requirement: Von keiner bis hin zu voller Besicherung.

3. Zentrale Beiträge

Formale Spezifikation von Clearing: Das Paper definiert Clearing nicht als Score oder Boolean Pass, sondern als eine Bestimmung, die durch die Zulässigkeit ihrer Beweise graduiert ist.
Soundness-Garantie: Es führt eine falsifizierbare Soundness-Eigenschaft ein, die sicherstellt, dass keine materielle Abwicklung auf unzulässigen Beweisen beruht. Dies unterscheidet RAILS von „Pass/Fail“-Systemen, numerischen Scores oder spieltheoretischen Gleichgewichten.
Admissibility Partial Order: Es schlägt ein nicht-skalares Modell der partiellen Ordnung für Beweise vor, das strukturelle Unterschiede im Vertrauen respektiert (z. B. die Unterscheidung zwischen einem Zeugen und einem Beleg).
Lifecycle State Machine: Es spezifiziert einen zehnstufigen Lebenszyklus (Discovery bis Finality) mit expliziten Reversibilitätsgrenzen und Eskalationspfaden (Human Arbiter, Appeal Window).
Integration in den bestehenden Stack: RAILS ist darauf ausgelegt, Inputs von bestehenden Protokollen (MCP, A2A, AP2, x402) zu konsumieren und Outputs in Settlement-Risiko-Standards einzuspeisen, wobei es als die fehlende „Clearing-Schicht“ im agentischen Stack fungiert.

4. Ergebnisse und Validierung

Das Paper validiert das Protokoll durch ein kanonisches Arbeitsszenario: ein Clearing-Ereignis für die Softwarelieferung, bei dem ein autonomer Coding-Agent einen Bug behebt, aber eine Abhängigkeitsrichtlinie verletzt.

Szenariodynamik: Der Agent fügt eine unautorisierte Abhängigkeit hinzu. Ein semantischer LLM-Judge wird durch den Selbstbericht des Agenten (ein SELF-Klasse Beweis) getäuscht und gibt ein PASS zurück.
Protokollausführung: Da der LLM-Judge seine Basis ehrlich deklariert (den SELF-Bericht), erkennt das Floor-Enforcement-Gate, dass die Basis unter der erforderlichen ATT (TEE-attestierten) Schwelle liegt.
Ergebnis: Das Urteil des LLM-Judges wird mit dem Gewicht Null belegt. Der Aggregator stützt sich auf andere Verifizierer (Constraint-Checker unter Verwendung von ATT-Klasse Git-Diffs), welche die Richtlinienverletzung korrekt identifizieren. Das Ergebnis ist ein Policy FAIL Urteil, welches die Freigabe von Geldern verhindert.
Bedeutung des Ergebnisses: Dies demonstriert, dass die Soundness des Protokolls auch dann hält, wenn ein Verifizierer „getäuscht“ wird, vorausgesetzt, der Verifizierer hält sich an den Vertrag, seine Beweisbasis ehrlich zu deklarieren. Das System erfordert nicht die Omniszenz des Verifizierers, sondern nur dessen Ehrlichkeit bezüglich seiner Inputs.

5. Bedeutung und Ansprüche

Das Paper behauptet, dass autonomes Agenten-Kommerz nicht skalieren kann, ohne einen neutralen Mechanismus, der Ausführungstraces in zulässige Beweise umwandelt und fundierte Settlement-Anweisungen emittiert.

Abgrenzung zu Vorarbeiten: Im Gegensatz zu „Verify-then-Pay“-Systemen, die einen Boolean Pass emittieren, oder „Challenge-Game“-Systemen, die auf rationalen Gleichgewichten basieren, emittiert RAILS eine falsifizierbare Behauptung über die Zulässigkeit der Beweise, die eine Abwicklung stützen.
Umfang der Soundness: Das Paper ist bescheiden hinsichtlich dessen, was Soundness bietet. Es garantiert, dass das Protokoll keine Settlement Instruction auf Basis unzulässiger Beweise emittiert. Es garantiert nicht die Wahrheit (Ground Truth), die Korrektheit der Verifizierer (Kalibrierung) oder die Ehrlichkeit der Attester. Es begrenzt, was das Protokoll emittieren kann, nicht was in der Welt wahr ist.
Positionierung: RAILS wird nicht als Ersatz für bestehende Protokolle (MCP, A2A, Payment Rails) präsentiert, sondern als die notwendige Clearing-Schicht, die diese bindet und das „Was ist passiert“ in ein „Was abgewickelt werden sollte“ transformiert.

Das Paper schließt mit der Feststellung, dass RAiel durch die Durchsetzung einer Zulässigkeitsschwelle und die Forderung nach einer ehrlichen Deklaration der Basis die strukturelle Integrität gewährleistet, die erforderlich ist, damit agentisches Kommerz von experimentellen Benchmarks zu realen, finanziell materiellen Verpflichtungen übergehen kann.