A reference for every term that matters when you're building autonomous agents that transact. If you're new to the space, read through top to bottom. If you know what you're looking for, use the search below.
The set of rules, checks, and workflows that determine whether an autonomous AI agent is allowed to make a specific payment. Governance answers the should question: given a payment request, should it proceed, be blocked, or pause for human review? It is distinct from the payment rail, which answers the how question.
A standard for declaring and enforcing what an autonomous agent is permitted to do. Permission protocols focus on the boundary between agent capability and agent execution - the agent can decide to do anything, but the protocol decides what actually happens. xBPP is an example of an agent permission protocol scoped to payment operations.
Payments initiated by an autonomous AI agent rather than a human. The term emphasizes the difference from traditional ecommerce or B2B transactions: agentic payments are typically machine-to-machine, small-value, high-frequency, and governed by pre-declared policy rather than per-transaction human consent.
The three verdicts xBPP returns from a policy evaluation. ALLOW means the transaction is within all policy bounds and may proceed. BLOCK means the transaction violates a hard limit and must stop. ESCALATE means the transaction is in a grey zone and requires human approval before proceeding. The three-verdict model replaces the binary allow/deny pattern used in traditional authorization. The ESCALATE verdict is what makes autonomous agents safe to deploy: it gives them a way to ask for help instead of guessing when rules are ambiguous.
An AI system that can plan, act, and react without step-by-step human intervention. Autonomous agents typically run in a loop: observe, decide, act, evaluate, repeat. Payment-capable autonomous agents are agents that can initiate financial transactions as part of that loop - which is where governance becomes critical.
A list of approved recipients (addresses, URLs, domains, or identifiers) that an agent is allowed to pay. The opposite of a blocklist. Allowlists are strict - if a recipient isn't on the list, the transaction is blocked or escalated. Common in high-security deployments where the set of legitimate counterparties is small and known in advance.
A policy rule that treats first-time-seen recipients differently from known ones. A typical freshness rule is "escalate for the first 30 days, then allow". This catches the single most common class of agent payment bugs: the agent misparsed an address or URL and started paying the wrong entity. Freshness rules catch these almost immediately while still allowing the agent to work autonomously with its established counterparties.
A policy expressed as data (typically JSON or YAML) rather than code. Declarative policies describe what rules apply, not how to enforce them, and leave enforcement to a separate engine. The benefits are significant: policies become portable across implementations, can be versioned and diffed in git, can be audited by non-engineers, and can be reused across multiple agents without duplication.
A monetary amount above which a transaction triggers the ESCALATE verdict instead of proceeding automatically. Escalation thresholds are typically set lower than hard caps - for example, a policy might allow up to $500 per transaction but escalate anything over $50. This creates a grey zone where an agent can still propose high-value work but a human decides whether it happens.
An open standard for governing autonomous AI agent payments. xBPP defines a declarative JSON policy format and an evaluation model that returns one of three verdicts - ALLOW, BLOCK, or ESCALATE - for each proposed transaction. The protocol is chain-agnostic, rail-agnostic, and implementation-agnostic. The reference TypeScript SDK is 600 lines with zero runtime dependencies and is released under Apache 2.0.
A design pattern where a human reviews or approves selected actions taken by an autonomous system. In agent payment governance, HITL typically means escalating borderline transactions to a human via a notification (Slack, dashboard, email) and pausing the agent until the human responds. The goal is to preserve autonomy for the 99% of routine cases while keeping humans involved for the 1% of genuinely ambiguous decisions.
An HTTP status code reserved in the original HTTP specification but left unused for decades. RFC 7231 describes it as "reserved for future use." The x402 protocol finally activated it as a standard response for services that require payment from the caller - typically an autonomous agent - before returning a resource.
Payments initiated and received by software rather than humans. M2M payments have existed in narrow B2B contexts for years (EDI, ACH batch processing) but are expanding rapidly as autonomous AI agents start transacting on the open web. M2M payments are characterized by high frequency, small value, no interactive authentication, and programmatic governance.
A payment settled directly on a blockchain, with the transaction recorded in the chain's ledger. On-chain transfers are typically denominated in a stablecoin (USDC, USDT, DAI) or a native token (ETH, VANRY). They contrast with off-chain payments like traditional bank transfers or Stripe charges. xBPP policies can govern both on-chain and off-chain payment rails - the same policy applies regardless of where the payment actually settles.
A structured set of rules that determine whether a proposed payment should be allowed, blocked, or escalated. A payment policy typically includes hard caps, budget windows, counterparty rules, currency allowlists, and escalation thresholds. In xBPP, payment policies are declarative JSON and are the only source of truth for payment authorization.
The practice of expressing policy rules as configuration (data) rather than code. Policy as data enables versioning, diffing, code review, portability across implementations, and audit trails - none of which are easy when rules are scattered across function bodies and conditionals. The term is analogous to "infrastructure as code" but applied to authorization rules.
A software component that takes a request and a policy as input and returns a verdict. Policy engines are deliberately separate from the systems they govern, which keeps the policy logic isolated, testable, and reusable. xBPP's reference SDK is a policy engine specifically for payment requests, but the general pattern applies to any authorization decision.
A property of a payment tool or protocol that works with multiple underlying payment rails without being tied to any one. xBPP is rail-agnostic: the same policy can govern x402 payments, on-chain transfers, Stripe charges, and custom payment APIs. This matters because most production deployments end up using more than one rail, and having a single policy engine across all of them keeps governance consistent.
A machine-readable identifier that explains why a policy returned a particular verdict. Examples: ABOVE_ESCALATION_THRESHOLD, NEW_RECIPIENT, OUTSIDE_HOURS, DAILY_BUDGET_EXCEEDED. Reason codes are critical for observability and debugging - they let you filter and aggregate verdicts in your logging stack, and they let an agent reason about why a transaction was blocked instead of failing silently.
Settling a payment in a stablecoin (a crypto asset pegged to a fiat currency, most commonly USDC) rather than a volatile token or fiat rail. Stablecoin settlement is the dominant model for machine-to-machine payments on public blockchains because it gives you the speed and programmability of crypto without the price volatility. x402 payments typically settle in stablecoins.
An action taken by an LLM or AI agent to invoke an external function. Modern agent frameworks (OpenAI Agents SDK, Anthropic tool use, LangChain, CrewAI, AutoGen) all model agent actions as tool calls. When a tool call results in a payment, a policy engine like xBPP sits between the tool call and the actual payment execution to enforce governance.
USD Coin, a stablecoin issued by Circle and pegged 1:1 to the US dollar. USDC is the most common settlement asset for machine-to-machine and agent payments on public blockchains because of its regulatory clarity, high liquidity, and broad chain support. Most xBPP policy examples use USDC as the reference currency.
A policy rule that caps the number of transactions an agent can make within a given time window - for example, "maximum 20 payments per hour." Velocity limits catch runaway agents that have somehow gotten into a loop and are making many small payments in rapid succession, even if each individual payment is within the per-transaction cap.
The structured output of a policy evaluation. In xBPP, a verdict contains three main fields: the decision (ALLOW / BLOCK / ESCALATE), an array of reason codes explaining why, and a human-readable message. Verdicts are the contract between the policy engine and the agent - everything the agent needs to decide what to do next is in the verdict.
An open payment protocol that reactivates HTTP status code 402 Payment Required. Pioneered by Coinbase, x402 lets an HTTP service request a stablecoin payment from its caller - typically an autonomous AI agent - as part of a normal HTTP request/response cycle. The caller pays, retries with a proof, and receives the resource. x402 handles the how of agent payments; it deliberately does not handle policy, which is where xBPP composes alongside it.