Firewall Playground
Test the real sipi.bot firewall right here. Enter a transaction and get an instant APPROVED, BLOCKED, or FLAGGED decision. This is the live production endpoint — not a simulation.
By the sipi.bot engineering team · Published 2026-07-13 · Last updated 2026-07-17
Try a transaction
Quick presets
Current default rules
per_transaction: max $500 → BLOCKEDdaily_total: max $2,000 → BLOCKEDvelocity: max 10 tx/hour → BLOCKED (runaway protection)approval_threshold: ≥ $200 → FLAGGED for human reviewFirst BLOCK wins. FLAG is non-blocking. Edit rules on the dashboard →
What happens when you click evaluate
Your test transaction is POSTed to /v1/transactions/evaluate — the exact endpoint agents in production call before they spend. The rules engine walks your active rules in priority order: the first BLOCKED rule ends the evaluation immediately, while FLAGGED rules are recorded without stopping it, so a transaction can be flagged for review and still go through.
Every rule that fired comes back in the response, along with a plain-English reason like "Transaction $6,200.00 exceeds per-transaction limit $500.00".
The engine is deterministic — pure rule logic, no ML inference — which is why its decisions are reproducible: the public eval suite replays 53 labeled spend scenarios across nine categories — clean approvals, human-review flags, edge cases, and every blocking rule type — and the engine currently passes 53 of 53. The same engine ships in the MIT-licensed self-hosted core, wires into LangChain, CrewAI, OpenAI Agents SDK, and Vercel AI SDK, and runs hosted for a flat $99/month. Not sure which limits to set? Start from the risk calculator's recommended rules.
Why Playground matters for agent spend control
Whether you are exploring playground, 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.
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 playground
- 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.