Types of LLM Guardrails: Input, Retrieved-Context, Output and Tool-Execution Layers

A customer pastes a full account number into a billing dispute, and the support agent calls a refund tool with that number in the arguments, then repeats it in a reply that streams back to the chat window.

The request passed through the LLM gateway and the tool call reached the server, but nothing on that path inspected the prompt or the tool-call arguments. The reply also went unchecked.

The prompt, the retrieved context, the reply and the tool call are separate enforcement points, and each needs its own guardrail layer.

What an LLM Guardrail Is

A large language model (LLM) guardrail is a runtime control on the inference path that inspects a prompt, a piece of retrieved context, a model response or a proposed tool call against a defined policy, then allows, blocks or redacts that content before it reaches the model, the user or a downstream system. A 2024 International Conference on Machine Learning (ICML) position paper on building guardrails for LLMs describes the same mechanism: an algorithm that takes LLM inputs or outputs and determines whether and how to take enforcement actions [1].

A system-prompt instruction, a static prompt filter, an offline evaluation and model alignment each fail the opening scenario for a different reason:

• System-prompt instruction: A system prompt tells the model how to behave, and the model may or may not comply. OWASP's LLM08:2026 entry states that hidden context such as the system prompt should not be relied on as the primary mechanism for controlling model behavior, because prompt injection can override it, and that critical behaviors should be enforced by independent, deterministic controls outside the LLM [2]. A guardrail is that outside system.
• Static prompt filter: A keyword or regex blocklist runs on the request but cannot score intent, so paraphrased, encoded or cross-lingual attacks pass it.
• Offline evaluation: An evaluation scores a test set before release or a sample of production traffic after the fact. It reports a rate, such as how often a retrieval-augmented generation (RAG) application answers outside its retrieved context, which application teams use to improve the next release. It does not touch the request that is leaking right now.
• Model alignment: Safety training changes the model's weights, so changing a rule means retraining. The ICML paper treats guardrails as post-hoc filters that operate alongside model training rather than inside it, which lets teams change a policy at runtime [1].

Within an AI governance program, LLM guardrails are the policy-enforcement component, alongside the inventory of applications and agents, their owners and lifecycle status, and the retained evidence of which policy action each guardrail applied and why.

Input Guardrails: Blocking Injection, Jailbreaks and Sensitive Data in Prompts

Input guardrails inspect the prompt before the model is invoked, and they are often the first layer deployed. They address what the user, or an attacker posing as the user, sends in:

• Prompt screening: OWASP's 2026 LLM Top 10 defines prompt injection as input that alters model behavior in ways the developer did not intend [3]. OWASP treats jailbreaking as the subset of prompt injection aimed at violating safety protocols [3]. The same list notes that LLMs make no architectural distinction between instructions and data [3]. A detector scores each prompt and blocks above a threshold, but static pattern lists and classifiers both degrade under adaptive attack. Nasr et al. bypassed 12 recent defenses with attack success above 90% for most [4]. Pair detection with the architectural controls in the later layers.
• Topic and scope restriction: A scope guardrail rejects or redirects requests outside the application's purpose, such as a billing agent asked for medical advice. A runtime scope check enforces that boundary outside the model, so the model's willingness to comply no longer decides the outcome.
• PII and secret redaction: The guardrail detects personally identifiable information (PII) and protected health information (PHI) in the prompt. It also detects secrets such as API keys and database credentials, and redacts the sensitive data before the prompt leaves the network for a model provider. OWASP's LLM02:2026 entry recommends combining classifiers with named-entity recognition, supplemented by pattern matching, since regex alone fails on encoded and cross-lingual text [3]. In the opening scenario, a redaction check on the request would have masked the account number before the model saw it.

Retrieved-Context Guardrails: Catching Instructions Hidden in RAG and Tool Results

Retrieved-context guardrails scan what the application pulls into the model's context window from outside the conversation: RAG chunks, tool results, fetched web pages, files and agent memory. OWASP's 2026 prompt-injection definition lists retrieved content and tool output among the input sources that can carry an injection [3]. This layer exists because the input guardrail never sees those sources; it ran before retrieval happened.

