Introduction

Trust machines with money.

Saifuro is B2B financial infrastructure for AI agent payments. It sits between your agents and your payment providers. You define what each agent may spend, on what, under whose authority, and within which limits. Saifuro evaluates every spend request against that in real time, meters usage, routes settlement through your licensed providers, and writes down every decision it makes.

Whether a request that breaks policy is blocked outright or recorded as a deviation depends on the rail it runs on. Both modes are set out in the threat model, and which one applies where is agreed per integration.

Start here

Two ways in, depending on which side of the transaction you are on.

Either way, every spend request takes the same path.

The full path, all seven steps with latency and failure modes, is in how it works.

Who this is for

Teams running agents that spend money in production: procurement and back office automation, agents buying compute, data, and APIs, platforms where agents pay other agents. Also API and tool providers who want to sell to agents and need per request metering and settlement.

The problem

When software can spend, the fraud question changes shape. The old controls assume a human: a CVV assumes a card in a hand, a 3-D Secure challenge assumes a phone in a pocket, a velocity rule assumes a buyer who cannot make fifty purchases in a minute. An agent has none of that, and fifty purchases a minute may be exactly what it was asked to do. It is not an intruder either — someone with real authority to spend sent it.

So the question stops being human or bot. It becomes whether this agent, acting for this principal, was authorized for this purchase, in this amount, for this purpose — and it has an answer only if the authority was written down beforehand, in a form a machine can evaluate and an auditor can read later.

In most stacks running agents today, it is not written down anywhere, and four gaps keep the stack from holding it.

Limits attach to instruments, not to authority. A provider can cap a card or an account. It cannot express that the procurement agent may spend up to 500 dollars on SaaS but nothing on compute, that the research agent is the opposite, and that both answer to the same budget owner. Run three providers and you maintain three sets of rules that do not know about each other, then reconcile them by hand at month close.

The rails multiplied. Machine payments now run over several standards at once — x402 and MPP for machine to machine settlement, ACP for agent checkout, AP2 for authorization and proof of intent — alongside the card agent programs from Visa and Mastercard. Each carries its own notion of who approved what. Write the policy separately for each rail and you get several policies that drift apart, usually without anyone noticing.

A limit in a prompt is a request. The model can be argued out of it, and a compromised or confused agent files no report about the limit it ignored. Teams tend to find this out late, because in testing the agent complies.

Evidence goes stale. Even when a decision was right, a controller will ask about it months later. Without the version of the rules that applied at the time, the best anyone can offer is a reconstruction.

What a control layer has to satisfy

Five requirements follow from those gaps, and the rest of this documentation is an account of how each one is met.

1. Authority is data, not code. What an agent may spend lives outside the agent, changeable and revocable without touching it. That is the mandate in core concepts.
2. Evaluation happens before settlement, inside the transaction path, not in reconciliation afterwards. That is the synchronous authorization step in how it works.
3. The decision is portable evidence. A counterparty can check an approval without trusting whoever presents it and without access to the system that issued it. That is the signed verdict in verifying a verdict.
4. The record survives rule changes. Every decision carries the version of the policy that produced it, in an append-only log. That is the record in core concepts and decision codes.
5. The layer states where it prevents and where it only detects, instead of letting the stronger guarantee be assumed everywhere. That is the credential placement table in the threat model.

What Saifuro does not do

Where to go next

Ready to evaluate? Go straight to observe mode and getting access.

Reading this as an agent? The full index lives at /llms.txt, and every page serves a markdown version.