Free tool ยท Real policy, not a mockup

Write the ceiling before you need it.

Four questions about what this agent may spend, and you get a policy the API accepts and the call to test it against. Everything happens in your browser.

Blocklist while you are still learning what the agent does. Allowlist before live.

One envelope covering model calls, paid tools and payments together.

Set to 0 to skip approvals entirely.

Comma separated. Leave empty to allow any.

What it is allowed to do
policy.json
test it

Why it is data

A ceiling in a config file is a ceiling anyone can raise quietly.

Policy here is a record, not deployed code. It validates when you save it rather than when an agent is waiting on it, it diffs in review like any other change, and raising a limit is a thing that leaves a trace. That matters more than expressiveness: a policy engine standing in front of money should be something you can read and argue with, not a program you have to run to understand.

The long version is in how to give an agent a spending limit it cannot raise, and the use case most teams start with isrefund and payout authority, which needs no AI at all.

Questions

What people check before pasting this in.

Is this real policy, or a mockup?+

Real. The rule kinds, field names and effects are the ones the API accepts, so the output can be pasted straight into a sandbox workspace. If a rule kind or setting were wrong, the API would reject it on write rather than at three in the morning.

Why is the daily window across all action types?+

Because that is the failure people do not see coming. A per-provider cap does not sum across providers, so a runaway loop on tool calls can consume the headroom a payment was going to need. One envelope across every action type is what stops that.

What does allowlist mode change?+

In allowlist mode anything not explicitly permitted is refused. Blocklist mode is the opposite and is the friendlier default while you are still discovering what your agent does. Start on blocklist in test mode, move to allowlist before live.

Does an approval block the agent?+

It holds it. The action gets a requires-approval answer and the reservation is kept while a person decides, so the agent waits rather than failing and nothing is spent in the meantime.

Where does a policy like this stop protecting you?+

At any path that does not ask. A control layer only binds the calls you route through it, so an agent holding a credential that reaches a rail directly is outside all of this. That is why an allowed decision comes back signed: make the executor demand the signature.

Now watch it deny something.

The policy above is only interesting when an action hits it. Sandbox keys take no card, the engine is the same one live mode runs, and a denial names the rule that refused.
Get API keysPolicy reference