AI-agents die betalen: waarom een handtekening onder een machtiging niet genoeg is

AI-agents die namens een gebruiker betalingen uitvoeren, zijn geen sciencefiction meer. Google's Agent Payments Protocol (AP2) laat LLM-gedreven shopping-agents transacties autoriseren en uitvoeren namens gebruikers. Maar de beveiliging van dat protocol kent een fundamentele blinde vlek: de ondertekende Checkout- en Payment Mandates beschermen de integriteit van transactiedata ná ondertekening, niet de context die vóór autorisatie is gevormd.

De kernvraag is niet of een agent-technologie werkt, maar of de beveiligingsarchitectuur de juiste grens trekt. Een systematische security-analyse van AP2 v0.2 (arXiv:2608.23858) beantwoordt die vraag ontkennend. De analyse modelleert de volledige transactie-lifecycle in vijf fasen, identificeert vijf deployment-architecturen, en bouwt met het MAESTRO-framework een catalogus van 48 dreigingen over vijf aanvalsfamilies. Acht daarvan bereiken de hoge band in minstens één architectuur.

Formeel: de beschermingsgrens van een mandate

Om de kwetsbaarheid scherp te krijgen, definiëren we de integriteitsclaim van een payment mandate formeel. Laat een transactie T worden bepaald door een reeks van n fasen vóór autorisatie en m fasen ná autorisatie:

T = f(A₁, A₂, ..., Aₙ, M, S₁, S₂, ..., Sₘ)

waarbij Aᵢ de pre-autorisatie inputs zijn, M de ondertekende mandate, en Sⱼ de post-signing outputs. De handtekening σ(M) beschermt alleen de integriteit van M en de Sⱼ-fase:

Integrity(σ(M)) ⟹ (M ongewijzigd) ∧ (S₁..Sₘ gebonden aan M)

De kritieke observatie is dat σ(M) niets zegt over de A₁..Aₙ-fase:

Integrity(σ(M)) ⇏ (A₁..Aₙ reflecteren gebruikersintentie)

Een attacker die de pre-autorisatie context (A₁..Aₙ) manipuleert, kan de agent een transactie laten autoriseren die semantisch anders is dan wat de gebruiker bedoelde, terwijl de handtekening cryptografisch geldig blijft. Dat is de kernstelling.

H1, de pre-auth-context-hypothese. Een geldige mandate-handtekening garandeert niet dat de agent-gemedieerde transactie de intentie van de gebruiker weerspiegelt wanneer de pre-autorisatie context is gemanipuleerd.

H1 is falsifieerbaar. De hypothese faalt wanneer kan worden aangetoond dat er een cryptografische binding bestaat tussen de pre-autorisatie inputs en de mandate, zodanig dat elke manipulatie van A₁..Aₙ detecteerbaar is door de gebruiker vóór autorisatie. De analyse toont aan dat deze binding ontbreekt.

De vijf levenscyclus-fasen en vijf deployment-architecturen

De auteurs verdelen de transactie-lifecycle in vijf fasen, van initiatie tot settlement. Elke fase heeft een eigen trust boundary. De vijf deployment-architecturen variëren in waar de agent, de wallet, de merchant en de payment provider zich bevinden en hoe ze vertrouwen.

Die scheiding is methodologisch belangrijk. Een dreiging die in architectuur A een lage score krijgt, kan in architectuur B hoog scoren omdat de trust boundary anders ligt. Dit leidt tot een tweede hypothese.

H2, de deployment-conditionaliteitshypothese. De ernst van een AP2-dreiging is niet inherent aan de dreiging zelf, maar afhankelijk van de deployment-architectuur waarin zij zich manifesteert.

H2 wordt ondersteund door de AIVSS-scores: acht dreigingen bereiken de hoge band in minstens één architectuur, wat impliceert dat dezelfde dreiging in andere architecturen lager scoort. De praktische consequentie is dat een generieke "AP2 is veilig" of "AP2 is onveilig" uitspraak zinloos is zonder architectuur-specificatie.

De aanvalsvectoren buiten de mandates

De pre-autorisatie fase wordt gevormd door externe inputs. Drie categorieën zijn dominant:

• Agent-to-Agent Protocol (A2A) berichten: communicatie tussen agents die de transactie vormgeven vóór autorisatie
• Model Context Protocol (MCP) tool calls: externe input die via tools de agent-context injecteert
• Prompt-injectie: kwaadaardige instructies die de agent een andere transactie laten autoriseren dan bedoeld

