🤖 AI

Zero-Trust Runtime Verification for Agentic Payment Protocols: Mitigating Replay and Context-Binding Failures in AP2

Dit artikel stelt een zero-trust runtime-verificatieframework voor en evalueert dit voor het Agent Payments Protocol (AP2), dat gebruikmaakt van dynamische nonces en consume-once-semantiek om replay- en context-binding-aanvallen in autonome betalingssystemen effectief te mitigeren, terwijl een hoge doorvoer en lage latentie behouden blijven.

Oorspronkelijke auteurs: Qianlong Lan, Anuj Kaul, Shaun Jones, Stephanie Westrum

Gepubliceerd 2026-02-09

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Qianlong Lan, Anuj Kaul, Shaun Jones, Stephanie Westrum

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een wereld voor waarin je persoonlijke AI-assistent zo vertrouwd is dat hij naar de winkel kan gaan, boodschappen kan uitkiezen en ze allemaal zelfstandig kan betalen, zonder dat je telkens een kaart hoeft te scannen of een wachtwoord hoeft in te voeren. Dit is de toekomst van "Agentic Payments" (Agent-betalingen).

Het geven van zoveel vrijheid aan een AI creëert echter een nieuw soort beveiligingsprobleem. Dit artikel, geschreven door onderzoekers van eBay, onderzoekt hoe deze AI-transacties veilig te houden wanneer de boel chaotisch wordt, zoals wanneer de AI per ongeluk probeert hetzelfde item twee keer te betalen of in de war raakt over in welke winkel hij is.

Hier is de uitleg van hun oplossing met eenvoudige analogieën.

Het Probleem: Het "Magische Ticket" dat nooit verloopt

Momenteel is er een nieuw systeem genaamd AP2 (Agent Payments Protocol). Zie dit als een Magisch Ticket (een cryptografisch mandaat) dat een gebruiker aan zijn AI geeft.

Hoe het werkt: Het ticket zegt: "Je mag een shirt van $50 kopen bij Winkel A." Het heeft een digitale handtekening (zoals een lakzegel) om te bewijzen dat het echt is, en een vervaltijd.
De Fout: In de oude dagen moest je er zelf zijn om het shirt te kopen. Nu opereert de AI op eigen houtje.
- De Glitch: Als de AI een "timeout"-fout krijgt, kan de AI direct proberen hetzelfde Magische Ticket opnieuw te gebruiken (een Replay Attack).
- De Verwarring: Als de AI verschillende taken tegelijk uitvoert, kan hij per ongeluk proberen het "Shirt-Ticket" te gebruiken om een "TV" te kopen bij een andere winkel (een Context-Binding Failure).

Het artikel stelt dat de huidige regels (het protocol) ervan uitgaan dat de AI perfect is en geen fouten maakt. Maar in de echte wereld proberen AI-agents dingen opnieuw, voeren taken parallel uit en raken ze in de war. Het "Magische Ticket"-systeem heeft geen manier om deze fouten te voorkomen voordat ze beveiligingslekken worden.

De Oplossing: De "Zero-Trust Gatekeeper"

De auteurs stellen een nieuwe beveiligingsbewaker voor genaamd de Zero-Trust Runtime Verifier (ZTRV). Zie dit als een uitsmijter bij een zeer strikte club die tussen de AI en de winkel staat.

In plaats van het Magische Ticket te vertrouwen simpelweg omdat het een lakzegel heeft, controleert de uitsmijter elke keer dat de AI probeert binnen te komen twee specifieke zaken:

De "Eenmalig Gebruik" Stempel (Consume-Once):
- Stel je voor dat de uitsmijter elke keer dat je een ticket probeert te gebruiken, het ticket een unieke, tijdsgevoelige code stempelt.
- Als de AI datzelfde ticket opnieuw probeert te gebruiken (zelfs per ongeluk), ziet de uitsmijter de stempel en zegt: "Nee, dit ticket is al gebruikt. Je kunt niet naar binnen."
- Dit voorkomt dat de AI per ongeluk hetzelfde item twee keer betaalt.
De "Context Check" (Binding):
- De uitsmijter controleert het ticket tegen de huidige situatie.
- Als het ticket zegt "Koop een shirt bij Winkel A", maar de AI staat op dat moment voor "Winkel B" of probeert een "TV" te kopen, dan zegt de uitsmijter: "Verkeerde context! Dit ticket komt niet overeen met wat je nu aan het doen bent."
- Dit voorkomt dat de AI per ongeluk een ticket dat bedoeld was voor één taak, gebruikt voor een totaal andere taak.

Hoe ze het hebben getest

De onderzoekers bouwden een simulatie om te zien hoe deze "Gatekeeper" presteert onder druk.

