PAN und CVV gelangen in keiner Runtime in den Agent-Kontext — die Credential-Grenze wird von JWE-Wrapping (MPP) oder der Harness-Grenze (CUA) erzwungen.
Runtime 1 — MPP
Für Merchants die MPP sprechen:1
Intent approved
Standard-Intent-Flow mit gesetztem
expectedMerchant.2
Credential minten
POST /v1/mpp/credentials/mint (oder POST /v1/mpp/pay für One-Shot).3
Präsentieren
Merchant-Call mit
Authorization: Payment <cred>.4
Verifizieren
Merchant ruft
POST /v1/mpp/credentials/:id/verify mit ihrem Merchant-Key.transactions-Row auf Verify.
Runtime 2 — CUA
Für Merchants die nur ein Checkout-Form haben (CUA):1
Intent approved
Standard-Intent-Flow mit
expectedAmountEuros.2
Autofill-Token minten
POST /v1/cua/autofill-tokens returnt aft_* (30s TTL, single-use, Intent + Card + Merchant-Origin + Amount-Cap).3
An Harness übergeben
aft_id an deinen CUA-Harness über deinen eigenen internen Channel — nicht via LLM-Kontext.4
Harness löst ein + füllt
Harness ruft
GET /v1/cua/autofill-tokens/:id/redeem mit X-CUA-Harness-Secret, holt DPAN, füllt Form via CDP Input.insertText.5
LLM klickt Submit
LLM sieht nur
{ status: "filled", masked_last4: "1234" }. Merchant settlet.Runtime 3 — Direct API Execute (Legacy)
Für Server-zu-Server Flows wo Ovra das Gateway ist:targetUrl muss HTTPS und SSRF-safe sein. Ovra resolvet Credentials, executet den Merchant-Call via PCI-Proxy-Forward-Pull, returnt das Ergebnis.
Sicherheits-Layer
Runtime wählen
Weiter
MPP
Wire-Flow, Error-Matrix, Merchant-Onboarding.
CUA
Threat-Model, Harness-Grenze, JWKS-Prep.
Bezahlung
Die Pay-Säule-Übersicht.