The attack this layer catches is indirect prompt injection, where instructions planted in a document or a web page are read as commands once the agent retrieves them. The mechanics and runtime defenses are covered in Fiddler's guide to indirect prompt injection. The check runs on each chunk or tool result between retrieval and context assembly, before the model reads it. The retrieved chunks this layer scans also become the reference the output faithfulness check scores against.

Output Guardrails: Stopping Leaks, Hallucinations and Malformed Responses

Output guardrails inspect the model's response before it reaches the user or a downstream system, and they catch what the model produced on its own, whatever the input looked like. OWASP's LLM02:2026 entry lists the disclosure channels a response check has to cover: final answers, tool-call arguments, reasoning traces, retrieved chunks, logs and telemetry [3].

• Toxicity and content safety: The check classifies the response against the content categories the policy prohibits and blocks it before delivery, since a benign prompt can still yield a harmful completion.
• Faithfulness and hallucination: For a RAG application, the check scores whether each claim in the response is supported by the retrieved chunks and blocks or flags responses that drift from them.
• PII and secret leakage: The response can contain data the prompt never did: a customer record from a tool return, a credential from a file read, or a key the model memorized. In SearchLeak (CVE-2026-42824), a 2026 Microsoft 365 Copilot flaw, a crafted search URL made the copilot place mailbox, calendar and file data in an image URL that streaming rendered before sanitization ran [5]. In the opening scenario, this check is where the echoed account number gets redacted from the reply.
• Format and schema validation: When output feeds a backend function, OWASP's 2026 guidance says to define a strict output schema, validate it in trusted application code using structural validation rather than a second LLM call, and treat the model as any other user whose responses are validated before backend functions receive them [3]. This is a low-cost guardrail and the one to deploy first on any output that a program, rather than a person, will consume.

Tool-Execution Guardrails: Stopping Unauthorized and Out-of-Policy Actions

Tool-execution guardrails, also called tool-call guardrails, sit between the model's proposed call and the tool, API or Model Context Protocol (MCP) server that would execute it. At this layer, the tool executes the model's proposed action, with consequences. Gartner surveyed 297 cybersecurity leaders in the second quarter of 2026; 54% either had no defined approach to limiting AI agent access or relied on access rules predefined for humans [6]. OWASP ranked Excessive Agency third in its 2026 LLM Top 10 based on community votes and recorded incidents involving agentic deployments [3].

• Allowlists: The gateway publishes only the tools permitted for the application or its access credentials and team, and denies everything else. The MCP specification, revision 2026-07-28, requires that tools/list return only the tools available to the requesting client, and that clients treat tool annotations as untrusted unless they come from trusted servers [7].
• Argument validation: The gateway checks each call's arguments against the tool's schema and against policy before execution. The MCP specification requires servers to validate all tool inputs and to declare a valid JSON Schema as inputSchema, and it recommends that clients validate results before passing them back to the model [7]. OWASP's LLM03:2026 entry adds that authorization belongs in deterministic application logic [3]. In the opening scenario, an argument policy that accepts only a masked account reference in refund-tool calls rejects the full number before execution.
• Approval thresholds: Policy decisions apply before a consequential call executes. A policy engine allows or blocks the call, or pauses it for human review. The MCP specification states that “There SHOULD always be a human in the loop with the ability to deny tool invocations” [7]. OWASP recommends explicit human confirmation for privileged actions and for those that are irreversible or externally visible [3].

How to Choose and Layer Guardrails

Layering guardrails at all four points gives defense in depth. Each layer inspects content the others never see, so an attack that slips past one check can still be caught at the next.

A guardrail check reaches its decision in one of three ways:

• Deterministic rules: Regex patterns, allowlists and schema validation. They are fast and predictable, but they cannot judge intent or meaning.
• Classifiers: Small trained models that handle injection scoring, toxicity scoring and PII detection. They generalize beyond fixed patterns and add some latency per check.
• LLM-as-a-Judge: A large model prompted to grade content. It handles nuanced judgments but adds the most latency. When it calls an external API, it sends the content across the network boundary described in the deployment boundary discussion below the table.

Content filtering at any layer can combine these methods, starting with the deterministic rule and adding a model only where the rule cannot decide.

The table compares the four types of guardrails by placement, coverage and request-path cost:

