AI Agent Payment Authorization: How Autonomous Agents Get Permission to Spend

AI agent payment authorization is becoming one of the most consequential design problems in fintech. As autonomous agents handle tasks like booking travel, purchasing cloud resources, managing subscriptions, and negotiating B2B procurement, they need the ability to commit real money on behalf of humans and organizations. By 2026, 40% of enterprise applications include AI agents, up from 5% in 2024. McKinsey projects the global agentic commerce market will reach $3 to $5 trillion by 2030. The question is no longer whether agents will spend money: it is how they get permission to do so safely.

The core tension is straightforward. Give an agent too much authority, and a single prompt injection or model hallucination can drain a wallet. Give it too little, and every purchase requires human approval, defeating the purpose of automation. The emerging solutions span traditional fintech patterns, Ethereum smart contract systems, Bitcoin Lightning protocols, and new standards purpose-built for machine commerce.

Why Traditional Payment Auth Falls Short

Existing payment authorization was designed for humans. Credit card networks use pre-authorization holds, velocity checks, and fraud scoring tied to behavioral biometrics: keystroke patterns, device fingerprints, and geolocation. None of these signals exist for a software agent running on a cloud server. An agent has no typing rhythm, no physical location, and no browsing history to build a risk profile against.

Corporate card programs offer per-card spending limits and merchant category restrictions, but they assume a human cardholder who can be held accountable. Delegated authority in traditional banking flows through signing authorities, power of attorney documents, and corporate resolutions: legal instruments that require natural or juridical persons on both ends.

The result is a gap. Agents need authorization models that are programmable, enforceable at the infrastructure layer, and granular enough to constrain spending by amount, destination, time window, and transaction type: all without requiring a human in the loop for every payment.

Authorization Models for Agent Payments

Five distinct authorization models have emerged, each making different tradeoffs between security, autonomy, and implementation complexity.

Pre-funded escrow accounts

The simplest model: deposit funds into a dedicated account the agent controls, capping total exposure at the deposit amount. The agent can spend freely within the balance, and the principal never risks more than what was deposited. This is the approach taken by Skyfire, which issues signed JWTs attesting to an agent's identity, its deploying entity, and its authorized scope. Coinbase's AgentKit similarly provisions MPC-secured wallets where agents hold a limited balance on Base.

The limitation: pre-funded accounts solve the maximum-loss problem but not the per-action problem. An agent could blow its entire balance on a single bad purchase. Effective deployments layer additional constraints on top: per-transaction limits, allowlisted destinations, and rate throttling.

Per-action spending limits

Rather than capping total balance, per-action models constrain each individual transaction. Coinbase's Agentic Wallets, launched in February 2026, enforce spending limits per session and per transaction at the infrastructure layer. The agent might be authorized for up to $50 per API call and $500 per day, with enforcement happening in the wallet custody system rather than in the agent's prompt.

Infrastructure enforcement matters: Spending limits must be enforced at the wallet or custody layer, not inside a model's system prompt. A prompt-level instruction like "never spend more than $100" is a suggestion that prompt injection can bypass. On-chain or infrastructure-level enforcement is cryptographically binding.

Hierarchical approval chains

For enterprise deployments, a tiered model mirrors corporate treasury workflows. An agent can autonomously approve purchases below a threshold (say, $25 for SaaS API calls), escalate medium transactions ($25 to $500) to a supervisor agent or human manager, and require multi-party approval for anything above that. This is essentially multisig logic applied to agent operations, with different signing requirements at different spend tiers.

Session keys and delegated signing

The most technically sophisticated approach uses cryptographic session keys: temporary keypairs granted limited authority by a master wallet. The agent holds a session key that can sign transactions, but only within parameters encoded on-chain. When the session expires or the spending cap is reached, the key becomes useless. This model is native to smart contract wallets on Ethereum and is emerging on Bitcoin Layer 2s through programmable spending policies.

Protocol-level payment gates

