As companies deploy AI agents, a legitimate question about security arises — and with it a frequent confusion. You hear the phrase said naturally: "the agent has guardrails, so the data is protected." That sentence mixes two things that operate on different planes. Guardrails and data access control are both necessary, but they aren't interchangeable, and one cannot do the other's job. This article explains what each one is, what it's for, and —above all— why guardrails, however good, don't protect the data.
What guardrails are
A guardrail is a control layer that sits between the user and the language model, and between the model and the final response. Its job is to inspect what comes in and what goes out: it examines the prompt before it reaches the model, and examines the response before it reaches the user, blocking or rephrasing whatever breaks a set of defined rules.
Guardrails serve valuable, real purposes:
- Blocking prompt injection and jailbreaks — attempts to manipulate the system instructions so the model does something it shouldn't.
- Filtering toxic, offensive, or off-topic content — keeping the agent within the subjects it was designed for.
- Detecting and redacting PII in what the model is about to emit.
- Reducing hallucinations through checks or verification against a knowledge base.
Tools like NeMo Guardrails (NVIDIA), Guardrails AI, or LLM Guard implement exactly this. They are serious, useful pieces. The important point is to understand how they work, because from that you can deduce what they can and cannot guarantee.
How they work: the control is over behavior, not over the data
A guardrail acts on language: on the text that comes in and the text that goes out of the model. It detects patterns —adversarial, toxic, sensitive— and decides based on them. And that detection is, by nature, statistical: a classifier, an embeddings comparison, a set of examples, a model that estimates the probability that a text is an attack or contains something improper.
This has a consequence worth facing head-on: a statistical mechanism gets it right almost always, but not always. There is already empirical research dedicated to evading guardrails — to constructing inputs that slip past prompt injection and jailbreak detectors. That an entire field of study exists on how to bypass them is not a flaw of a particular implementation: it's the nature of any defense based on recognizing patterns in language. There's always a new formulation the classifier didn't see.
For many uses, that "almost always" is perfectly acceptable. An assistant that avoids, 99.5% of the time, responding rudely or going off-topic is an excellent outcome. But there's a domain where "almost always" isn't enough, and it's precisely that of the data.
Why guardrails don't protect the data
Here is the core of the argument. A guardrail watches what the agent says. It does not govern what the agent accesses.
Let's see it with an example. Suppose a portfolio-analysis agent at a financial institution. Its legitimate task is to assess the suitability of a customer's portfolio. For that it needs that customer's positions — and nothing else. It doesn't need their declared medical history, nor other customers' data, nor their credit-risk score.
With a guardrail-based approach, the data remains technically accessible to the agent; what's attempted is that it not put it out — that it not include in its response what it shouldn't. If, through an unexpected phrasing of the task, an unforeseen chain of reasoning, or a malicious input, the agent accesses another customer's data, the guardrail has a single chance to catch it: to detect, in the output text, that something is there that shouldn't be. If it doesn't detect it —and a statistical mechanism will fail sometimes— the data has already gone out. Worse still: the agent already accessed it, held it in its context, could combine it with other information and derive conclusions. The harm isn't only what gets emitted; it's what got touched.
The guardrail, by design, arrives too late for the data. It watches the exit door of language, when the problem already happened at the entrance door to the data.
The other model: structural control of access
opendome's approach operates on the opposite plane. It doesn't try to make the agent not say what it shouldn't: it makes the agent unable to access what its task doesn't justify. The control is not at the language output, but at access to the data.
The mechanism is what we call the Cell Model. Each access is decided individually, at the moment it happens, evaluating four dimensions at once: which agent is asking, for which task, over which specific data —at the field level, not the record level— and in which context. Only when the combination is legitimate does the cell open; if any of the four fails, the data is not accessible. There are no inherited accesses, no leftover permissions, no back door through which the data can leave.
In the earlier example, the portfolio-analysis agent doesn't "hold back" from showing another customer's data: that data simply never enters its reach. The policy isn't asked of the agent via prompt — it's imposed by infrastructure, beneath it, where the agent has no ability to circumvent it because it takes no part in the decision.
The key difference: reproducibility
And here is the property that changes everything, and the one worth underlining: the Cell Model's decision is reproducible, not statistical.
A guardrail estimates. Faced with the same input phrased two different ways, it may get one right and the other wrong, because its verdict depends on a pattern recognition that has a margin of error. The Cell Model doesn't estimate: it evaluates a deterministic rule. Given the same combination of agent, task, data, and context, the decision is always identical — today, tomorrow, and the millionth time. There is no accuracy percentile: there is a correct answer that is produced every time.
This difference —between the statistical and the reproducible— is exactly what separates a good intention from a guarantee. In an environment regulated by GDPR, DORA, or the EU AI Act, it's not enough to reduce the probability of a leak: you have to be able to demonstrate, to an auditor, that an improper access could not occur, and that every access that did occur was logged with its full context. A statistical measure can't be demonstrated: you can only measure its accuracy rate. A reproducible measure can — because its behavior is the same every time and is inscribed in the architecture itself.
It's the same difference as between placing an attentive guard at the exit of a room full of confidential documents, and letting into the room only the documents the task requires. The guard, however good, has a bad day. The room that only the right things enter doesn't depend on anyone having a good day.
It's not a choice: it's understanding what each one does
None of this means guardrails are superfluous. On the contrary: they are complementary, because they protect against different things. The two models, together, cover a spectrum that neither covers alone:
- Guardrails protect the agent's linguistic behavior: that it not be manipulated by prompt injection, that it not generate toxic or off-tone content, that it not stray from the conversational purpose. They operate on language, and for that they are the right tool.
- Structural access control protects the data: that the agent can only touch what its task justifies, reproducibly and auditably. It operates on access, and it's the only way to guarantee protection of the data.
Where guardrails don't reach: to prevent access to a piece of data, to guarantee demonstrably that something cannot happen, to produce an auditable record of what was touched and why. Where they do reach: to moderate and channel what the agent says, to stop attacks on its behavior, to keep it within its purpose.
The conclusion is simple and worth fixing. If the question is "is my agent behaving well?", guardrails are part of the answer. If the question is "is my data protected?", guardrails are not the answer — structural, reproducible access control is. Confusing the two questions is what leads to believing the data is safe because the agent "has guardrails." It isn't. It's safe when the data that isn't meant for it never comes within its reach.
Sources
- AI Safety Directory, LLM Guardrails: The Complete Guide (definition, input/output/system guardrails, EU AI Act) — https://aisecurityandsafety.org/en/guides/llm-guardrails/
- Langfuse, LLM Security & Guardrails (input/output scanners, PII, toxicity) — https://langfuse.com/docs/security-and-guardrails
- WitnessAI, LLM Guardrails: Securing LLMs for Safe AI Deployment (prompt injection, jailbreaks, RAG) — https://witness.ai/blog/llm-guardrails/
- Bypassing LLM Guardrails: An Empirical Analysis of Evasion Attacks (arXiv:2504.11168) — https://arxiv.org/pdf/2504.11168
- NVIDIA NeMo Guardrails — rail types (input, dialog, retrieval, execution, output) — https://appsecsanta.com/nemo-guardrails