• Deployment boundary: Teams choosing where to run the scoring model must account for the guardrail's own data-exposure path. A guardrail that sends each prompt to an external moderation or judge API moves the content it is supposed to protect across the network boundary.
• Latency budget: Nielsen Norman Group's response-time limits put 0.1 seconds as the point where a response feels instantaneous and 1.0 second as the limit for an uninterrupted flow of thought [9]. Set a per-check budget and measure it under production load.

Security teams use red-team tests against the application to identify what each layer must block: successful injection strings and leakage paths, along with tool-call sequences that succeed today. The security team turns each confirmed finding into a policy or threshold adjustment, or an allowlist entry at the matching layer, then adds a regression test after the fix.

How Fiddler Enforces Guardrails Inline

Closing all four layers means running checks on the request path without adding noticeable delay or sending the content being protected outside the environment. Fiddler Guardrails runs inline on the existing LLM or MCP gateway, including LiteLLM, AgentGateway and Kong Gateway, with under 80ms response time. At each layer, it allows, blocks or redacts content, whichever the policy calls for:

• Input: Checks the prompt for prompt injection and jailbreaks, and runs PII/PHI detection and redaction and secret checks, before the model is invoked.
• Retrieved context: Scans RAG chunks, tool returns and file reads for indirect prompt injection and secrets before the model reads them.
• Output: Checks the response for toxicity, PII/PHI and secrets, and scores hallucination and faithfulness for RAG applications, before it reaches the user or a downstream system.
• Tool execution: On the MCP gateway, enforces tool allowlists and validates tool-call arguments before a call runs.

The batteries-included, out-of-the-box Fiddler Centor Models score these checks in-environment, so guardrail scoring does not send prompts or responses to an external LLM API.

Request a demo to review how inline enforcement would fit the LLM or MCP gateway architecture already in place.

References

[1] Y. Dong et al., “Position: Building Guardrails for Large Language Models Requires Systematic Design,” in Proc. 41st Int. Conf. Machine Learning (ICML), PMLR 235, pp. 11375-11394, 2024. Accessed: Oct. 20, 2026. [Online]. Available: https://proceedings.mlr.press/v235/dong24c.html.

[2] OWASP GenAI Security Project, “LLM08:2026 Hidden Context Exposure,” GenAI-LLM-Top10 repository, GitHub, 2026. Accessed: Oct. 14, 2026. [Online]. Available: https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/final/LLM08_HiddenContextExposure.md.

[3] OWASP GenAI Security Project, “OWASP Top 10 for LLM Applications 2026,” OWASP, 2026. Accessed: Oct. 14, 2026. [Online]. Available: https://genai.owasp.org/download/56857/.

[4] M. Nasr et al., “The Attacker Moves Second,” arXiv:2510.09023, 2025. Accessed: Oct. 14, 2026. [Online]. Available: https://arxiv.org/html/2510.09023v1.

[5] D. Taler, Varonis Threat Labs, “SearchLeak,” Varonis, 2026. Accessed: Oct. 14, 2026. [Online]. Available: https://www.varonis.com/blog/searchleak.

[6] Gartner, “Gartner Identifies Top Five Actions for CISOs to Take by End of 2026,” press release, Sept. 30, 2026. Accessed: Oct. 14, 2026. [Online]. Available: https://www.gartner.com/en/newsroom/press-releases/2026-09-30-gartner-identifies-top-five-actions-for-cisos-to-take-by-end-of-2026.

[7] Model Context Protocol, “Tools,” Model Context Protocol Specification, revision 2026-07-28, 2026. Accessed: Oct. 14, 2026. [Online]. Available: https://modelcontextprotocol.io/specification/2026-07-28/server/tools.

[8] EDPB Support Pool of Experts, “AI Privacy Risks and Mitigations in LLMs,” European Data Protection Board, Apr. 2025. Accessed: Oct. 14, 2026. [Online]. Available: https://www.edpb.europa.eu/system/files/2025-04/ai-privacy-risks-and-mitigations-in-llms.pdf.

[9] Nielsen Norman Group, “Response Times: The 3 Important Limits,” Nielsen Norman Group. Accessed: Oct. 14, 2026. [Online]. Available: https://www.nngroup.com/articles/response-times-3-important-limits/.