Frequently Asked Questions — sipi.bot
Common questions about agent spend firewalls, pricing, integrations, and deployment.
By the sipi.bot team · Published 2026-07-19
Common Questions
What is an agent spend firewall?
A policy engine that evaluates every transaction an AI agent attempts before money moves, enforcing your rules on caps, limits, merchants, and categories.
How is this different from payment fraud detection?
Fraud detection catches stolen cards and chargebacks. A spend firewall catches unwanted purchases — runaway loops, bad merchants, over-budget spending — by an agent you authorized.
Do I need this if my agent only calls free APIs?
Today, no. But the moment your agent touches any paid API, cloud resource, or SaaS tool, you need a firewall. Most agents start free and grow into paid surfaces.
How fast is the evaluation?
Deterministic rules check for standard policy evaluation. The policy check is deterministic local code; hosted latency also includes the network path.
Can I self-host?
Yes. The open-source core (MIT license) runs on any Python 3.10+ environment. The hosted version is $99/month for unlimited evaluations.
What happens when a transaction is FLAGGED?
The transaction is recorded as FLAGGED and appears in the authenticated dashboard approval queue. Your payment integration should wait for an APPROVE or DENY decision before continuing.
What frameworks do you support?
Any framework that can make an HTTP call. Native integrations: LangChain, CrewAI, Vercel AI SDK, OpenAI Agents SDK. Custom: call the REST API from any agent runtime.
Is there a free tier?
The open-source core is free forever. The public playground is free to try; hosted workspaces start at $99 per month.
Why FAQ matters for agent spend control
Whether you are exploring faq, comparing solutions, or evaluating specific features, the central challenge remains the same: autonomous AI agents can initiate financial transactions, and without real-time enforcement, those transactions can escape human oversight in milliseconds. A policy that is not enforced before the transaction executes is not a control — it is a hope.
Pre-spend enforcement can stop a policy-violating transaction before the payment call; incident reduction depends on the policy and integration. The mechanism is straightforward: every transaction runs through a policy check that returns one of three decisions, and the agent acts on that decision before the money moves. No dashboard-watching, no after-the-fact reconciliation, no "we caught it on the next billing cycle."
Key considerations for faq
- Enforcement vs. observation: Dashboards tell you what happened. A spend firewall stops what should not happen. Both are useful; they are not substitutes. Start with enforcement, add observation for attribution and analytics.
- Per-agent vs. global policies: Different agents have different spend profiles. A research agent and a billing agent need different limits. Configure per-agent policies from day one.
- Velocity limits are non-negotiable: A per-transaction limit will not catch a loop of 200 small calls. A velocity cap (max transactions per minute) is the specific control for the most common runaway pattern.
- Merchant allowlists prevent the worst-case scenario: A compromised agent can be redirected to any destination. An allowlist ensures it can only transact with vendors you have explicitly approved.
Next steps
sipi.bot enforces all four control dimensions — per-transaction limits, daily ceilings, velocity caps, and merchant allowlists — with a deterministic rules check and no model call. Pricing starts at $99/month for unlimited evaluations. Deploy in under an hour: define your policy, wrap your agent's spend functions, and run the three test scenarios (APPROVED, BLOCKED, FLAGGED) before going to production.