I was going through the news this morning and saw that Mozilla.ai had published its ACM FAccT 2026 write-up, From Evaluation to Guardrails, and it caught my eye. The piece makes an argument I have been thinking about, and trying to prove out with some recent POCs, except they brought data. The argument is simple: the guardrails we bolt onto LLMs deserve as much scrutiny as the models themselves, and most of them cannot actually do their job because they are judging from text alone.

Let me unpack why that matters, and where I think it lands differently in a bank than it did in a humanitarian setting.

Guardrails are the least-tested part of the stack

Testing guardrails is like writing unit tests: necessary, but not as sexy as building cool new agents. So we spend a lot of time on the models instead. We benchmark them, red-team them, run evals on evals. Then we wrap them in a guardrail layer, a classifier or a policy prompt that filters inputs and outputs, and we treat that layer as if it were infallible plumbing. Mozilla.ai’s framing is that guardrails “get far less scrutiny than the models they govern,” and that historically they were proprietary classifiers visible only through unexplained refusals.

In regulated environments, that is exactly backwards. The guardrail is the control. It is the thing your second line of defense points to when the regulator asks how you prevent the model from giving unsuitable financial advice or leaking material non-public information. If the control itself is unverified, you do not have a control. You have a vibe.

The finding that should change your architecture

The core experiment in the Mozilla.ai work is the part I keep quoting. They tested their policies and found a structural gap: some things cannot be judged from text alone. Which makes a lot of sense. An LLM is incapable of validating whether a fund exists, what the current rate is, or any business-specific information, the kind that comes from real-time news or your internal systems.

So Mozilla.ai’s hypothesis follows naturally: LLM-enabled guardrails need tools such as search, retrieval, and fact-checking to judge reliably. They built an agentic guardrail to test it.

The nuance I was happy to learn from this

Here is where I appreciate that they published real numbers instead of a demo that always wins. When they ran agentic versus non-agentic judges on the same responses, 90% of verdicts agreed. Tools changed the supporting evidence more often than they flipped the final answer.

If you only read the headline, you might conclude tools do not matter much. I read it the opposite way. In a regulated setting, the 10% where the verdict flips is the entire game, and the evidence trail on the other 90% is not a nice-to-have, it is the audit artifact. When an agentic judge verifies a factual claim and raises the score, or catches an error the text-only judge missed and downgrades a pass to borderline, that is documented reasoning I can hand to an auditor. “The model felt fine about it” does not survive an exam. “The guardrail checked the claim against an authoritative source and logged the result” does.

The other finding worth flagging: agentic behavior depended heavily on the judge model. Claude Sonnet 4.6 used web search on nearly every run, around 4.1 tool calls each. GPT-5 Nano almost never did, roughly 0.2. So “give the guardrail tools” is not enough. You have to verify the guardrail actually uses them, which is a testing discipline most teams do not have yet. Your guardrail can have a search tool wired up and still behave like a text-only classifier because the underlying model never reaches for it.

The bottom line

The shift Mozilla.ai is describing, from static taxonomies of harm toward dynamic, context-aware, tool-equipped policies, is not an academic refinement. For anyone putting agentic AI near money, advice, or regulated decisions, it is the difference between a control you can defend and one you are quietly hoping nobody tests. The models are getting good enough. The guardrails are the part that is still guessing, and that is where I would spend the next quarter of engineering effort.

Credit to Roya Pakzad and Daniel Nissani at Mozilla.ai for the research that prompted this. Their write-up is worth reading in full.