A proposed circuit breaker for code-review agents defaults its security guardrail to None

A microservice breaker counts things that are visible at the call boundary. It opens after N failures in a rolling window and stops traffic so the service can recover ^[16]. Three of the four signals in this design have that property: tokens spent on a single pull request without reaching a conclusion ^[5], a review step that runs past its SLO ^[8], and an identical correction regenerated and caught by hash similarity ^[6]. Hash similarity catches an agent that repeats itself verbatim, and an agent that paraphrases its own bad fix produces a new hash.

The fourth signal needs a verdict from somewhere else: a smaller, faster LLM or a static analyzer flagging the generated code as high-risk, with `eval()` and hardcoded secrets given as the examples ^[7]. In the constructor, `security_guardrail` defaults to `None` ^[10]. Security is one of the four blast-radius dimensions the post names, alongside cognitive, resource and operational ^[12].

The failure list opens with hallucinated context, an agent misreading the architectural intent of a module ^[13]. A confidently wrong review spends few tokens and returns inside the SLO, and it does not repeat itself. None of the three cheap signals fire, and the design has no other criterion that would.

`failure_threshold=5, recovery_timeout=300, token_budget=10000, security_guardrail=None` ^[10]. The article defines token exhaustion per pull request ^[5], so the default gives one PR 10,000 tokens to reach a conclusion ^[11]. That is workable on a two-file diff. On a schema migration the breaker opens on budget, and OPEN blocks every autonomous action and hands the work to human review only or static analysis only ^[2].

HALF-OPEN is where I would expect the pattern to strain. In a service breaker the probe is the same kind of request that was failing, so its outcome is evidence. Here the trial admits a limited set of low-risk actions to test whether context drift or model instability has resolved ^[4]. A low-risk action succeeding on some other PR tells you little about the input that opened the circuit; the trial would have to replay the pull request that tripped the breaker.

Then there is scope. `failure_count` lives on the breaker instance ^[10]. One breaker per PR and the count resets every review, so a bad prompt update never reaches five. One breaker per repository and a single pathological diff parks every other review in Safe Mode. The post's stated motivation covers both cases: a buggy prompt engineering update or a specific edge-case PR driving an agent to keep generating bad code, exhaust API tokens, or introduce subtle security flaws into the main branch ^[14].

The published snippet stops mid-signature at `async def execute_actio` ^[17], so the interception itself is not in the text. I would copy the placement: the middleware wraps the agent's execution loop and intercepts every action the agent requests to perform, and the checks do not sit inside the prompts ^[9], so they still run when the model ignores its instructions.