De Stress-test: Ze simuleerden een chaotische omgeving waarin duizenden AI-agents op exact hetzelfde moment transacties probeerden te doen (tot wel 10.000 per seconde).
Het Resultaat:
- Het oude systeem (zonder de Gatekeeper) liet 100% van de valse of foutieve transacties door.
- Het nieuwe systeem (met de Gatekeeper) blokkeerde 100% van de slechte transacties.
De Snelheid: De Gatekeeper was ongelooflijk snel. Het voegde slechts ongeveer 3,8 milliseconden (minder dan een knipoog) toe aan de transactietijd, zelfs toen het systeem extreem druk was.

Waarom dit belangrijk is

Het artikel concludeert dat je niet alleen kunt vertrouwen op de "regels geschreven op het ticket" (het protocol). Je hebt een runtime check nodig (de Gatekeeper) die in realtime ziet wat de AI daadwerkelijk doet.

Ze ontdekten ook dat dit systeem niet de geschiedenis van elke enkele transactie hoeft te onthouden. Het hoeft alleen te onthouden wat er nu gebeurt (piek-concurrency). Dit betekent dat het systeem snel blijft en niet wordt vertraagd door een enorme database met oude gegevens.

Kortom: Om AI-agents veilig geld te laten uitgeven, hebben we een beveiligingsbewaker nodig die controleert of het ticket voor het juiste doel wordt gebruikt, op de juiste plek, en slechts één keer, terwijl hij net zo snel beweegt als de AI zelf.

Technische Samenvatting: Zero-Trust Runtime Verificatie voor Agentic Betalingsprotocollen

1. Probleemstelling

De implementatie van autonome AI-agents die in staat zijn om commerciële transacties uit te voeren, heeft een verschuiving noodzakelijk gemaakt van interactieve, sessiegebaseerde autorisatie naar mandaatgebaseerde protocollen, specifiek het Universal Commerce Protocol (UCP) en het Agent Payments Protocol (AP2). Hoewel AP2 garanties op specificatieniveau biedt—zoals cryptografische integriteit, authenticiteit en expiratiesemantiek—leunen deze garanties op aannames die de complexe runtime-gedragingen van autonome agents abstraheren.

In real-world agentic omgevingen vertonen systemen gedragingen zoals automatische retries, parallelle taakuitvoering, inter-agent delegatie en observability-gestuurde replays. Deze dynamiek introduceert temporele en contextuele complexiteiten die de impliciete aannames over mandaatgebruik uitdagen. Specifiek identificeert het artikel een kloof tussen protocolontwerp en de runtime-realiteit: AP2-manden, hoewel cryptografisch geldig, kunnen misbruikt worden als ze meerdere keren binnen hun geldigheidsvenster worden geconsumeerd (replay) of worden omgeleid naar onbedoelde executiecontexten (context-binding falen). De auteurs stellen dat correctheid op specificatieniveau geen veilige executie garandeert in asynchrone, hoog-concurrente agent runtimes.

2. Methodologie en Systeemmodel

Om deze handhavingskloven aan te pakken, stellen de auteurs een Zero-Trust Runtime Verification (ZTRV) framework voor. Het systeemmodel bestaat uit drie entiteiten:

User Agent (A): Een autonome entiteit die een cryptografisch mandaat bezit.
Merchant Endpoint (M): De dienstverlener die de transactie uitvoert.
Runtime Verifier (V): Een vertrouwde middleware-component (die fungeert als een security gateway) gepositioneerd tussen de agent en de merchant.

De ZTRV werkt als een stateless verificatie gateway, aangevuld met minimale, tijdsgebonden state. Het handhaaft een strikte, fail-closed verificatiepijplijn waarbij alle mandaat-dragende verzoeken expliciete controles moeten passeren voordat ze de betalingsinfrastructuur bereiken.

Kernmechanismen

Het framework handhaaft beveiliging via twee primaire mechanismen:

Context-Aware Binding:
Elk mandaat is cryptografisch gebonden aan een specifieke runtime executiecontext. De verifier berekent een hash ( $H_{ctx}$ ) gebaseerd op executie-attributen (bijv. task.id, agent.id, merchant.id, scope) en vergelijkt deze met de hash die in de handtekening van het mandaat is ingebed. Elke mismatch resulteert in onmiddellijke afwijzing, wat voorkomt dat mandaten worden hergebruikt voor verschillende taken, agents of merchants.
Dynamic Consume-Once Nonce Registry:
Om replay-aanvallen te voorkomen (zowel binnen dezelfde context als cross-context), handhaaft het systeem "consume-once" semantiek. Elk mandaat bevat een unieke, dynamisch gegenereerde nonce. De verifier onderhoudt een sliding-window nonce registry (geïmplementeerd als een gedistribueerde datastructuur) om atomaire check-and-set operaties uit te voeren. Een nonce wordt slechts één keer geaccepteerd binnen zijn geldigheidsvenster ( $\Delta t$ ). Dit zorgt voor idempotente executie en voorkomt meervoudige consumptie van hetzelfde mandaat, zelfs onder hoge concurrentie.

