How to Let AI Agents Make Payments Safely

TL;DR

Letting an AI agent transact is letting software make decisions in milliseconds with real money. Safe doesn't mean infallible — agents will sometimes do things you didn't intend. Safe means failures are bounded, every charge has an audit trail, and you can stop a misbehaving agent in seconds.

What are the five safety layers?

Layer 1: Delegated authorization (scope)

Agents don't hold credit card credentials. They hold a delegation — a scoped, revocable authorization to spend on a specific card under specific rules. Card data stays vaulted. The agent's authority is bounded by the delegation.

Why this matters: a compromised agent (prompt injection, infrastructure breach) can only do what the delegation allows. Scope is the first line of defense.

See Delegated Payment Authorization.

Layer 2: Policy enforcement at auth time

Every transaction is evaluated against the policy before authorization is granted. 15+ rule types: amount, MCC, geo, time, velocity, custom approval thresholds. Sub-100ms decision in the auth path.

Why this matters: rules are enforced where it matters — at the network. Application-layer rules can be bypassed by a misbehaving agent. Network-layer rules can't.

See How We Built a 100ms Policy Engine.

Layer 3: Merchant + MCC controls (where)

Whitelist of merchants the agent can transact with. Block list of merchant categories (gambling, crypto, tobacco, etc.). Layered: whitelist as outer boundary, MCC as categorical filter.

Why this matters: even within a sensible spending policy, you don't want an agent paying off-brand impostors or spending outside its purpose. Where-controls catch the "right amount, wrong merchant" failure mode.

See How to Prevent AI Agents From Spending at the Wrong Merchants.

Layer 4: Velocity caps (how often)

Limits on transactions per minute, hour, day. Catches runaway loops, compromised credentials, and prompt-injection attacks that would otherwise fire many small charges fast.

Why this matters: many failure modes manifest as elevated transaction frequency before they show up as suspicious amounts. Velocity is the early warning + the rate limiter.

See What Are Velocity Rules.

Layer 5: Human-in-the-loop fallbacks

For high-value or anomalous transactions, the policy says "ask first." The transaction is held; a notification fires to the user; user approves or denies. Policy variants:

Why this matters: the four prior layers are automated. Human-in-the-loop is the fallback for cases where automation isn't enough — typically high-value or novel decisions.

How do these layers compose?

Order of evaluation in the auth path:

  1. Delegation valid? If revoked/expired → decline.
  2. Merchant whitelist OK? If not → decline.
  3. MCC allowed? If blocked → decline.
  4. Amount within cap? Velocity OK? Geo OK? Time OK? If not → decline.
  5. Approval-required threshold hit? If yes → hold + notify human.
  6. All checks pass → authorize.

Short-circuit on first failure. Decline reasons are explicit; you know which layer fired.

What does "safe" actually look like in production?

Concrete metrics from a production agent platform with the five layers operational:

What's NOT covered by these layers?

Three remaining risks:

1. Logic errors in the agent itself. The agent decides to do the wrong thing within the rules. ("Buy this specific concert ticket" instead of normal travel booking.) The payment platform can't catch this — it requires application-layer logic about what the agent is supposed to be doing.

2. Compromised user identity. If an attacker takes over the user's account, they can issue new delegations or modify existing ones. Account-security controls (2FA, anomaly detection on user behavior) are upstream of the payment layer.

3. Novel attack vectors. New attack patterns that the existing rules don't model. The agent-aware fraud model needs to keep up. See Agent-Aware Fraud Detection.

What about regulatory compliance?

The five layers map to specific regulatory expectations:

Not legal advice, but the model is built to fit existing regulatory frameworks.

FAQ

Is this enough for production?

For most agent products, yes. High-stakes verticals (financial agents trading real assets, healthcare agents making medical decisions) need additional layers — formal verification of agent behavior, regulatory pre-clearance, and operational SLAs that include rapid rollback.

What if the user wants no human-in-the-loop at all?

Possible. Layer 5 is optional. Configure the policy without approval thresholds. The other four layers still apply.

How do I handle a compromised delegation?

Revoke the delegation via API. Sub-second to network refusal. Optionally also: terminate all cards under that delegation (destructive); send notification to the user; flag the agent for review.

Are these layers Shatale-specific?

The framework applies to any agent payment platform. Shatale implements all five natively. DIY stacks need to build each layer separately and ensure they share state.

Can agents learn to bypass these layers?

The layers are enforced server-side by the platform — the agent can't bypass them by changing its own code. What the agent CAN do is operate within the layers in unintended ways. Application-layer logic + monitoring is the answer to that.

Related reading

External references

By Kristina Medvedeva. Last updated 2026-04-29.