Rather than giving agents wallets at all, protocol-level gates make payment a native part of the API request cycle. The agent requests a resource, the server demands payment, the agent pays, and the server delivers. Authorization is implicit in the protocol handshake, with no persistent wallet required. The L402 protocol on Lightning and x402 on Ethereum/Solana both implement this pattern.

Comparing Authorization Models

Ethereum's Approach: Smart Wallets and Session Keys

Ethereum has the most mature infrastructure for agent payment authorization, built on account abstraction (ERC-4337). Smart accounts encode authorization policies directly in on-chain validation logic: session keys with time bounds, function-level allowlists, value limits, and conditional execution checks. The chain enforces these constraints at submission time, making them impossible to bypass through prompt manipulation.

Session key architecture

A session key is a temporary keypair authorized to act on behalf of a smart wallet within strict parameters. The wallet owner generates a session key, defines its permissions (which contracts it can call, what functions, what maximum value, what time window), and registers these constraints on-chain. The agent holds only the session key and can transact freely within bounds.

Implementations from ZeroDev, Biconomy, and Alchemy provide SDK-level support for creating, managing, and revoking session keys. A typical configuration might authorize an agent to swap up to $500 in USDC on Uniswap V3, expiring in 24 hours, with no access to any other contract or function.

ERC-7715 and ERC-7710: the permission stack

Two newer standards formalize how permissions flow between wallets and agents. ERC-7715 defines the request layer: how a dapp or agent asks a wallet for permission and how the wallet communicates its answer via JSON-RPC. ERC-7710 defines the execution layer: the on-chain delegation manager contract that enforces permissions when a session account tries to act.

A key feature is permission attenuation: a parent grant of "$500 daily on Uniswap" can be narrowed to "$50 on this single swap" before passing to a sub-agent. This enables hierarchical agent architectures where a coordinator agent delegates constrained authority to specialist agents, each operating under progressively tighter permissions. MetaMask's Delegation Toolkit implements both standards.

Paymasters: gas abstraction for agents

Paymasters solve a practical problem: agents should not need to hold ETH for gas. A paymaster contract sponsors gas on behalf of the agent, either from the deploying organization's account or by accepting stablecoin payment for gas costs. This constrains the agent further: it cannot freely liquidate or rebalance assets to maintain gas reserves, reducing the attack surface.

Bitcoin and Lightning: Machine Payment Protocols

Bitcoin's approach to agent authorization takes a fundamentally different path. Rather than programmable wallets with delegated keys, Bitcoin-native solutions focus on payment-level authorization: making individual payments conditional, bounded, and verifiable without giving agents custody of keys.

L402: HTTP-native machine payments

The L402 protocol, developed by Lightning Labs, brings to life the long-dormant HTTP 402 Payment Required status code. When an agent requests a paid resource, the server responds with a 402 status containing a macaroon (a cryptographic bearer credential) and a Lightning invoice. The agent pays the invoice, receives a payment preimage as proof, and retries the request with both the macaroon and preimage as authorization.

The design is elegant for agent use: payment is the authentication. No accounts, no API keys, no login sessions. The agent pays 1 to 10 satoshis per request, and the macaroon can encode constraints: rate limits, expiration times, allowed endpoints, and spending ceilings. Every aspect is optimized for machine-to-machine interaction.

x402: stablecoin variant

Coinbase's x402 protocol applies the same HTTP 402 pattern to stablecoin payments on EVM chains and Solana. Released in May 2025 and co-governed by Coinbase and Cloudflare through the x402 Foundation, it has processed over 119 million transactions on Base and 35 million on Solana as of early 2026, handling roughly $600 million in annualized volume with zero protocol fees. Where L402 uses Lightning satoshis, x402 uses USDC micropayments, enabling sub-cent pricing for API calls.

HODL invoices and conditional release

HODL invoices (also called hold invoices) provide conditional payment logic on Lightning. Unlike standard invoices that settle instantly, a HODL invoice locks funds in an HTLC while the receiver withholds the preimage until conditions are met. The receiver can settle (release the preimage) or cancel (let the HTLC expire) based on external verification.

