What is a consent receipt?
A consent receipt is a portable proof object that makes user permission for AI-agent actions verifiable. It’s designed to produce a transaction-time YES/NO decision and to survive disputes, audits, and degraded environments.
Definition
A consent receipt is machine-verifiable evidence that a user delegated a specific scope of actions to a specific agent under explicit constraints.
Purpose
Make permission enforceable at the moment of transaction and provable later—without relying on screenshots, narrative logs, or long-lived sessions.
What problems consent receipts solve
- Issuer authorization evidence: prove a delegated agent was in-scope when you approved an authorization.
- Merchant checkout trust: verify agent permission before you create the order or release value.
- Consent disputes: answer “did the user allow this?” with a verifiable object, not a UX screenshot.
- Offline / edge: keep verification meaningful when connectivity drops.
Consent receipt vs OAuth vs “terms accepted”
OAuth and terms acceptance are often broad and session-like. Consent receipts are designed for transaction-scoped permission and binary decisioning.
OAuth scopes answer: “can this client call this API?”
Consent receipts answer: “is this agent allowed to perform this action for this transaction under these limits right now?”
Required fields (minimum viable receipt)
To be useful under real issuer/merchant scrutiny, the receipt must be unambiguous.
- delegator: who granted permission (pseudonymous identifier is fine)
- agent: which agent is authorized (identifier + key binding)
- scope: allowed actions (e.g.,
payment.authorise,book) - constraints: amount/currency, merchant/category, channel, time window
- expiry + revocation semantics
- signature/proof: who issued it and how verifiers validate it
- receipt_id + nonce: replay-safe verification for payment-like actions
How verification works (transaction time)
Verification takes the receipt + proposed transaction context and returns a deterministic result.
{
"input": {
"receipt": "…",
"context": {
"action": "payment.authorise",
"amount": 4200,
"currency": "GBP",
"merchant": "m_123",
"timestamp": "2026-03-18T12:00:00Z"
}
},
"output": {
"eligible": true,
"proof": "sha256:…",
"reason": "in_scope"
}
}
Where AffixIO fits
AffixIO is a stateless verification and decision layer. It’s designed for transaction-scoped checks that produce a YES/NO outcome and a proof object—usable by issuers, merchants, and agent platforms.
- How businesses verify user consent
- Issuer-side AI agent authorization
- Merchant-side verification at checkout
FAQ
Is a consent receipt legally “enough”?
It’s not legal advice, but for payments/compliance teams the key is whether you can produce defensible evidence: who delegated, what scope, what constraints, and a verifiable transaction-time decision record.
Does this require storing PII?
No. Consent receipts can be privacy-preserving via pseudonymous IDs, minimal fields, and proofs that avoid retaining raw personal data.
How do you handle revocation?
Verification must check revocation state at the moment of transaction (online) or apply freshness windows/offline policies that limit drift until reconnect.