Proof of permission
Proof of permission is the category name AffixIO is here to own. It means you can verify—at transaction time—that an AI agent was permitted to act under explicit constraints, and you can store portable evidence of the YES/NO decision.
Permission artifact
Something concrete: consent receipt or delegation record—not a vague “user agreed.”
Transaction context
Amount, merchant/category, channel, time window—so permission can be evaluated precisely.
Proof record
A loggable output: YES/NO + proof hash/ID + policy version + evaluated context.
Why this matters in payments/compliance
When an agent initiates payments, disputes change shape: you’re not proving who clicked a button. You’re proving the agent acted within delegated scope at the moment of transaction. Proof of permission is the evidence standard that makes that defensible.
What “proof” looks like (minimal)
{
"eligible": true,
"agent_id": "agt_123",
"permission_ref": "cr_456",
"policy_version": "pv_2026_03",
"proof": "sha256:…",
"evaluated_context": { "amount": 4200, "currency": "GBP", "merchant": "m_001", "action": "payment.authorise" }
}
Common failure modes (what to avoid)
- Screenshot consent: can’t be verified by third parties.
- Broad tokens: don’t encode constraints; drift over time.
- No replay control: permission artifacts can be reused.
- Unversioned policies: you can’t explain which rules were applied later.
Internal links
- Verify AI agent transactions
- Stateless verification
- Consent receipts and definition
- Consent receipt spec
FAQ
Is proof of permission the same as authentication?
No. Authentication identifies an actor. Proof of permission proves the actor is allowed to perform this specific action under constraints at this moment.
Do we need zero-knowledge proofs for this?
Not always. The key is verifiable evidence without unnecessary data exposure. ZK can be useful for privacy-preserving checks, especially for consent and compliance.