Free tool · Real policy, not a mockup
Write the ceiling before you need it.
Configure your policy
Adjust the limits below. Your policy and API example update in this workspace.
Why it is data
A ceiling in a config file is a ceiling anyone can raise quietly.
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.
