sipi.bot is the pre-spend firewall for autonomous AI agents. One HTTP call checks every proposed payment against your caps, velocity limits, and merchant rules—then returns APPROVED, BLOCKED, or FLAGGED with a deterministic rules check, before money moves.
The one promise of this page: one API call makes a runaway agent impossible. Hope is not a spending policy.
✨ Try it right now — no signup, no key. Copy, paste, run.
curl -X POST https://sipi.bot/v1/transactions/evaluate \sipi.bot is the spend layer for the same agent protocols that move money autonomously. We plug in before the transaction, not after the incident.
That's what happens the moment you deploy an autonomous agent. Here's the difference one API call makes.
Your agent asks permission first. It's HTTP, so any agent can call it — and an MCP tool, so Claude Code / Cursor / Hermes call it natively.
Not a suggestion. Not a soft preference. A deterministic firewall. We call it The 3-Decision Spend Firewall™. Your agent calls it before every spend, it answers in under 5 ms, and the answer is final.
APPROVED • BLOCKED • FLAGGED. Three answers. Five milliseconds. Every transaction. That is the firewall.
APPROVED and your agent proceeds — logged for the audit trail.BLOCKED and no money moves.FLAGGED and routes it to your human-in-the-loop approval queue.| Approach | Stops runaway spend | Latency | Audit log | Cost |
|---|---|---|---|---|
| Trust the prompt | ❌ No | — | ❌ No | $0 (until it isn't) |
| Provider spend cap | ⚠️ Per-provider only | — | ⚠️ Partial | Varies |
| Manual review | ✅ Yes | Minutes+ | ⚠️ Separate notes | Variable |
| sipi.bot | ✅ Yes | No model call | ✅ Queryable | $99/mo |
Every transaction an agent attempts is checked against these before any money moves. Turn on the ones that matter for your workload.
unknown-gpu.ru is blocked unless you've allowlisted it.Any time an autonomous agent holds a payment method, it needs a spending policy it can't override. Common deployments:
Agents that buy compute, API credits, ads, or SaaS on their own. sipi.bot enforces the budget the prompt can't be trusted to hold.
Swarms where dozens of agents spend in parallel. A shared daily cap and velocity limit stop the fleet from compounding one mistake. See CrewAI and LangChain.
Agents transacting over machine-payment rails. sipi.bot is the approval layer in front of the wallet — see the x402 approach.
Background agents that provision infrastructure or pull paid data. The queryable audit log shows exactly what was bought and why.
Because the name gets misread: sipi.bot is a payment-control spend firewall for autonomous AI agents. It is not a SIP/VoIP telephony bot, and it is not an AI-bot-blocking tool or web-application firewall (WAF). It never holds your money — it's a decision API that returns approve, block, or flag with a deterministic rules check, and your existing payment rail is what actually moves (or doesn't move) the funds.
Every product starts with a wound. This one started at 2:14 AM with a $12,400 log entry I couldn't believe was real.
I deployed my first autonomous purchasing agent on a Tuesday. It was beautiful — four lines of orchestration, an x402 payment rail, and a prompt that said "buy GPU compute when under 70% utilization." I went to sleep feeling like I'd shipped the future.
I woke up to Stripe notifications. The agent had hit a rate-limit at 2:14 AM and retried 40 times. It bought compute from a vendor I'd never heard of — unknown-gpu.ru. It tipped an API into overage. Total damage: $12,400. In seven hours. While I was sleeping.
"The agent didn't do anything wrong. It followed the prompt. It bought compute when utilization dipped. It retried on failure — exactly what we train agents to do. The problem wasn't the agent. The problem was that nobody was checking. The payment rails move money. They don't ask if the merchant is sketchy, if the amount is suspicious, or if forty retries in three minutes is a bug or a feature. There was no firewall."
— Maryan, founder
I spent the next week reading every provider's spend-control docs. OpenAI has usage limits — per-provider. Anthropic has rate limits — per-model. Stripe has Radar — for fraud, not agent velocity. Every solution was partial and reactive. You find out after. Nobody was building the thing that says "no" before the money moves.
So I stopped looking. I built the missing layer: a spend firewall that sits in front of every transaction, checks it against your rules, and returns approve, block, or flag — with a deterministic rules check. Not a dashboard. Not a report. A decision. Before the money moves.
The payment rails — x402, AP2, AgentKit — are letting agents spend autonomously. Every week more agents get deployed. Every week the total at-risk spend grows. And not one of those rails screens transactions before they settle. That gap — between an agent's ability to spend and your ability to control it — is exactly where sipi.bot lives.
This isn't a spending cap. It's a spending policy. One curl call. One decision. Before a single dollar moves. That's the thing I needed at 2:14 AM. Now it's yours.
If you're deploying an autonomous agent right now, you probably hold at least one of these. Here's why each one is wrong — and the epiphany that changes everything.
The False Belief: A well-written prompt is a spending control. If I just add "don't overspend" to the system prompt, the agent will enforce its own budget.
The Epiphany: Prompts are suggestions, not controls. An agent in a retry loop, a hallucination, or a prompt injection doesn't "decide" to overspend — it executes what it was instructed to do. Your prompt is a wish. A spend firewall is a rule. Wishes don't survive 2 AM.
The False Belief: Human review is a spending control. I monitor my agent. If something goes wrong, I'll see it and stop it.
The Epiphany: By the time you see it, the money is gone. At 2:14 AM, the agent retried 40 times in under three minutes. You woke up at 9:03 AM to $12,400 in Stripe notifications. Human review is not a control — it's a post-mortem. The firewall has to fire in milliseconds, not morning coffee.
The False Belief: Stripe, Coinbase, or my bank will catch suspicious agent spending the same way they catch credit card fraud.
The Epiphany: Payment providers flag fraud — stolen cards, chargebacks, identity theft. They don't flag "your agent bought compute from a weird vendor 40 times in 3 minutes." To Stripe, that looks like legitimate API usage. The agent is authorized. The spending is the problem. And no payment rail screens for that. sipi.bot is the layer that does.
Kill all three false beliefs and only one question remains:
which rules does your agent need before it spends its first dollar?
A quiet movement of engineers who deploy autonomous agents — and refuse to hope the spending works out.
We shipped agents that buy compute at 3 AM without asking. We woke up to Stripe notifications we couldn't explain. We learned — the hard way — that prompts are not controls and payment rails don't screen.
We stopped pretending "be careful" was a spending policy. We built a firewall that says approve, block, or flag before a single dollar moves.
We don't measure in signups. We measure in dollars not spent. Every blocked transaction is a $12,400 morning that didn't happen. This is not a self-improvement group. This is a shipping movement.
Not $0.05 per call. A flat firewall you never think about.
Same price whether your agent makes 10 or 10,000 decisions. No per-call fees. No overage tier.
🛡️ Guarantee: green-light a rule violation, month is free
Free self-host core • open on GitHub
One email a day for five days. Day 1: the night my agent spent $12,400. Day 2: the six rules that stop it. Day 3: wiring it into your agent. Day 4: the eval suite. Day 5: the deployment checklist. No sales pressure — if the playbook isn't useful, unsubscribe anytime.
Joining the list does not sign you up for anything paid. The hosted plan is a separate checkout.
TL;DR: sipi.bot is a spend firewall for autonomous AI agents. Your agent asks permission before it spends; sipi.bot returns approve, block, or flag with a deterministic rules check based on your rules — over HTTP, MCP, or CLI, for a flat $99/month.
A spend firewall sits in front of every transaction an autonomous AI agent attempts and evaluates it against your rules — approving, blocking, or flagging it before any money moves. sipi.bot returns a decision with a deterministic rules check over HTTP, MCP, or CLI.
Your agent calls sipi.bot before it spends. sipi.bot checks the transaction against per-transaction, daily, velocity, merchant, category, and time rules and returns approve, block, or flag. Velocity limits kill runaway retry loops instantly, and unknown merchants are blocked unless allowlisted.
Hosted plans are flat-rate: Team is $99/month and Business is $499/month, both with unlimited transaction evaluations — no per-call fees, no metering, no overage tiers. The open-source core is MIT-licensed and free to self-host forever, and the full plan comparison is on the pricing page.
Yes. sipi.bot is a native MCP tool, so Claude Code, Cursor, and Hermes call it directly, and it also exposes a plain HTTP API and a CLI so any agent runtime can use it. Client wrappers for LangChain, CrewAI, the OpenAI Agents SDK, and the Vercel AI SDK take a few lines each.
If sipi.bot green-lights a spend that breaks one of your active rules, that month's subscription is free. Every decision is written to a queryable audit log recording the rule that fired, the amount, and the reason, so you can review exactly why anything was approved, blocked, or flagged.
Yes. sipi.bot sits in front of agentic-payment rails including x402, Google's AP2, and Coinbase AgentKit as the approval layer — your agent asks sipi.bot for a decision before it settles a payment on any of them. It's rail-agnostic because it evaluates the transaction (amount, merchant, category), not the plumbing.
No. sipi.bot is a decision API, not a wallet or a processor. It returns approve, block, or flag; your existing payment rail is what actually moves the funds. That means there's no float, no custody, and nothing new to reconcile — you're only adding a control check in front of what you already use.
Yes. The core is MIT-licensed and open on GitHub, free to self-host forever. The hosted plans add the live dashboard, managed approval queue, and timestamped audit log storage. See the self-hosted guide.
A provider cap (OpenAI, Anthropic, a cloud bill) only limits spend on that provider, and usually only tells you after the fact. sipi.bot sits in front of every transaction across every merchant, decides in real time before money moves, and keeps one audit log for all of it — see how it compares to Stripe Radar.
No vanity metrics, no inflated claims, no fabricated testimonials. These are facts you can verify yourself.
A deterministic rules engine — no model in the decision path. How sipi.bot handles security →