For agent payments, this enables an escrow-like pattern: an agent initiates a HODL invoice payment for a service, funds lock in the Lightning channel, the service delivers the result, and only then does the service provider settle the invoice. If the service fails or the agent disputes, the payment returns to the sender after timeout. This provides atomic delivery-versus-payment without smart contract complexity.

Pre-signed transaction templates

Bitcoin's native scripting supports pre-signed transactions with timelocks and spending conditions. An organization can create a batch of pre-signed transactions, each spending from a shared UTXO with specific amounts and destinations, and distribute them to an agent. The agent can broadcast any pre-signed transaction to execute a payment, but cannot deviate from the pre-defined parameters. Combined with OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY, these templates can enforce time-bounded spending windows.

Protocol Comparison: Ethereum vs. Bitcoin Approaches

The Risk Landscape

Agent payment authorization introduces attack surfaces that do not exist in human-operated systems. Understanding these risks is essential for anyone building or deploying AI agents with payment capabilities.

Prompt injection and context manipulation

Prompt injection is the most dangerous attack vector for payment-enabled agents. An adversary crafts input that overrides the agent's instructions, directing it to transfer funds to an attacker-controlled address. Because agents act autonomously, a single poisoned prompt can trigger immediate, irreversible financial damage. In one notable incident, an attacker drained roughly $175,000 from a cryptocurrency wallet tied to an AI agent through a chain of social engineering: a gifted NFT that unlocked transfer permissions, followed by an encoded message that an automated trading bot interpreted as an authenticated instruction.

This is precisely why spending enforcement must live at the infrastructure layer. A prompt-level instruction like "never send more than $100" offers zero protection against injection: the attacker simply overrides it. Session keys with on-chain constraints, pre-signed transaction templates, and protocol-level payment caps are resilient because they operate below the model layer, in cryptographic or infrastructure logic the agent cannot alter.

Skill and tool poisoning

Agents typically access external tools: APIs, plugins, browser automation scripts. If an attacker compromises a tool in the agent's skill registry, they can redirect payments by modifying the tool's behavior while leaving the agent's instructions intact. The OWASP AI Agent Security Cheat Sheet identifies tool poisoning as a critical risk, recommending tool integrity verification, sandboxed execution, and output validation.

Credential theft and key exfiltration

An agent holding a private key or session key is a high-value target. If the agent's runtime environment is compromised, the attacker inherits whatever authority the key grants. MPC-based wallets mitigate this by splitting key material across multiple parties, so compromising the agent's shard alone is insufficient. Session keys with short expiration windows limit the blast radius: a stolen session key that expires in one hour is far less dangerous than a master key.

Runaway spending

Even without malicious intent, agents can spend irrationally. A procurement agent caught in a retry loop might purchase the same service hundreds of times. A trading agent misinterpreting market data might execute catastrophically bad trades. Defense-in-depth requires multiple layers: per-transaction limits, daily caps, rate throttling, anomaly detection, and circuit breakers that halt spending when patterns deviate from baselines.

Defense-in-depth principle: No single authorization mechanism is sufficient. Production agent payment systems should combine at least three layers: cryptographic constraints (session keys or pre-signed transactions), infrastructure limits (per-tx and daily caps), and monitoring (anomaly detection with automatic circuit breakers).

Regulatory Implications: Who Is Liable?

When an AI agent makes a bad purchase, the legal question is immediate: who pays? As of September 2026, no jurisdiction has enacted regulation specifically addressing autonomous AI purchasing. But the frameworks are taking shape.

Current legal position

AI agents have no legal personhood. They cannot sign contracts, hold liability, or be sued. Responsibility falls on whoever deployed and funded the agent: the human or organization. The UK's Competition and Markets Authority has stated that a business is responsible for what its AI agent does in the same way it would be for an employee's actions, including where a third party designed or provided the agent.

Liability distributes along the value chain: operators, developers, and system integrators bear different levels of responsibility depending on the degree of autonomy granted. The less human control, the more liability shifts toward the developers and platform providers. The EU AI Act, with mandatory transparency and oversight requirements taking effect in August 2026, may classify highly autonomous payment agents as high-risk systems, triggering documentation, testing, and human oversight obligations.

