How do teams control AI agent spending today?

AI agents can now pay for things.
They can call APIs, purchase data, subscribe to services, and even transact with other agents, all autonomously. Standards like x402 have made machine-speed payments possible. Google's AP2, Stripe's Agentic Commerce Protocol, and Mastercard's Verifiable Intent are all racing to build the rails.
The execution layer is ready. The policy layer is not.

THE BREAKTHROUGH THAT'S ALSO A RISK
An autonomous agent with a credit card is useful. It can pay for compute, subscribe to real-time data, and acquire services on demand. It removes friction from every step that used to require a human hand.
It's also a liability. Because right now, an agent can pay, but it can't prove it should. There's no layer between "I have the money" and "I have permission to spend it." There's no clean way to encode boundaries, enforce budgets, or route ambiguous transactions for human review.

HOW GOVERNANCE IS DONE TODAY, AND WHY IT BREAKS
If you talk to teams building with autonomous agents today, you'll see three patterns:

1. Prompt-level rules, "Don't spend more than $50 without asking me first." These rules live inside the system prompt. Easy to write, impossible to enforce. An agent can ignore them, misinterpret them, or get manipulated into overriding them.
2. Hardcoded if-statements, Developers wrap payment calls in code-level checks. This works until you need to change the policy. Every update means a redeploy. Every team builds its own incompatible version.
3. Vendor-specific SDK rules. Works if your agent only uses one provider. The moment you operate across x402, Stripe, on-chain USDC, and traditional banking, you're writing the same policy three different ways.
None of these is governance. They're duct tape.

WHAT REAL GOVERNANCE LOOKS LIKE
A working governance layer needs four properties: external (policies live outside the agent), deterministic (same input = same output), rail-agnostic (works across any payment system), and auditable (every decision produces a verifiable record).
That's what xBPP is built to do.

xBPP: THE DECISION LAYER BEFORE EXECUTION
xBPP evaluates every proposed agent action against policy before it reaches the payment rail. The protocol returns one of three verdicts:

→ ALLOW, the action falls within policy. Execute it.
→ BLOCK, the action violates policy. Stop it.
→ ESCALATE, the action is ambiguous. Ask a human.

That third verdict is the one people underestimate. Without ESCALATE, you have two options: kill autonomy by blocking anything unclear, or accept risk by allowing anything not explicitly forbidden.
Policies are written as declarative JSON. They live outside the agent. They work across every payment rail. Every decision is cryptographically signable and auditable.

STANDARDS OUTLAST PRODUCTS
The agent economy is going to be massive. The companies that ship the best governance products will matter for a few years. The standards that emerge will matter for decades.
Think of payment rails: Visa and Mastercard are still around. But the invisible layers, TCP/IP, HTTPS, and OAuth, power every transaction on the internet. Nobody thinks about them. Everyone uses them.
xBPP is built for that kind of role.

WHAT HAPPENS NEXT
x402 is live. AP2 is shipping. ACP is rolling out. Agents will transact at machine speed, whether governance is ready or not.

The question isn't whether agents will have boundaries. They will. The question is whether those boundaries will be ad hoc and brittle, or whether they'll come from an open standard everyone can implement.

Learn more about xbpp here: xbpp.org
Learn more: vanarchain.com