Drei-Wege-Commitment: Wie unser Stack Zahlungsabsicht, Ausfuehrungs-Transkript und Abrechnung in einen verifizierbaren Beleg bindet

Kernpunkte

• Ein Drei-Wege-Commitment hashht Zahlungsabsicht, Ausfuehrungs-Transkript-Digest und Abrechnungs-txid in einen Beleg — ein Prufer verifiziert jedes Element unabhaengig und bestaetigt, dass der kombinierte Hash alle drei abdeckt — das Commitment deckt alle Schritte ab oder keinen; es gibt keine Teilabdeckung (IETF draft-hopley-x402-retention-chain-06, 2026).
• Cross-Session-Replay wird durch Hash-Abweichung erkannt, nicht durch Richtlinie verhindert — weil binding_ref payment_hash UND action_ref zusammen hashht, erzeugt das Austauschen einer Zahlung aus Session A mit einer Ausfuehrung aus Session B einen anderen kombinierten Hash; der Verifizierer berechnet neu und erhaelt eine Abweichung (x402 GitHub issue #2332, 2026).
• MCP-Module erzeugen das Ausfuehrungs-Transkript nativ — jeder Tool-Aufruf (Vendor-Compliance-Pruefung, Supplier-Suche, Angebotserstellung) wird mit Argumenten, Ergebnissen und Zeitstempeln protokolliert; der Transkript-Digest ist action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp})), von jeder Partei mit den vier Feldern neu berechenbar (IETF draft-etcheverry-action-ref-02, 2026).
• Die x402-Abrechnung auf Base erzeugt payment_hash in ~200ms — der On-Chain-Transaktions-Hash ist unabhaengig verifizierbar durch Abfrage der Base-Blockchain; kein Vertrauen in den Operator oder Facilitator erforderlich (Chainalysis, 2026).
• Alle Konstruktionen verwenden SHA-256 und JCS (RFC 8785) — derselbe Kanonisierungsstandard, den der Hermes Agent Audit Trail verwendet (GitHub issue #487), sodass der Ausfuehrungs-Transkript-Digest vom Audit-System des Agenten selbst nativ erzeugt wird, nicht nachtraeglich angehaengt.

Das Problem: Jeden Schritt separat zu pruefen ist notwendig, aber nicht ausreichend

Der Sechs-Protokoll-Agent-Commerce-Stack (UCP, A2A, MCP, ACP, AP2, x402) deckt Discovery, Kommunikation, Tooling, Checkout, Autorisierung und Abrechnung ab. Jedes Protokoll erzeugt seinen eigenen Beweis: x402 erzeugt einen Zahlungs-Hash, MCP erzeugt ein Tool-Aufruf-Protokoll, AP2 erzeugt ein Autorisierungs-Mandat. Jeden Schritt separat zu pruefen ist notwendig — Sie muessen verifizieren, dass die Zahlung abgerechnet wurde, dass die Ausfuehrung stattfand und dass die Autorisierung gueltig war.

Aber getrennte Audit-Trails reichen nicht aus. Ohne Bindung kann ein Angreifer eine echte Zahlung aus Session A mit einer echten Ausfuehrung aus Session B mischen. Beide sind authentische Artefakte. Keines ist gefaelscht. Aber sie fanden nicht in derselben Session statt. Der Zahlungsbeleg beweist, dass eine Zahlung stattfand. Das Ausfuehrungsprotokoll beweist, dass ein Screening durchgefuehrt wurde. Ohne eine Bindung, die sie kryptografisch verknuepft, gibt es keinen Beweis dafuer, dass es sich um dieselbe Transaktion handelt.

Dies ist der Cross-Session-Replay-Angriff: Nehmen Sie einen echten payment_hash aus einer abgeschlossenen Transaktion und paaren Sie ihn mit einem echten action_ref aus einer anderen Transaktion. Wenn das Audit-System die Paarung vertraut, weil beide Artefakte individuell gueltig sind, akzeptiert es ein gefaelschtes Komposit. Der Audit-Trail zeigt eine abgerechnete Zahlung und ein durchgefuehrtes Screening — aber sie stammen aus verschiedenen Transaktionen.

Der Bindungsschritt ist der Punkt, an dem dieser Angriff erkannt wird — oder nicht.

Die Architektur: Wie unser Stack jede Komponente erzeugt

Das folgende Diagramm zeigt den vollstaendigen Drei-Wege-Commitment-Fluss — welches System welches Artefakt erzeugt, wie die Bindungsschicht sie komponiert und wie der Prufer sie verifiziert:

Wie jede Komponente in unserem Stack erzeugt wird

Zahlungsabsicht: das signierte x402-Angebot

Wenn der Agent eine kostenpflichtige Vendor-Compliance-Pruefungs-API aufruft, gibt der Server HTTP 402 mit einem signierten Angebot zurueck. Die offer-receipt-Erweiterung (in das x402-Protokoll integriert) verpflichtet den Server zu spezifischen Zahlungsbedingungen: amount, asset, payTo address, die exacte resource, die erfuellt wird, und ein Gueltigkeitsfenster. Das Angebot wird mit EIP-712 (Ethereum-Wallet-basiert) oder JWS (jeder asymmetrische Schluessel, einschliesslich Solana Ed25519) signiert.

Das Angebot ist die Zahlungsabsicht — wofuer der Agent zu zahlen im Begriff ist. Der Prufer hasht es unabhaengig:

offer_hash = SHA-256(JCS(signed offer terms))

Der Prufer berechnet dies aus den signierten Angebot-Bedingungen neu und verifiziert die Signatur des Servers. Kein Kontakt zum payment backend erforderlich — das Angebot ist ein portables, signiertes Artefakt.

Ausfuehrungs-Transkript: das MCP-Tool-Aufruf-Protokoll

Unsere MCP-Module verbinden den Agenten mit Vendor-Compliance-APIs, Supplier-Katalogen und Zahlungs-Rails. Jeder MCP-Tool-Aufruf wird protokolliert: welches Modul aufgerufen wurde, welche Argumente uebergeben wurden, welches Ergebnis zurueckkam, zu welchem Zeitstempel, unter welcher Richtlinienversion. Dies ist das Ausfuehrungs-Transkript.

Der Hermes Agent Audit Trail (GitHub issue #487) implementiert SHA-256-Hash-Chain-Aktions-Protokollierung mit RFC 8785 (JCS)-Kanonisierung — derselbe Standard, den action_ref und binding_ref verwenden. Der Ausfuehrungs-Transkript-Digest wird nativ vom Audit-System des Agenten selbst erzeugt:

action_ref = SHA-256(JCS({
  agent_id: "procurement-agent-001",
  action_type: "compliance.screen",
  scope: "vendor:acme-corp screening-type:sanctions",
  timestamp: "2026-07-31T19:45:23.482Z"
}))

Der Prufer berechnet action_ref aus diesen vier Preimage-Feldern neu. Kein Kontakt zum Agenten oder seinem Operator erforderlich. Die Kanonisierung ist durch RFC 8785 definiert, nicht durch den Serializer — sodass der Hash ueber Implementierungen hinweg deterministisch ist.

Das policy_bound_ref bindet die Richtlinienversion, die bei der Ausfuehrung der Aktion gueltig war. Wenn die Sanktionsliste zwischen Juni und Juli 2026 aktualisiert wurde, aendert sich der Richtlinien-Hash und der Prufer kann erkennen, welche Version aktiv war. Das gate_ref bindet das ALLOW/DENY-Urteil der Compliance-Pruefung an die Richtlinienreferenz, sodass das Ergebnis nachweisbar an die Regelversion gebunden ist, die es erzeugt hat.

Abrechnung: die on-chain txid auf Base

Der x402-Facilitator verifiziert die signierte Zahlungsautorisierung des Agenten, konstruiert die On-Chain-Transaktion und uebertraegt sie auf Base. Die Abrechnung wird in etwa 200ms abgeschlossen. Der Facilitator gibt den Transaktions-Hash (payment_hash) an den Server zurueck, der ihn im PAYMENT-RESPONSE-Header an den Agenten weitergibt.

Der Prufer verifiziert payment_hash durch Abfrage der Base-Blockchain — die txid ist ein oeffentlicher, unveraenderlicher Datensatz. Kein Vertrauen in den Facilitator oder das payment backend erforderlich. Der Prufer bestaetigt:

• Die Transaktion existiert auf Base
• Der amount entspricht den Angebot-Bedingungen
• Die payTo address entspricht dem Angebot
• Die Transaktion ist bestaetigt (nicht ausstehend)

Die Bindung: wie binding_ref alle drei komponiert

Das binding_ref (IETF draft-hopley-x402-retention-chain-06) komponiert alle drei Hashes in ein Commitment:

binding_ref = SHA-256(JCS({
  offer_hash,      // was versprochen wurde (Zahlungsabsicht)
  action_ref,      // was ausgefuehrt wurde (MCP-Transkript-Digest)
  payment_hash     // was abgerechnet wurde (on-chain txid)
}))

Dies ist ein Drei-Wege-Commitment. Der Prufer verifiziert jede Komponente unabhaengig:

1. offer_hash — neu berechnen aus den signierten Angebot-Bedingungen, Server-Signatur verifizieren
2. action_ref — SHA-256 neu berechnen aus den vier Preimage-Feldern, kein Kontakt zum Agenten
3. payment_hash — Base-Blockchain abfragen, bestaetigen dass txid existiert und abgerechnet ist

Dann berechnet der Prufer binding_ref aus allen drei neu und bestaetigt, dass es uebereinstimmt. Wenn eine Komponente ausgetauscht wird — eine Zahlung aus Session A mit einer Ausfuehrung aus Session B gepaart — wird der kombinierte Hash nicht uebereinstimmen. Das Commitment deckt alle drei Schritte ab oder keinen. Es gibt keine Teilabdeckung.

Wie Cross-Session-Replay erkannt wird

Der Cross-Session-Replay-Angriff funktioniert wie folgt: Ein Angreifer nimmt einen echten payment_hash aus einer abgeschlossenen Transaktion in Session A und paart ihn mit einem echten action_ref aus einer anderen Transaktion in Session B. Beide Artefakte sind echt. Keines ist gefaelscht. Aber sie fanden nicht in derselben Session statt.

Ohne Bindung prueft das Audit-System payment_hash und action_ref separat, findet beide gueltig und akzeptiert das Komposit. Der Audit-Trail zeigt eine abgerechnete Zahlung und ein durchgefuehrtes Screening — aber sie stammen aus verschiedenen Transaktionen.

Mit binding_ref berechnet der Prufer den kombinierten Hash aus dem tatsaechlichen payment_hash und action_ref im Beleg neu. Wenn der Angreifer eines aus einer anderen Session ausgetauscht hat, stammen die Hashes aus verschiedenen Preimage-Kontexten und der kombinierte binding_ref wird nicht mit dem Wert im Beleg uebereinstimmen. Der Verifizierer erkennt die Abweichung. Das Commitment deckt nicht alle Schritte ab, wird also abgelehnt.

Das ist es, was den Bindungsschritt zur Vertrauens-Primitiv macht: Er fuegt keinen neuen Beweis hinzu, er verknuepft vorhandenen Beweis kryptografisch. Der Zahlungs-Hash auf Base ist verifizierbar. Das Ausfuehrungsprotokoll ist verifizierbar. Der Bindungs-Beweis macht den Link zwischen ihnen verifizierbar. Ohne den Link ist jedes eine eigenstaendige Behauptung. Mit dem Link sind sie ein kombinierter Beleg, den ein Prufer Ende-zu-Ende verifizieren kann.

Was dies fuer die Konstruktion bedeutet

Ein Beschaffungs-Agent, der 85 Supplier pro Woche auf Compliance prueft, benoetigt das Drei-Wege-Commitment in seinem Audit-Trail. Die Implementierung in unserem Stack:

• MCP-Module erzeugen das Ausfuehrungs-Transkript. Jeder Tool-Aufruf wird mit Argumenten, Ergebnissen, Zeitstempeln und Richtlinienversion protokolliert. Der Transkript-Digest ist action_ref, nativ vom Hermes Agent Audit-System mit JCS-Kanonisierung berechnet.
• x402 behandelt die Abrechnung. Der Facilitator rechnet auf Base ab und gibt payment_hash zurueck. Die offer-receipt-Erweiterung signiert die Zahlungsabsicht bei der 402-Antwort.
• Die Audit-Schicht (nicht der Agent, nicht das payment backend) berechnet binding_ref aus offer_hash, action_ref und payment_hash. Sie berechnet auch policy_bound_ref und gate_ref zum Binden der Richtlinienversion und des Compliance-Urteils.
• Der Human-in-the-Loop-Kontrollpunkt bei der Zahlungsautorisierung sieht den kombinierten Beleg: Angebot-Bedingungen, Ausfuehrungsergebnis, Abrechnungsbestaetigung, Richtlinienversion und Urteil — alle durch binding_ref verknuepft.
• Ein externer Prufer (Regulierer, Gegenpartei, interne Compliance) verifiziert den kombinierten Beleg durch unabhaengige Neuberechnung jedes Hashes. Kein Kontakt zum Agenten, payment backend oder Audit-Schicht-Operator erforderlich.

Die Verifikation dauert Sekunden: Base nach der txid abfragen, action_ref aus vier Feldern neu berechnen, offer_hash aus den signierten Bedingungen neu berechnen, binding_ref aus allen drei neu berechnen. Das Commitment deckt alle Schritte ab oder keinen. Das ist die Primitiv, die Agent-Commerce Ende-zu-Ende pruefbar macht.

Weiterfuehrende Literatur

• Liquidation ohne Ausfuehrungsnachweis ist eine bezahlte Blackbox: Die Agent-Zahlungs-Audit-Schleife schliessen — die fuenf-Schritt-Audit-Schleife und die IETF-Entwuerfe, die binding_ref, policy_bound_ref und gate_ref definieren
• Wenn der Agent die Bestellung aufgibt: Wie agentische Zahlungen die B2B-Beschaffungsschleife schliessen — der Procure-to-Pay-Zyklus mit agentischen Zahlungsprotokollen (Mastercard Agent Pay, x402, Stripe agentic tokens)
• Kill-Switch by Design: Agent-Governance-Architektur — die Governance-Schicht, die entscheidet, wann ein Agent handeln darf und wann er anhalten muss
• MCP Security Hardening Checklist: 1,467 exponierte Server und die Kontrollen, die sie schliessen — OWASP MCP08 (Lack of Audit and Telemetry) und die Kontrollen, die es schliessen

---

Ein Mid-Market-Distributor, der einen Agenten betreibt, der 85 Supplier pro Woche auf Compliance prueft, benoetigt mehr als getrennte Audit-Trails. Er benoetigt ein Drei-Wege-Commitment, das das Versprochene (das signierte Angebot), das Ausgefuehrte (das MCP-Transkript) und das Abgerechnete (die on-chain txid) in einen Beleg bindet. Ein Prufer berechnet jeden Hash unabhaengig neu und bestaetigt dann, dass die Bindung alle drei abdeckt. Cross-Session-Replay wird durch Hash-Abweichung erkannt, nicht durch Richtlinie verhindert. Das ist die Architektur, die wir konstruieren: MCP-Module erzeugen das Transkript, x402 erzeugt die Abrechnung, die Audit-Schicht komponiert die Bindung und der Verifizierer prueft alles, ohne irgendeiner Partei in der Kette zu vertrauen.

Fordern Sie eine begrenzte Konstruktion an. Einwoechige Discovery. Sie erhalten ein Systeminventar, eine Workflow-Karte und einen festen Umfang — ob Sie mit uns bauen oder nicht.