Engineering · Action layer

Why the circuit breaker is compiled into the binary, not prompted

A system prompt that says “never drop a table” is a request. A function with no branch reaching DROP is a guarantee.

Last updated 27 July 2026

Every autonomous infrastructure tool eventually arrives at the same question: what stops the model from doing something catastrophic? The common answer is a system prompt. Some variation of you must never execute destructive operations, usually in capital letters, usually near the end.

That answer has a specific failure mode. A prompt is an input to a probabilistic system, and it competes for attention with every other token in the context window, including the ones an attacker controls. It is not a boundary. It is a strongly worded preference, and the strength of the wording is not correlated with the reliability of the outcome.

The boundary belongs where it can be proven

We use language models for the part that is genuinely hard: correlating commits, config diffs, traces and heartbeats into a ranked hypothesis about cause. That is reasoning over messy, unstructured signal, and nothing else does it as well.

We do not use them to decide what happens to your database. The execution engine carries a compiled allowlist. It permits exactly two operations today:

  • git_revert — a scoped revert, opened as a pull request through the same review flow your team already uses.
  • scale_replica — a patch to a Kubernetes scale subresource, which cannot change an image, a command, or an environment variable.

Anything absent is refused. Not discouraged, not scored, not weighed against confidence: refused, by raising an exception the calling code has no path to catch. A model that hallucinates DROP TABLE gets an error and a log line, not a production incident.

Two properties you get for free

Moving the boundary from the prompt into the binary buys two things that a prompt cannot offer at any level of wording.

It is auditable before you trust it. A prompt-based guardrail can only be evaluated empirically: run it many times and see whether it held. A compiled allowlist is a finite set you can read in a code review, and the absence of a branch is a fact rather than a probability. Your security team can confirm the property without running the system once.

It composes with the platform boundary. The allowlist is the second of two independent limits. The first is the Kubernetes ClusterRole, whose only mutating verbs are patch and update, and only on deployments/scale and statefulsets/scale. There is no create, no delete, no exec, and no access to Secrets. Even if the allowlist were somehow bypassed in-process, the API server refuses the call. Two mechanisms, different layers, no shared failure mode.

The cost, stated plainly

This design is worse than a prompt in one respect and we should be honest about it: it is rigid. Adding a capability means shipping a binary, not editing a string. When a customer asks for a new remediation primitive, the answer is a release cycle rather than a config change.

We think that trade is obviously correct for this product, because the failure modes are asymmetric. A slow capability rollout costs a quarter of roadmap. A guardrail that holds ninety-nine times in a hundred costs somebody their data, and it costs it at 3 AM, and it costs it in a way that no post-mortem gets back.

There is a related rule we apply to anything proposed for the list: every permitted action must be reversible by construction. A wrong revert is undone by reverting the revert, through the same pull request flow, with the reasoning attached. If an operation cannot be undone that way, it does not go on the list, however useful it would be.

What this does not solve

A compiled allowlist bounds what the system can do. It does nothing about whether the system is right. A confidently wrong causal hypothesis still produces a revert of an innocent commit, and the allowlist will happily execute it, because reverting is on the list.

That is a different problem, addressed by a different mechanism: a confidence threshold below which nothing executes and a human gets a written analysis instead. The allowlist is not the safety story. It is the part of the safety story that can be proven by reading it, which is why it is the part we put in the compiler.

See the boundariesMore engineering