Skip to main content
A guardrail library reads text: the prompt going in, the completion coming out, sometimes a tool call’s arguments, and it blocks or rewrites what it does not like. CTRLRun does not read text at all. It sits one layer down, where a decision becomes an effect, and asks whether this exact action may run, whether it has already run, and what to record.

What guardrail libraries are good at

Catching things that are visible in language: personal data in a completion, a jailbreak attempt in a prompt, an off-topic answer, a toxic response, a schema a tool call does not match. They run fast, they are model-aware, and they are the right tool for the failure modes that live in the text.

What they do not do

That last row is the pair. A guardrail can spot an injected instruction in the page an agent read. CTRLRun cannot: the refund request that arrives looks exactly like a real one. What CTRLRun does instead is make the consequence survivable: the refund needs a grant the agent does not hold, the amount needs a human, the recipient is bound to what the human saw, and the effect happens once.

When to use both

Most deployments that matter want both, in this order: a guardrail on the model’s input and output, and CTRLRun in front of the calls that change the world. They fail differently, which is the point of having two. A guardrail that misses one injection has let a request through; if that request must still get past authority, policy, a human and an effect key, the injection has not bought much.

The distinction that matters

Guardrails are about what is said. CTRLRun is about what is done. A library that filters text cannot tell you whether the refund happened twice, and a library that owns effects cannot tell you whether the completion was rude.

Next