Delegated payment permissions for AI agents

From human authentication to a spendable delegation

The user issues a delegation proof that binds: agent identity handle, instrument scope, merchant category constraints, spend caps, and an expiry. Each payment attempt carries a fresh nonce and references the delegation identifier.

Real deployments usually split “who may delegate” from “what the agent may do.” The first step is strongly authenticated; the second is a signed artifact with fields that do not rely on the merchant to interpret natural language. That separation is what keeps chargeback stories coherent.

1. Authenticate user to issuer — Establishes who may issue delegation (human authentication).
2. Mint delegation object — Signed structure with immutable scope fields.
3. Agent presents proof + attempt — Merchant and verifier check signature, freshness, and scope intersection.
4. Issuer authorizes — Authorization checks delegation, velocity, and policy—not “who clicked.”
5. Revocation — Short-lived tokens plus explicit revocation lists or epoch bumps prevent stale delegation.

Where current systems fail

• OAuth-style scopes without payment semantics — Fine for APIs, insufficient for money movement.
• Long-lived refresh tokens — Delegation without expiry explodes dispute surface.
• Merchant-only consent — If the issuer never sees delegation, chargeback narratives break.

The uncomfortable part for product teams is that delegation errors look like fraud from the outside—large charges, odd merchants—when they are often scope bugs. Strong delegation artifacts make that distinction legible instead of moral.

Risks and attack surfaces

• Scope creep — Agents that reinterpret natural-language instructions into broader purchases.
• Delegation theft — Stolen proof objects without nonce/replay controls.
• Confused deputy — Merchant redirects that trick the agent into a broader authorization.

How verification or authorization is enforced

Enforcement is cryptographic (signature on delegation), temporal (expiry + nonce), and logical (policy intersection). Authentication of the user happens once at delegation; subsequent steps are authorization against the delegation artifact.

Where stateless verification applies

Verifiers do not store user profiles. They validate signatures, delegation version, and replay windows—stateless with respect to PII, bounded operational state for nonces.

How AffixIO approaches this

Delegation for agents should look like what issuers already understand—scoped instruments, expiry, revocation—expressed in structures machines can verify. AffixIO emphasizes short-lived proofs and explicit revocation paths because the failure mode users actually hit is “I turned that off and something charged anyway.”

• Allow/deny with reasons — Merchants get outcomes they can act on; issuers retain the narrative.
• Minimal persistent identity — Evidence travels with the attempt; verifiers do not need a CRM row per user to say “valid proof.”
• External eligibility without data sprawl — Validators answer narrow questions; they are not a licence to exfiltrate profiles.
• Offline-aware freshness — Terminals and edge nodes can enforce what is locally checkable and sync the rest honestly.

Where this fits in agentic commerce

What this system does not solve

Delegation cannot fix a compromised user account at issuance. It does not judge whether the user’s verbal instruction to the agent was ethical—only whether the attempt matches signed scope.

Further reading

• Agent wallet authorization
• Authorization model
• Consent proof architecture
• Machine authorization vs authentication
• Reference architecture
• Agent permissions product