Every team deploying LLM agents eventually confronts the same question: what actually prevents the agent from doing something it shouldn't? Agents act through tools. They query databases, search document stores, send email, call external APIs. A tool grant is broad by default. An agent that can query your database can query any table in it, and an agent that can send email can send it to anyone.
Most teams answer this with instructions in the system prompt. That's policy without enforcement. The model follows instructions most of the time, but "most of the time" is not a security posture, and prompt injection turns a well-behaved agent into one that follows someone else's instructions instead. OWASP's RAG security guidance is direct on this point: "[Don't] Rely on the language model to enforce access control. Access control must be enforced before content reaches the model." If your data-access guarantees live in a prompt, you don't have guarantees; you have suggestions.
We built Hardrails to close that gap. It's the enforcement layer in our agent platform: constraints defined outside the model, applied by the platform on every tool call, that the model cannot see into, modify, or bypass. This post explains what that buys you and what to look for when you evaluate any agent platform's answer to the same problem.
Before the security argument, there's a simpler one about multi-tenancy and the deployment economics that come with it.
Say you build one agent that answers questions over your data, but different users are entitled to different slices of it. One analyst should see only Client A's records. Another should see Clients A and B, but only for one region. Without per-session controls, each distinct scope means another copy of the agent, possibly another copy of the data, and your team maintaining, auditing, and syncing all of them.
With Hardrails, scope is a runtime parameter. The agent is defined once. Each session carries an execution policy, a declarative object that states what data that session can reach and what arguments the agent may pass to its tools. Every tenant runs the same agent under its own policy, whether that's ten customers or ten thousand users with distinct entitlements. Your engineers maintain one artifact; your policies express the differences.
The isolation itself is not optional. OWASP's RAG security guidance treats it as a baseline requirement: "In multi-tenant or multi-classification environments, vector stores must prevent cross-boundary data leakage. A query from one context must not retrieve chunks from another context. This is mandatory for any organization handling multiple clients, departments with different security clearances, or regulated data." Execution policies are how Hardrails meets that requirement: the boundary is attached to the session, and every query it issues is filtered before results return.
Policies are named, stored, and composable, which turns entitlements into governance building blocks (no_pii, northeast_only, email_locked) rather than code changes. It's also what makes agent sharing viable across team or company boundaries. The creator shares the agent and attaches policies to the share; the consumer runs it without seeing the policies or being able to widen them, so handing an agent to another team stops being a security decision.
Enforcement means the model's cooperation is beside the point. When the agent queries a database, the platform rewrites the query before execution so it can only touch the data the session's policy allows. The rewrite happens after the model has produced the query, outside the conversation, so a prompt injection can tell the model to ignore its restrictions and nothing changes. Every tool type gets the same treatment: document search results are filtered before the model sees them, tables and columns outside scope are removed from what the model is shown and independently blocked if referenced anyway, and arguments to external tools are validated against the policy before the call is dispatched.
Two design details do most of the work here, and they're worth asking any vendor about. The first is that enforcement is layered. Hiding a table from the model's view is good hygiene; rejecting any query that references it is what makes the guarantee hold, and each control has an independent backstop like that, so a failure of the polite mechanism doesn't become a breach. The second is that the policy itself is out of reach. It's resolved before the session's first model call, stays immutable for the session's lifetime, and no tool exposed to the model can read or write it. There is no key, path, or API for an injected instruction to target, even one that knows exactly how the system works.
A subtlety we learned in practice: hiding everything from the model doesn't make the system safer, and it does make the product worse. Where knowing the rules helps the model behave, the platform tells it. Parameter limits appear in tool descriptions so the model makes valid calls on the first attempt. Data-scope boundaries are described to the query-writing model so that, asked about data outside its scope, it can say the data isn't available instead of hallucinating an answer from empty results. Both accuracy and user trust are better for it.
Where knowledge adds nothing, things stay invisible: disabled tools aren't in the toolkit, and out-of-scope documents never surface. None of this disclosure changes what's enforced. Telling the model the rules is a usability choice, and enforcement doesn't hinge on it.
Most of the real risk lives at the edges, so it's worth spelling out how the system behaves there.
Policies can only narrow. The agent's author sets a ceiling on what the agent could ever access. Session policies restrict within it, and when multiple policies apply they combine by intersection. There is no override path, so a misconfigured session policy can't widen access.
Configuration errors surface before execution. A policy referencing a misspelled table, a nonexistent field, or the wrong parameter name is a policy that silently protects nothing. Hardrails checks every reference against the real schemas before the session's first model call and refuses to start, listing every problem. Your team finds out at deploy time, not in an incident review.
Ambiguity resolves to denial. A document missing a required metadata field is invisible. An argument that violates a constraint blocks the call. Conflicting constraints fail the affected calls rather than picking a winner.
For audit and compliance, the effective policy for each session is a single resolved artifact: you can state, per session, exactly what constraints governed it.
Whether or not you evaluate ours, these questions separate enforcement from decoration:
If the answer to the first question is "the system prompt," the platform doesn't have guardrails. It has requests.
Agents become deployable at scale when access control moves out of the prompt and into the platform. Industry guidance has settled in the same place: OWASP's prompt injection guidance concludes that prompt-level defenses only slow a determined attacker, and that proposed actions must be screened against policy by machinery the model can't influence. Hardrails makes an agent's boundaries declarative, per-session, auditable, and enforced at the point of execution. Your teams build one agent instead of one per entitlement, and your security review approves a policy rather than trusting a prompt. The model can be told the rules when that helps it do its job; it's never the one enforcing them.
Ready to start your AI journey? Contact us to learn how Meibel can help your organization harness the power of AI, regardless of your technical expertise or resource constraints.
Spencer Torene serves as Principal Research Scientist at Meibel, where he shapes the platform's confidence scoring and runtime evaluation systems. He holds a Ph.D. in Computational Neuroscience from Boston University (2010-2017) and brings expertise in machine learning and AI research. Prior to Meibel, Spencer spent over six years at Thomson Reuters Special Services, progressing from Senior Research Scientist to Manager of Research and Development (2018-2024), where he led AI and machine learning R&D initiatives. He earned his Bachelor of Science in Computer Science from the University of Maryland (1999-2004) and completed the Leadership and Management Certificate Program at Wharton Online (2021).
REQUEST A DEMO
See how Meibel delivers the three Cs for AI systems that need to work at scale.
