API-level spend caps solve the "how much" problem but not the "why." The agent still loops 50 times before hitting the limit. You just lose $50 instead of $200.
The missing layer is detection inside the agent loop itself. If the agent is calling search_kb for the 8th time with slightly different args, or about to issue a refund it already issued, you want to catch that at iteration 3, not at the dollar ceiling.
I built an open-source middleware called Aura Guard (https://github.com/auraguardhq/aura-guard) that does exactly this. It sits in the agent loop and detects repeated tool calls, argument jitter, duplicate side-effects, stall patterns, and budget overruns. When it catches a loop it can rewrite the prompt, return a cached result, or escalate instead of letting the agent spin until an external limit kills it.
Zero dependencies, framework-agnostic, works with any LLM provider. Has a shadow mode so you can see what it would catch without blocking anything.
Your approach and this are complementary. Spend caps at the proxy level, loop detection at the agent level. Both are needed if you're running agents in production.
This is exactly the problem. The blast radius question is real. One pattern I've been exploring is a deterministic governor that sits between the agent loop and the tools. Before any tool executes, it checks: is this a repeat? Is this tool quarantined because it's been failing? Is this a side effect that already fired? Have we exceeded the cost budget? The decision is pure computation, no LLM calls, just counters and signatures. It won't solve the permissions problem, but it limits how much damage an agent can do once it has access.
One thing I haven't seen discussed much is enforcement at the tool-call boundary, specifically the moment between 'the model wants to call this tool' and 'the tool actually executes.' Most safety approaches focus on content (output filtering, prompt injection) or infrastructure (sandboxing, permissions). But there's a gap for runtime behavior: detecting that the agent is stuck in a jitter loop (rephrasing the same query slightly each time), that a side-effect tool fired twice with near-identical args, or that the model is stalling with apologetic non-progress text. I've been building something in this space and found that deterministic checks (HMAC signatures on tool+args, overlap coefficients on outputs) catch most of these without needing another LLM call.
Author here. Happy to answer questions.
If you’ve dealt with “rephrase & retry” tool loops or duplicate side effects (refund/email twice), I’d love feedback on the heuristics and thresholds.
Quick demo is aura-guard demo after install. Repo has a benchmark harness + JSON reports.
The missing layer is detection inside the agent loop itself. If the agent is calling search_kb for the 8th time with slightly different args, or about to issue a refund it already issued, you want to catch that at iteration 3, not at the dollar ceiling.
I built an open-source middleware called Aura Guard (https://github.com/auraguardhq/aura-guard) that does exactly this. It sits in the agent loop and detects repeated tool calls, argument jitter, duplicate side-effects, stall patterns, and budget overruns. When it catches a loop it can rewrite the prompt, return a cached result, or escalate instead of letting the agent spin until an external limit kills it.
Zero dependencies, framework-agnostic, works with any LLM provider. Has a shadow mode so you can see what it would catch without blocking anything.
Your approach and this are complementary. Spend caps at the proxy level, loop detection at the agent level. Both are needed if you're running agents in production.