Delegated Payment Authorization: How AI Agents Spend Without Card Credentials

TL;DR

In a delegated authorization model, an AI agent doesn't hold a credit card credential — it holds a delegation token that proves it's allowed to spend under specific conditions. The platform resolves the delegation to a card at transaction time and enforces the policy in the auth path. Card data never touches the agent.

What's the problem with giving an agent the card directly?

Three failures, in production:

1. Credential leakage. An agent is software running in environments your security team can't fully control. Logs, memory dumps, error reports, model outputs — any of these can leak a PAN.

2. Revocation is broken. If you give the agent a card and want to revoke its authority, you have to terminate the card. That triggers reconciliation churn (in-flight refunds, voided auths, settlement gaps). Delegation is revocable without touching the card.

3. No scope. A card is a binary credential — either it works or it doesn't. Delegations carry scope (this merchant set, this budget, this expiration). Granular control comes from the delegation, not the card.

How does delegated auth actually work?

Five components:

  1. The user delegates spending authority to the agent via a consent flow. The delegation specifies scope (budget, merchants, expiration, geo).
  2. The platform issues a delegation token tied to a specific card and a specific policy version.
  3. The agent holds the token, not the card. When checking out, the agent passes the token to the platform's checkout SDK or API.
  4. The platform resolves the token to a tokenized PAN at transaction time and submits the auth.
  5. The policy engine evaluates the auth against the policy version the delegation was issued under. Approved auths execute; declines return reason codes.

The card credential never leaves the platform. The agent never sees PAN/CVV/expiry. Revocation is one delegation update — no card lifecycle work.

What about the network rails — does delegation work there?

Visa and Mastercard have both shipped delegated authentication / trusted-beneficiary frameworks. These let the issuer mark a transaction as pre-authenticated under a delegation, satisfying SCA without a 3DS challenge.

In practice for agents:

This is recent — most issuing-only stacks haven't operationalized it yet. Platforms with delegation-first design ship it as default.

What's in the delegation token?

Conceptually:

{
  "delegation_id": "del_abc123",
  "agent_id": "agt_xyz789",
  "user_id": "usr_456",
  "card_id": "crd_789",
  "policy_id": "pol_def",
  "policy_version": 7,
  "scope": {
    "max_per_transaction": 50000,
    "budget_remaining": 180000,
    "allowed_mccs": ["3000-3299", "7011"],
    "geo_allow": ["US", "CA", "GB"]
  },
  "expires_at": "2026-12-31T23:59:59Z",
  "revoked_at": null
}

The token is opaque to the agent — it just carries it. The platform validates and decodes it on every auth.

How does revocation work?

User-initiated: the user revokes the delegation in their settings. The platform marks revoked_at, and the next auth using that token fails.

Agent-publisher initiated: the publisher revokes via API for a specific agent. Same effect.

Emergency-stop at the policy level: one toggle revokes all delegations under a policy. Useful for incident response.

Time-based: delegations have an expires_at. After that, auths fail without explicit revocation.

In all cases, revocation is sub-second from API call to network refusal — much faster than terminating a card.

What does this look like at scale?

A publisher with 10,000 active agents typically has:

Indexing on delegation_id + policy_version is critical. Common access patterns:

FAQ

Doesn't this just push the credential problem into the platform?

Yes — and that's the point. The platform is built to vault credentials with PCI-grade controls. A general agent product isn't. Delegation centralizes the high-risk surface in the part of the stack that's hardened for it.

What if the platform leaks the token instead?

A leaked token is bounded by the delegation's scope. The damage is capped at "one agent, one budget, one card, one merchant set." Compare to a leaked PAN with no policy — unbounded.

Can I revoke just one charge instead of the whole delegation?

Sort of — you can refund the charge, which produces a credit and reverses the ledger. But "blocking a single future charge under an active delegation" requires modifying the delegation's scope (e.g. shrink the budget or add a merchant block). Atomic to a single transaction isn't a natural primitive.

Does delegation work for one-off agents that won't re-spend?

Yes. Issue a single-use delegation tied to a single-use card. Both expire after the one charge. Common pattern for shopping-cart agents.

What's the difference between this and an OAuth scope?

Conceptually similar — both grant scoped, revocable authority. Delegation in payments is more constrained (it's tied to a card and a policy) and is enforced at the auth path of the network, not just at the API gateway.

Related reading

External references

By Vlad K.. Last updated 2026-04-29.