Axiru prevents unauthorized money outflows. Enforce your rules before supported transactions execute through Axiru. Enforcement must be enabled.
So when Stripe shipped approvals for agent actions, we read every page of the docs. Short version: it is good. You should turn it on.
What Stripe shipped
On August 26, 2026, Stripe added the Approval Requests v2 API in public preview. In the Dashboard it lives under Settings, then Approvals.
You write a rule for an action. Refund created is one. So are payment intent created, subscription canceled, credit note created, and a few account changes.
Each rule can have conditions:
- Amount. Only ask above a threshold.
- Actor. Only ask when a team member or an agent key does it.
- Rate. Ask when there are too many requests in a window.
Then you pick the control. Require approval pauses the action until a reviewer says yes. Block rejects it outright.
There is a new kind of key too. You can tag a restricted key as belonging to an autonomous agent. Stripe calls this the recommended way to give agents access. Agent keys get default rules. Refunds and subscription cancels wait for a person.
When an agent key hits a rule, the API returns approval_required. Stripe files the request for you. A reviewer approves or denies it in the Dashboard. Approved actions run on their own. Denied ones change nothing. Requests expire after 14 days.
One detail we really like. A requester cannot approve its own request. On a one person account, the agent key counts as a separate actor. So the owner approves the agent. The agent can't approve its own spending.
The MCP server follows the same idea. Some writes, like refunds and outbound payments, need a human to click a confirmation link first. From October 31, Stripe MCP stops accepting full access keys or untagged restricted keys.
Every rule change and every decision shows up in Security history. There are webhooks for each state.
This is a real control. It acts before money moves. It is not a dashboard that tells you what went wrong last week. Credit to Stripe for shipping it, and for making it the default for agent keys.
What it covers
Stripe Approvals governs your Stripe account. That is its job, and it does it well.
But agents do not live inside one processor. A support agent may refund on Stripe today. Tomorrow the same team adds a second processor for another region. An ops agent pays a vendor by card. A research agent pays for an API call with a stablecoin. Each place has its own rules screen, its own limits, its own log. Or none at all.
So the policy forks. A $200 refund ceiling lives in Stripe. A different ceiling lives somewhere else. Nobody owns the full picture.
Where we sit
Your agent has one budget, even when it uses several payment providers.
Think of it like a spending limit on each card versus one budget across all your cards. Or a cashier who sees one purchase, while the manager sees the whole shopping trip. Say an agent has a $1,000 daily budget and sends ten $100 payments through each of three providers. Each provider sees $1,000. The business has spent $3,000. Or the same invoice gets paid once on each provider, and each one looks fine on its own.
That is the problem we are building Axiru to solve. Axiru is built around a shared, rail-agnostic policy and evidence model. Enforcement is integration-specific, so you verify the path enabled for each rail.
What is live today:
- Routed Stripe refund enforcement. Allow, hold or deny before the refund executes.
- Supported x402 pre-authorization.
- Human approval on holds.
- Decision records you can hash-verify.
What is not there yet: Stripe DAA runs in shadow mode. USDC on Solana is limited early access. Other rails are reserved, not live. Policy is not yet one stored rule that automatically covers every path, and cross-provider budgets still need proof before we claim them.
The core rule is the same one Stripe chose. The AI can't approve its own spending. We think that rule should travel with the workflow, not stop at one provider.
The practical test
Before giving an AI agent payment access, test four things: an allowed action, a denied action, a required approval and a direct-provider bypass. Can the agent call the provider directly with another credential? A policy needs an execution path that honors it.
How they fit together
These are not either/or. If you run on Stripe, turn on Approvals. Tag your agent keys. Keep the defaults.
Then ask a few questions:
- Do your agents move money anywhere besides Stripe, now or next quarter?
- Does one person need to see every agent outflow in one queue?
- Do you need to catch the same refund twice, not just a big one?
- Can you prove to an auditor which policy version made each call?
If the requirement is only a Stripe approval flow, Stripe's native control may be enough. If any answer above is yes, you want independent policy and evidence across the systems your agents use.
Try it without moving money
There is a synthetic playground where no money moves, and a free local refund replay that previews how a sample policy would have treated past refunds. It does not turn on enforcement. Current coverage is listed on the security page at axiru.com.
If you are thinking about this problem, we would like to hear how you handle it today. Leave a comment, or ask for a live demo. More at axiru.com.
Top comments (0)