How it works

Every spend request takes the same path.

1. Intent. The agent decides to spend: amount, recipient, category.
2. Authorization request. The agent runtime calls Saifuro and waits.
3. Evaluation. Saifuro finds the applicable mandate and runs the request through policy: limits, categories, velocity, expiry.
4. Metering. The call is metered whatever the verdict, per request, per session, or per outcome.
5. Verdict. One of the decision codes comes back, always with a reason attached.
6. Settlement. If approved, your payment provider executes it. Saifuro touches neither funds nor card data.
7. Record. Request, policy version, verdict, and reason go into the log.

Step 2 is synchronous, so the round trip sits inside your agent's transaction path. In practice the network hop costs more than the evaluation, so placement next to your agents is part of the onboarding conversation.

We measure p50 and p99 on your own traffic during observe mode, before anything blocks. A figure taken from someone else's deployment would say very little about yours.

What stops an agent from skipping step 2 altogether depends on where payment credentials sit for that rail. Both modes are set out in the threat model.

Layers

Behavior when Saifuro is unavailable

Failure mode is set by policy, per class of operation.

Critical categories fail closed by default: no verdict, no spend. A control system that waves everything through when it breaks can be bypassed by breaking it.

For selected classes you can choose to fail open, with a record written after the fact, where continuity matters more than control. That choice lives in the policy and shows up in the log, so nobody discovers it during an incident.