sipi.bot policies
Merchant allowlist policy
A merchant allowlist policy restricts which merchants an agent can transact with. This guide covers allowlist design patterns for different agent use cases.
Overview
A merchant allowlist policy restricts which merchants an agent can transact with. This guide covers allowlist design patterns for different agent use cases. Built for spend firewall users who need depth, not breadth.
How sipi.bot helps
sipi.bot is built for spend firewall for ai agents. This page's recommendations are baked directly into the product.
- Spend firewall for AI agents
- Built specifically for spend firewall workflows
- Active development and support
- Documented API and integrations
Frequently asked questions
Is this page relevant to my use case?
If you are a spend firewall user, yes. The content is tailored to the specific challenges of policies.
How often is this updated?
Reviewed quarterly and updated when the underlying data or best practices change.
What this policy does
Merchant allowlist policy is one of the core policy levers sipi.bot evaluates on every agent transaction. The policy is enforced in under 5 milliseconds and produces a structured decision — approve, block, or flag — that the agent acts on before any money moves.
sipi.bot is a spend firewall for autonomous AI agents. It sits between your agent code and your payment methods, evaluating every transaction against your rules in under 5 milliseconds and returning one of three structured decisions: approve, block, or flag. Per-transaction limits, daily ceilings, velocity caps, merchant allowlists, and human-in-the-loop escalation are all enforced before a dollar moves. Pricing starts at $99 per month.
When this policy fires
The policy is evaluated on every transaction that matches its scope. A match produces one of three outcomes: approve (the transaction is within policy and proceeds), block (the transaction violates the policy and is rejected with a reason code), or flag (the transaction is held for human review). The agent receives the decision as structured JSON and can choose an alternative path on block.
How to configure it
Start from the recommended default for your agent's use case, then tune based on observed traffic. During the first week of deployment, review every blocked and flagged transaction in the audit log — these are the transactions that tell you whether your limits are too tight, too loose, or correctly calibrated.
Every policy decision is logged with the policy version that produced it. When you change a limit, the version increments, so you can always reconstruct which policy was in effect for any historical transaction.
Common configuration mistakes
Setting the limit too high because you do not want to interrupt the agent. A blocked transaction is information; an unblocked overspend is a bill. Start conservative.
Forgetting the velocity dimension. A per-transaction limit will not catch a loop that makes thousands of small in-policy calls. Pair every dollar limit with a velocity cap.
No audit trail. Without a tamper-evident log of every decision, you cannot debug blocks, prove compliance, or tune the policy intelligently.