> ## Documentation Index
> Fetch the complete documentation index at: https://ctrlrun.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# CTRLRun and guardrail libraries

> Guardrail libraries inspect what goes into and comes out of a model. CTRLRun sits at the boundary between deciding to act and having acted.

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

|                                 | Guardrails                                   | CTRLRun                                                                 |
| ------------------------------- | -------------------------------------------- | ----------------------------------------------------------------------- |
| Input                           | prompts, completions, tool arguments as text | one canonical action: name, arguments, resource, principal, environment |
| Question asked                  | is this content acceptable                   | may this action run, has this effect already happened, what happened    |
| A refund that already committed | invisible: the text looks fine               | refused: the effect key is reserved                                     |
| A lost reply                    | invisible                                    | `AMBIGUOUS`; the retry is refused                                       |
| A human's approval              | not their concern                            | bound to the action's hash, single-use, expiring                        |
| Evidence                        | a filter decision, if logged                 | a receipt per action, chained, portable                                 |
| What it cannot see              | the second execution                         | the injected instruction that reads as legitimate text                  |

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

* [Why](/why): the boundary CTRLRun owns.
* [Fail closed](/concepts/fail-closed) · [Effect keys](/concepts/effect-keys).
* [Get started](/get-started/quickstart).


## Related topics

- [Why CTRLRun](/why.md)
- [CTRLRun](/index.md)
- [Try it in your browser](/try-it.md)
- [Running on Postgres](/postgres.md)
- [StaticIdentityProvider](/reference/api/StaticIdentityProvider.md)