HARDRAILS
The enforcement layer for AI agents in production. Hardrails sits between the LLM and every tool your agents can call, applying data access constraints the model cannot see, modify, or bypass.
The problem
Hardrails is the enforcement layer that sits between the LLM and every tool it can call, constraining what data and capabilities are available before the model runs.
You can write "only query the orders table" in a system prompt. The model might ignore it. A prompt injection might override it. There is no mechanism that prevents the model from reaching restricted data.
Without per-session data boundaries, serving N customers means building N agents, maintaining N configurations, and propagating every change N times. The cost of agent sprawl compounds with every customer.
When you give an agent database access, it can reach any table in that database. When you give it a search tool, it can search anywhere. Platform-level constraints are the only way to narrow that access.
Most platforms stop at extraction. Document Intelligence starts there.
Hardrails removes restricted data from the LLM's view entirely. The model does not choose to comply. Restricted tables, documents, and tool capabilities simply do not exist from its perspective. Constraints are stored in a layer the LLM cannot access, read, or write.
One enforcement model applies across document search, database queries, and external tools. Document access uses mandatory metadata filters. Database access uses platform-enforced query rewriting. External tools use parameter constraints and capability blocking. No gaps between tool types.
Build an agent once. Run it for every customer, every department, every access level, each with its own data boundary. Named, reusable execution policies define each scope. Change the agent once, the update applies everywhere. Each user sees only what their policy allows.
POLICY MODEL
The agent definition sets the ceiling. Named policies narrow within that ceiling. Per-session overrides narrow further. No layer can grant access beyond what the layer above permits, and the effective constraint is always the intersection: policies merge structurally, constraints combine with AND, and anything disabled in one layer stays disabled through all of them.
Named policies are stored and reusable. Create a policy called "northeast_readonly" and apply it across hundreds of sessions. Update it once and every future session uses the updated policy. No agent changes needed.
Every document search applies policy-defined metadata filters as mandatory conditions. Documents outside the policy's scope are invisible to the agent and to the model. There is no query the agent can form that returns out-of-scope documents.
The platform parses and rewrites every database query the agent generates, enforcing data boundaries at the query level. The agent only sees schemas for tables the policy allows. The effect is equivalent to database row-level security, enforced by the platform rather than the database.
External tool calls are validated against policy-defined parameter constraints before the call is dispatched. A web search can be restricted to specific domains. An email tool can be disabled entirely. Fixed parameters are removed from the agent's view so the model cannot change them.
Ambiguity denies access, not grants it. When a query falls outside defined scope, the request fails rather than proceeding with uncertain access. Every tool call, every query, every document search operates under this default. There is no fallback that widens scope.
Constraints are not stored in the prompt, the conversation, or anywhere the LLM can read. A prompt injection cannot instruct the model to reveal or modify the policy. Even if the model knew where the constraints were stored, there is no tool or interface it could use to access them.
Every session records its effective policy, every tool call dispatched, and the constraints applied at each step. You can prove what data was accessible and what was actually accessed, for every user, for every interaction. Exportable for compliance review, customer audits, or internal governance.
Use Cases
One data corpus. Multiple experiences. Meibel lets you process your data once and build as many solutions as you need on top, without reprocessing or rebuilding your pipeline.
.webp)
Comparison
Four ways to constrain an agent. Only one enforces.
Hardrails is built for the scale and compliance requirements of production AI deployments.
Try Meibel
Connect your agent. Apply an execution policy. See enforcement in action on your own data.
A system prompt tells the model what it should do. Hardrails enforces what the model can do. Constraints are stored in a secure layer the LLM cannot access. The model does not choose to comply with scope restrictions. Restricted data and capabilities simply do not exist from its perspective.
Yes, by design. Constraints are not stored in the prompt, the conversation, or any interface the model can read or write. A prompt injection cannot instruct the model to reveal or change the policy because there is no tool or mechanism the model can use to reach the constraint layer.
The platform parses and rewrites every SQL query the agent generates before it reaches the database. The rewrite enforces the policy's table and row restrictions. The agent only sees schemas for tables the policy allows. The effect is equivalent to database row-level security, enforced at the platform level rather than the database level.
Hardrails enforces constraints uniformly across three tool types: document search (mandatory metadata filters), database queries (platform-enforced query rewriting), and external tools (parameter constraints and tool blocking). One enforcement model, no gaps between tool types.
An execution policy is a named, stored configuration that defines what data and tool capabilities are available in a session. Policies compose in layers: the agent definition sets the ceiling, a named policy narrows within it, and a per-session API parameter can narrow further. Each layer can only restrict, never widen. You attach a policy to a session at the API level when you start each interaction.
Yes. That is the design pattern Hardrails makes reliable. One agent definition serves every scope. Each session carries its own execution policy, which defines that session's data boundary. Customers, departments, and access tiers each get their own policy. Change the agent once, the change applies to every future session.
Yes. Hardrails enforces constraints before the LLM runs, at the tool dispatch layer. It is model-agnostic. You can use Hardrails with any model supported by the Meibel platform.
.webp)
