Guardrails

Guardrails are the controls that sit before and after each model call. Input guardrails screen what reaches the model: they detect prompt-injection attempts in user messages or retrieved documents, strip or mask personal data the model should not see, and reject requests outside the agent's remit. Output guardrails screen what comes back: they validate structured outputs against schemas, check claims against retrieved sources, block disallowed content, and confirm tool calls are well-formed and permitted before execution.

Guardrails are usually a mix of deterministic code (schema validation, regex, allow-lists, permission checks) and small classifier models (injection detection, topic classification, toxicity). Deterministic checks are cheap and predictable; classifiers cover cases rules cannot express. Both are tested with their own evaluation sets, because a guardrail that blocks too much is as harmful to the product as one that blocks too little.

Guardrails are not the same as policy gates, which apply business rules to specific actions; guardrails apply to every interaction regardless of action. They are also not a reason to trust a model with more access: least privilege on tools and data is the primary control, and guardrails are the second layer.

• CISO: guardrails are the application-layer defence against prompt injection and data exfiltration through AI features.
• Product manager: they keep the assistant on topic and on brand, which is what makes it shippable to customers.
• Compliance officer: masking personal data before it reaches a third-party model is often a regulatory requirement, not an option.
• CTO / Head of Engineering: schema validation on outputs is the difference between an agent that fails loudly and one that corrupts data quietly.

Models take instructions from their inputs, and inputs include untrusted content: customer messages, uploaded documents, web pages. Without guardrails a crafted input can redirect the agent, extract data or trigger tool calls it should not make. Guardrails exist to make those failure modes detectable and blockable at the boundary. The trade-off is false positives: over-eager filters frustrate users and hide legitimate requests, so guardrails need their own evals and tuning. They also add latency and cost per call, which is acceptable when proportionate to the risk of the action.

• A SaaS support agent that detects injection attempts in pasted content and refuses to change account settings on their basis.
• A banking assistant that masks account and card numbers before any external model call and validates every tool call schema.
• A clinical assistant that refuses to answer outside its approved protocols and flags any response not grounded in retrieved sources.
• A retail chatbot that stays on catalogue and order topics and declines requests for competitor comparisons or legal advice.
• An education tutor that applies stricter content filters and never collects personal details from learners who may be minors.

Technique / practiceAn engineering technique layered on least-privilege design. Eazyware builds input and output guardrails, with their own evaluation sets, into every agent under private agentic AI and every LLM application, and tunes them against false-positive rates as well as misses.

Eazyware service that covers it: Agentic AI Solutions (self-hosted). Starting prices are on the pricing page.