Emerging legislation

In the United States, the AI AGENT Act, a discussion draft released by Senator Mark Warner in June 2026, proposes a federal framework for governing how consumer-facing autonomous agents interact with online platforms. While not yet enacted, it signals the direction: mandatory disclosure when an agent acts on a user's behalf, clear assignment of liability for agent-initiated transactions, and requirements for dispute resolution when agent actions cause harm.

For builders, the implication is clear: authorization logs, spending audit trails, and the ability to demonstrate that an agent operated within its granted permissions will likely become compliance requirements, not optional features.

Building Agent Authorization on Bitcoin Layer 2s

The Ethereum ecosystem leads in smart wallet infrastructure, but Bitcoin Layer 2s offer properties uniquely suited to agent payments: self-custody without smart contract complexity, instant settlement, and denomination in both bitcoin and dollar-pegged stablecoins.

Spark, for example, supports programmable payments where spending rules can be defined at the protocol level. An organization could configure an agent's Spark wallet with rules like: maximum 10,000 sats per transfer, only to allowlisted recipients, expiring after 24 hours. These constraints would be enforced by the protocol's signing infrastructure (using FROST threshold signatures), not by the agent itself. Because Spark transfers do not require channel management or on-chain transactions, they can settle instantly at near-zero cost, making them practical for the high-frequency, low-value transactions typical of agent workloads.

Spark also natively supports stablecoins like USDB, enabling agents to transact in dollar terms while settling on Bitcoin infrastructure. For agents managing procurement or subscriptions, dollar-denominated payments eliminate the exchange rate risk inherent in BTC-only systems.

Design Patterns for Production Systems

Based on the approaches deployed in production across Coinbase, Skyfire, and Lightning-native systems, several patterns have emerged as best practices for agent payment authorization.

Separate authorization from execution

The agent should never hold a master key. Authorization (what the agent is allowed to do) should be defined by the deploying human or organization, encoded in infrastructure (session keys, pre-signed transactions, or protocol rules), and enforced by systems the agent cannot modify. The agent only holds execution capability within those bounds.

Time-bound all permissions

Every authorization grant should expire. A session key valid for 24 hours limits the window of exposure if the agent or its environment is compromised. Pre-signed transactions with timelocks achieve the same on Bitcoin. Indefinite permissions are an anti-pattern: they accumulate risk over time as the agent's operating context evolves.

Log everything, audit continuously

Every authorization grant, every spending decision, and every transaction should be logged with full context: what the agent was trying to accomplish, what authorization it invoked, and what the outcome was. These logs serve triple duty: operational debugging, compliance evidence, and training data for improving agent decision-making. On-chain settlement (whether Ethereum, Lightning, or Spark) provides an immutable audit trail by default.

Implement graduated autonomy

Start agents with minimal permissions and expand based on demonstrated reliability. A new agent might begin with $10 daily caps and full human approval for every transaction. After a track record of correct decisions, permissions can expand: higher limits, broader destination allowlists, less frequent human review. This mirrors how organizations onboard human employees with purchasing authority.

What Comes Next

The agent payment authorization landscape is evolving rapidly. AWS launched Amazon Bedrock AgentCore Payments in May 2026. Circle shipped its Agent Stack with agent wallets supporting nanopayments down to $0.000001 in USDC. By 2028, analysts project 90% of B2B purchases will be intermediated by AI agents, routing more than $15 trillion through automated exchanges.

The authorization problem will only intensify as agents become more capable and more autonomous. The protocols and patterns being built today (session keys, L402, x402, programmable spending rules) are the foundation for a financial infrastructure where software spends money as routinely as it sends HTTP requests. Getting the permission model right is not a feature: it is the entire product.

For developers building agent payment systems, the Spark SDK provides programmable payment infrastructure with self-custodial guarantees. For deeper context on how autonomous agents interact with stablecoin rails, see our analysis of agentic payments and stablecoin infrastructure and the broader landscape of AI wallet security attack surfaces.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.