Consumer-side encryption for AI agent purchases. Per-tier key derivation, registry witness mode, retention-enforced PII destruction.
Maya buys a $4.50 coffee. Her phone constructs a layered encrypted envelope around her order — name, payment method, delivery address. That envelope travels to the cafe. The cafe receives what it needs to make the coffee: item and amount. Maya's identity never crosses the network as plaintext.
After 30 days, the decryption key for her identity tier is destroyed — by the protocol, automatically, without anyone initiating it. No court order applied to the cafe can recover it. Not the cafe's payment processor. Not the registry. No one.
If Maya wants a refund 45 days later, only her device can re-derive the token that reconstructs her identity for the refund window. The cafe cannot start this. The registry cannot start it. Her device is the only door.
ABT-C v2 does not activate on every transaction. It activates when the consumer's device signals capability. The same merchant endpoints serve both paths.
create_checkout_session, and ACP REST /checkout route to standard Stripe checkout. No overhead. No ABT.abt_consumer_pubkey or abt_origin is present, the same endpoints route to /api/agent/v2/checkout. Consumer-side encryption activates.Origin signals accepted: abt_consumer_pubkey in request body · abt_origin in ABT envelope · AP2 PaymentMandate with ABT fields · UCP MCP abt_consumer_pubkey tool argument
ABT-C v2 is the live transaction architecture at CinematicCard.com. Every card purchase supports the ABT-C path alongside AP2, UCP MCP, A2A, and ACP — the full five-protocol stack. See CinematicCard's agent commerce page for all five protocols, or the ABT protocol overview for how ABT fits alongside the channel protocols.
ABT-C uses Ed25519 digital signatures for authentication of every event at every party. Per-event symmetric keys are derived via HKDF with the event identifier as salt and held in hardware-backed secure storage (Apple iOS Keychain, Android Keystore, or equivalent platform secure-storage). Envelope encryption is performed at the first-party endpoint before any ciphertext leaves the device or origin. Each tier authority’s ciphertext contains only that tier’s authored projection — information not relevant to a tier authority is authored out before encryption, not redacted after. The registry maintains a hash-chained log where each entry’s hash includes the prior entry’s hash, providing tamper-evident integrity across the chain. Forward-only tier activation: registration of a new tier authority causes inclusion of an active tier layer in subsequent envelopes only. Existing envelopes are not retroactively modified. Cryptographic boundary at the first party. Plaintext never moves. Per-tier projection authored at envelope construction. Registry-routed restoration requires structural participation by all three parties.
Cryptography researchers studying envelope encryption, tier-bounded ciphertext, deterministic key derivation, and signed receipt chains in AI agent commerce transactions.
Privacy researchers studying architectural privacy enforcement, unlinkability, purpose limitation, retention through cessation, and consumer-controlled key custody.
Consumer protection advocates seeking architectural alternatives to policy-based privacy enforcement. Cryptographic structural enforcement, not vendor trust.
Policy researchers examining cryptographic enforcement of storage limitation (GDPR Article 5(1)(e)), data minimization (GDPR Article 5(1)(c)), and consumer protection requirements.
AI agent commerce developers building consumer-side cryptographic authorization for ChatGPT, Operator, Perplexity, and other agentic shopping flows — as a consumer-side alternative to merchant-side authorization (ACP, AP2, Stripe SPT) and platform-issued credential schemes (Apple Pay agents, Visa Trusted Agent, Mastercard Verifiable Intent).