How Businesses Verify User Consent for Agentic Transactions
When an AI agent acts on behalf of a user, businesses need verifiable evidence that the user actually consented. A consent receipt provides that evidence: signed, scoped, and constrained.
In This Guide
Why Consent Verification Matters · What Must Be in a Consent Receipt · Consent Verification at Transaction Time · Consent vs. Terms Acceptance · Revoking Consent
Trust Signals & Evidence
Author: AffixIO (Kris & Becca Richens). See What is AffixIO.
Method: Consent verification converts “user intent” into a cryptographic receipt, then verifies that receipt at transaction time (signature, scope, constraints, expiry, and anti-replay).
Privacy: Stateless verification by design; no PII stored. See Privacy Policy.
Last updated: March 18, 2026
Further reading: consent receipts, consent framework, NIST Digital Identity.
Consent Verification Checklist (At Transaction Time)
When the agent presents a receipt, verify it meets the following requirements:
- Signature validity — issuer signature verifies (receipt was not tampered with).
- Scope match — the requested action is allowed by
consent_scope. - Constraint match — amount, merchant/category, currency, and time window are within receipt limits.
- Expiry — receipt has not expired (online/offline freshness policy).
- Revocation/TTL policy — receipt has not been revoked and revocation/TTL controls are satisfied.
- Anti-replay — receipt nonce has not been used before.
- Evidence output — return a binary result and reason codes suitable for audit/disputes.
See also: authorization model for how consent is combined with issuer policy.
Consent Verification Graph (Transaction Time)
This graph summarizes what a verifier checks to decide whether consent evidence is valid for a proposed agent action:
Field semantics and replay rules are defined in the consent receipt spec.
Consent Failure Modes
| Failure mode | Evidence checked | Typical decision reason |
|---|---|---|
| Missing receipt | Receipt presence | RECEIPT_MISSING |
| Invalid receipt signature | Receipt signature | INVALID_SIGNATURE |
| Receipt out of validity window | Expiry (and optional not-before) | EXPIRED_RECEIPT |
| Scope mismatch | Consent scope | SCOPE_NOT_ALLOWED |
| Constraint mismatch | Amount/currency/merchant/category/time limits | CONSTRAINT_VIOLATION |
| Replay detected | Nonce / anti-replay state | REPLAY_DETECTED |
| Revocation model not satisfied | Revocation lists / TTL policy controls | REVOKED_OR_TTL_EXPIRED |
Why Consent Verification Matters
Without verifiable consent, businesses face:
- Dispute risk — Users claim they never authorized the transaction
- Compliance exposure — Regulators require evidence of consent for financial transactions
- Fraud liability — Unauthorized agent actions create financial and reputational risk
Consent receipts solve this by producing machine-verifiable evidence at the moment of delegation. See consent receipts for the full model.
What Must Be in a Consent Receipt
A valid consent receipt contains:
- Delegator ID — Pseudonymous identifier for the consenting user
- Agent ID — The agent receiving permission
- Scope — Allowed actions (pay, book, cancel, etc.)
- Constraints — Amount limits, merchant restrictions, time windows, geographic restrictions
- Nonce — Unique value for replay protection
- Signature — Cryptographic proof of issuance
- Expiry — When the consent expires
See the consent framework for implementation details.
Consent Verification at Transaction Time
When the agent presents a transaction, the verifier checks the consent receipt against the transaction context:
Consent vs. Terms Acceptance
| Aspect | Terms Acceptance | Consent Receipt |
|---|---|---|
| Scope | Broad (everything) | Per-action, per-constraint |
| Evidence type | Timestamp + checkbox | Signed proof object |
| Verifiable at transaction time | No | Yes |
| Replay protection | No | Yes |
| Offline verification | No | Yes |
See also: OAuth vs. consent receipts.
Revoking Consent
Consent can be revoked by the user at any time. Revocation is handled by:
- Expiry — Receipts have a built-in expiry timestamp
- Revocation list — Issuer maintains a revocation list checked at verification time
- Short TTL — Issuing receipts with short time-to-live (e.g., 1 hour) limits exposure
Ready to implement?
Explore the reference architecture or request a technical walkthrough.
Frequently Asked Questions
By checking the consent receipt: signature authenticity, scope match, constraint compliance, and replay status. The receipt is machine-verifiable evidence of user consent.
Without a valid consent receipt, the transaction is rejected. The receipt is the only acceptable evidence of consent.
Yes. Via expiry, revocation lists, or short TTLs. Once revoked or expired, the receipt fails verification.