Setting a Spend Ceiling Your Agents Can't Talk Their Way Past
How a workspace-level policy caps what every agent run can spend, why it can only ever get stricter, and why it applies to admins too.
"AI agent burned through the budget" stopped being a hypothetical in 2026. One company exhausted a full year's AI budget by April. Another reportedly spent $500 million in a single month after rolling out AI access with no usage caps. Governance now eats 8–12% of the average enterprise AI budget, up from 3–5% just two years earlier — and most of that growth is organizations retrofitting controls they should have had from the start.
Piskes ships that control as a default, not an afterthought.
The policy table, and what it actually bounds
Every workspace has an agent policy that an admin — and only an admin — can set. It covers three things: a maximum dollar amount (tracked in micro-units of USD) any single run is allowed to spend, a list of capabilities that are simply forbidden regardless of what a run asks for, and a threshold above which a run must stop and wait for a human to approve it before continuing.
What makes this more than a suggestion is where it's enforced: at write time, when a run is actually about to do something, not as a report you check after the fact. A run that would exceed the ceiling doesn't get flagged in a dashboard three days later — it doesn't get to spend past the line in the first place.
Narrowing only — including for the person who set it
The detail that matters most here is the shape of the constraint: every column in the policy can only tighten, never loosen, and that includes the admin's own runs. Setting a $10 per-run ceiling doesn't create an admin exception where the person who set the rule can quietly spend past it. The policy binds the workspace it's set in, full stop.
That's a meaningfully different posture than a soft budget alert that anyone with the right role can dismiss or override in the moment. A spend ceiling that the most privileged account can talk its way around isn't really a ceiling — it's a suggestion with an audit trail. This one holds.
Why this beats a blanket "off" switch
The alternative most tools offer is binary: agents are on, or agents are off, and if costs get scary you turn the whole thing off. That's a blunt instrument that throws away the value of agent work along with the risk. A per-run ceiling, a forbidden-capability list, and an approval threshold let you keep agents doing real work while bounding the worst case — the same instinct behind spending limits on a corporate card, applied to a system that can otherwise act thousands of times faster than a person with a card ever could.
Setting it up
The policy lives in workspace admin settings, and because it's admin-only by design, it's worth deciding as a team — not as an individual contributor's guess at what "reasonable" looks like — what your per-run ceiling, your forbidden capabilities, and your approval threshold should be. A ceiling set too low will interrupt legitimate work with approval prompts constantly; one set too high defeats the purpose. Start conservative, watch what real runs actually cost over a week or two, and adjust the ceiling based on observed spend rather than a guess made before you had any data.
The point isn't to make agents expensive to use. It's to make sure nobody discovers the cost of an unbounded agent the way Uber or that unnamed enterprise did — by seeing the bill after it was already spent.