AP2 v0.2 lost enkele problemen uit v0.1 op (replay- en prompt-injectie-aanvallen), maar voegt tegelijkertijd capabilities en deployment-aannames toe die de attack surface vergroten. Elke nieuwe capability is een nieuw punt waar pre-autorisatie context kan worden gemanipuleerd.

Het dreigingsmodel: MAESTRO en AIVSS

De analyse gebruikt MAESTRO (Multi-Agent Environment, Security, Threat, Risk, Outcome) om de dreigingsruimte systematisch te modelleren:

Dimensie	Aantal
Dreigingsactoren	4
Aanvalsoppervlakken	11
Adversary capabilities	18
Attacker goals	6
Totaal dreigingen	48
Aanvalsfamilies	5

Elke dreiging wordt gescoord met AIVSS (Artificial Intelligence Vulnerability Scoring System). Acht dreigingen bereiken de hoge band in minstens één architectuur.

Omdat er geen complete publieke AP2-deployment beschikbaar was, bouwden de onderzoekers een testbed dat alle vijf architecturen dekt, met vijf proof-of-concept demonstraties voor alle acht hoog-risico dreigingen en hun mitigaties. Ze ontwikkelden ook een deployment-aware scanner die drie check-typen combineert:

• Statische checks: code- en config-analyse
• Cross-role consistentie checks: verifiëren dat rollen geen inconsistente bevoegdheden claimen
• Adversarial checks: actieve tests van bekende aanvalspaden

Wat dit betekent voor Nederlandse organisaties

Voor organisaties die AI-agents integreren met betalingssystemen (fintech, overheid, e-commerce) is dit een directe waarschuwing. Bestaande PSD2-assessments dekken geen AI-agent-specifieke aanvalsvectoren. De pre-autorisatie fase, waarin externe input de transactie vormgeeft, valt buiten de scope van traditionele betalingsbeveiliging.

Onder de EU AI Act en GDPR Artikel 32 (beveiliging van verwerking) moeten organisaties aantoonbaar passende technische maatregelen nemen. Een agent die betalingen uitvoert zonder dreigingsmodellering voor de pre-autorisatie fase, heeft een structurele blinde vlek die onder Artikel 32 niet verdedigbaar is.

Een minimale gate-set voor agent-betalingen

Op basis van de analyse stellen we een minimale gate-set voor organisaties die agent-gemedieerde betalingen overwegen:

Gate	Te bewijzen eigenschap
G1, Intent-binding	De transactie is cryptografisch of logisch gebonden aan de expliciete gebruikersintentie, niet aan de laatste model-inferentie
G2, Pre-auth integriteit	A2A-berichten en MCP-tool-outputs die de transactie vormen, zijn verifieerbaar en niet-manipuleerbaar
G3, Architecture-specificatie	Het dreigingsmodel is per deployment-architectuur opgesteld, niet generiek
G4, Prompt-injectie resistentie	De agent kan geen betalingsinstructies aannemen uit onvertrouwde content
G5, Post-signing verificatie	Na autorisatie wordt geverifieerd dat de daadwerkelijke transactie overeenkomt met de getekende mandate

Conclusie

De les is helder: valid mandate signatures zijn noodzakelijk maar niet voldoende. De beveiliging van agent-gemedieerde betalingen moet de volledige transactie-lifecycle omvatten, inclusief de pre-autorisatie context die door externe input wordt gevormd. Organisaties die AI-agents aan betalingsinfrastructuur koppelen, moeten hun dreigingsmodel uitbreiden naar de agent-specifieke aanvalsvectoren die dit protocol blootlegt.

De H1-hypothese, dat een geldige handtekening geen garantie is voor gebruikersintentie, is de kern die elke compliance-assessor moet toetsen. Zonder pre-auth integriteit is een betalende AI-agent een onbeheerde betalingsbevoegdheid met een cryptografische schijn van veiligheid.

Beperkingen

De analyse is gebaseerd op een preprint en een testbed, niet op een productie-deployment. De acht hoog-risico dreigingen zijn gevalideerd in gecontroleerde omstandigheden; de generaliseerbaarheid naar specifieke productie-architecturen vereist per-deployment analyse. De AIVSS-scores zijn een relatieve, geen absolute maatstaf. H2 is ondersteund door de architectuur-specifieke scores maar vereist bredere empirische validatie.

Bronnen

1. Aviv, Gandh, Bitton, Shabtai, Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2), arXiv:2608.23858, ingediend 24 aug 2026.