Temprl Labs presents
Compare · security
Guardrails for agents: filters, classifiers, LLM judges and Guard
Every agent team ends up choosing how to check steps. The options differ in what they can see, what they return, and whether you can afford to run them on every step.
The options
| Approach | What it checks | What it returns | Your own rules? |
|---|---|---|---|
| Keyword and regex filters | Known strings and formats | Match or no match | Only as patterns |
| Injection classifiers | Whether input looks like an attack | One fixed score | No: the categories are fixed |
| LLM-as-judge prompts | Anything you can describe | Prose to parse, or a number with no calibration | Yes, in the prompt |
| Simo Guard | Input, each tool call and each reply, against your policy | A calibrated score per check, a decision and evidence | Yes: checks you define, per tool |
What matters for agents
- The action, not only the input. Filters and input classifiers see text coming in. Attacks do damage at the tool call, so the check has to see the action, the policy and what the agent read.
- Your rules. “Refunds over $50 need a manager” is not in any classifier’s label set. Guard checks are written by you.
- A number you can threshold. A judge prompt that writes “this looks risky” gives you nothing to set a threshold on. Guard’s calibrated scores do.
- Cost per step. A judge that reasons at length on every tool call adds seconds per step. Guard reads the step once and answers every check in the same pass, in milliseconds. See Simo vs reasoning models.
Use them together
Filters are cheap and exact for known secrets formats; keep them. Least-privilege tools and hard limits in code stay essential. Guard adds the judgment none of them can make: does this step, in this context, break this policy?
Frequently asked questions
Is Simo Guard an LLM judge?
It plays the same role with a different shape: one read of the step, typed checks, and a calibrated probability for each, instead of a written verdict.