Can your CrewAI agent spend money without your permission?

CrewAI Community Support
1

Your CrewAI agent can browse the web, write code, and call APIs.

Can it spend $500 without your permission?

If you have not explicitly set spending limits and an approval
layer, the answer is probably yes.

Curious how others are handling financial guardrails for agents
that touch real money or APIs with billing attached. Is anyone
solving this properly?

2

same problem here, just not CrewAI specific , I built a gateway that sits in front of agent-to-agent (A2A) calls and cuts an agent off once it hits its budget.

thing I didn’t expect going in: you can’t actually check what a task will cost before it runs, only after it responds. so the budget check ends up looking backward at everything that’s already happened, not forward at the request in front of it.

that has a real hole in it though. if two requests land at basically the same time, they can both check the budget before either one has recorded what it spent, so both get let through even when only one should. tested this on purpose , gave an agent a budget for about one request, fired five at once, all five got through.

wrote it up here: I built a spending gate for AI agents. Then I proved it doesn't hold under load - DEV Community

code’s here if you want to see the actual test that reproduces it: a2a-cost-gateway/tests/test_budget_race_condition.py at main · AliAbdallah21/a2a-cost-gateway · GitHub

curious if you’re seeing this on the CrewAI side too, or if it’s more of an A2A-specific thing

3

That’s an interesting challenge. I agree that simply checking the budget after execution leaves a race condition when multiple requests arrive simultaneously.

One approach that might help is introducing a reservation step before execution, where the agent temporarily reserves part of the available budget before making external API calls. If the task completes successfully, the reservation becomes a finalized spend; otherwise, it’s released. That won’t solve every distributed systems challenge, but it can prevent multiple concurrent requests from all believing the same budget is still available.

Thanks for sharing the article and test case—it was an interesting read.

4

This is a really interesting discussion. As I’m learning more about AI agents and automation, one thing that stands out is that spending limits alone may not be enough for production systems. Combining approval workflows, budget limits, and detailed logging seems like a safer approach, especially when agents can call external APIs or paid services. I’m looking forward to seeing how others implement these safeguards in real-world CrewAI deployments.

5

The runtime side of this — a gateway + a reservation step before execution, like @Ali_Abdalla1 and @Pawan_Thakur describe — is the right hard-stop, and it’s the layer you can’t skip, because it’s the only thing that catches a genuinely runaway loop live.

But I’d gently push back on one line: “you can’t actually check what a task will cost before it runs, only after.” For the predictable part of the cost you actually can, and it’s usually the biggest part. A large share of a multi-agent run’s tokens is fixed overhead that doesn’t depend on the customer’s input at all: the system prompt and the full tool schemas, which get re-sent and re-billed on every turn of every agent. That’s countable statically — tokenize the prompt template + tool JSON schemas, multiply by the model’s per-token price, multiply by expected turns — before a single call fires. The variable part (what the user actually asks) is the only bit you’re truly blind to until runtime.

So I’ve ended up running two layers, not one:

  • Runtime — the budget gateway you’re all describing: the reservation / hard-stop for the unpredictable spend.
  • Pre-merge — estimate the fixed-overhead cost of a crew in CI, so a PR that doubles the tool-schema bloat (or adds a sub-agent that re-sends everything) gets flagged before it ships, not after it’s quietly burned budget in prod for a week.

The second one is cheap to bolt on and catches the slow, structural cost creep that a runtime cap only ever catches after it’s already been spent. (I work on open tooling for the measurement half — npx @wartzar-bee/tokenscope for the static estimate, Apache-2.0 — happy to share the crew-overhead breakdown if it’s useful, but the two-layer split stands whatever you measure with.)

Genuine question for @Ali_Abdalla1: with your A2A gateway, can you attribute the hard-stop to a specific sub-agent when a crew blows its budget, or does it just cut the whole run? The “which agent ate the budget” attribution is the piece I keep finding hardest.