Het verificatiealgoritme verloopt in vijf stappen: het parsen van het mandaat, het verifiëren van cryptografische handtekeningen en versheid (freshness), het valideren van contextintegriteit, het uitvoeren van atomaire nonce-consumptie, en tot slot het autoriseren van de aanvraag.

3. Belangrijkste Bijdragen

Het artikel levert de volgende specifieke bijdragen:

Threat Modeling: Het presenteert een systematisch dreigingsmodel voor AP2 mandaat-executie in autonome agent runtimes, waarbij specifieke dreigingen worden geïdentificeerd zoals Same-Context Replay (T1), Cross-Context Replay (T2), Context Leakage Induced Misuse (T3) en Observability-Based Replay (T4).
Identificatie van Handhavingskloven: De auteurs demonstreren dat de AP2-specificatie geen normatieve definities mist voor verifier-zijde, stateful executie-semantiek (bijv. consume-once handhaving en strikte executie-tijd context binding) die vereist zijn voor real-world agent retries en orchestratie.
Framework Design: Het introduceert het ZTRV-framework, dat expliciete context binding en consume-once semantiek afdwingt tijdens de executie, waarmee verder wordt gegaan dan statische uitgifte-eigenschappen.
Empirische Evaluatie: Door middel van simulatie-gebaseerde evaluatie demonstreert het artikel dat zowel context-bewuste binding als consume-once handhaving onderscheidende en complementaire mechanismen zijn; geen van beide is op zichzelf voldoende om alle klassen van mandaatmisbruik te voorkomen.

4. Experimentele Resultaten

Het framework werd geëvalueerd onder hoge concurrentieomstandigheden (tot 10.000 transacties per seconde) tegenover een baseline verifier die alleen standaard AP2-checks uitvoert (handtekening en expiratie).

Effectiviteit van Beveiliging: De ZTRV behaalde een interceptiepercentage van 100% over alle geëvalueerde aanvalsscenario's (replay en context-redirect aanvallen). In contrast hiermee faalde de baseline verifier om enige van de geteste aanvallen te onderscheppen.
Prestatie-overhead: Het framework behield een stabiele verificatie-latentie van ongeveer 3,8 ms bij piekdoorvoer. De overhead werd gedomineerd door cryptografische handtekeningverificatie, terwijl context binding en nonce registry operaties een verwaarloosbare extra kost veroorzaakten.
Schaalbaarheid: De studie naar opslagoverhead toonde aan dat de vereiste runtime state begrensd wordt door de piek-concurrentie in plaats van de cumulatieve transactiegeschiedenis. Zelfs met een 60-seconden nonce window bij 10.000 TPS bleef de geheugenvoetafdruk bescheiden (ongeveer 12 MB), wat wijst op geschiktheid voor cloud-native implementaties.
Ablatie-studies: Experimenten die de mechanismen isoleerden, bevestigden dat context binding alleen cross-context aanvallen voorkomt maar faalt tegen same-context replays, terwijl consume-once handhaving replays voorkomt maar faalt tegen context redirectie. Alleen de combinatie van beide mechanismen bood uitgebreide bescherming.

5. Betekenis en Claims

Het artikel claimt dat het voorgestelde framework de kritieke kloof overbrugt tussen protocolaannames en de runtime-realiteit in agentic betalingssystemen. Door autorisatie-eigenschappen af te dwingen tijdens de executie in plaats van enkel te vertrouwen op statische specificatie-niveau garanties, mitigeert ZTRV replay en context-binding falen zonder significante prestatie-overhead op te leggen.

De auteurs benadrukken dat hun aanpak deterministische beveiligingsgaranties biedt via cryptografische logica, wat het onderscheidt van heuristiek-gebaseerde fraudedetectiesystemen die gevoelig zijn voor false positives en negatives. Zij stellen dat robuuste runtime beveiliging voor agentic betalings-executie kan worden bereikt met minimale, voorspelbare overhead.

Het werk concludeert dat runtime handhaving moet worden beschouwd als een fundamenteel onderdeel van secure engineering voor autonome systemen. Er wordt opgemerkt dat hoewel ZTRV misbruik op de executie-laag aanpakt, het geen semantische aanvallen voorkomt (bijv. prompt injection die de intentie van een agent manipuleert) en ervan uitgaat dat de onderliggende cryptografische primitieven niet gecompromitteerd zijn. Toekomstig werk wordt gesuggereerd om de integratie van Trusted Execution Environments (TEEs) te verkennen om de verifier verder te harden.