When a team ships its first application backed by a large language model, security tends to live in the prompt. Someone writes "do not reveal personal data" into the system message and hopes the model complies. That approach breaks down quickly. Models are probabilistic, prompts can be overridden by cleverly crafted user input, and the same model is often reached by a dozen different applications with a dozen different copies of the rules. What one team calls a safeguard, another forgets entirely. The result is inconsistent protection that nobody can audit.

Guardrails are the disciplined alternative. A guardrail is a programmatic check that sits outside the model, inspects the data flowing to and from it, and either blocks that data or rewrites it when a rule is violated. Instead of trusting the model to police itself, you place deterministic controls around it. This article explains what guardrails are, where they run in the request lifecycle, the difference between inspecting and rewriting, how to roll them out without breaking production, and why the API gateway is the natural place to enforce all of it.

What a guardrail actually does

A guardrail inspects data and then acts on it. The inspection might look for personally identifiable information, a prompt-injection attempt, an API key that leaked into a response, or risky SQL. The action is one of two things: it refuses the request, or it modifies the data so the request can proceed safely. Because guardrails are ordinary code or hosted services rather than instructions to the model, their behavior is repeatable. The same input produces the same decision every time, which is exactly the property you want when you later need to prove to an auditor that a control was in force.

Guardrails apply in two different settings. The first is a plain request to a language model. The second is a tool call made through the Model Context Protocol, where an agent invokes an external function such as a database query or a file read. The lifecycle differs slightly between the two, and understanding that difference is the foundation for everything else.

Input versus output for model requests

For a request to a language model, guardrails run at two points. Input guardrails run before the model ever sees the prompt. This is where you catch a user trying to smuggle in an injection attack, or where you redact a customer's national ID number before it is sent to a third-party model provider. Output guardrails run after the model responds, before the answer reaches the user or the calling application. This is where you catch the model echoing back a secret, generating moderated content, or including PII it inferred from context.

Both directions matter because the threats are different. Input controls protect the model and the downstream provider from malicious or sensitive data. Output controls protect your users and your organization from what the model produces. A complete posture uses both. The ability to sit directly in the request path and run these checks is one of the defining properties of AI gateway guardrails, because the gateway is the one component every request already passes through.

Pre-tool versus post-tool for MCP tools

When an agent calls a tool rather than a model, the two checkpoints are named differently but serve the same purpose. Pre-tool guardrails run before the tool executes. They can stop an agent from calling a destructive function or from passing sensitive arguments into an external system. Post-tool guardrails run before the tool's result is returned to the agent, so you can scrub a database row of PII before the model ever reads it. Guardrails run separately for each tool call, which means a single agent turn that fans out to five tools gets five independent evaluations rather than one coarse check.

Validate versus mutate

Every guardrail operates in one of two modes, and the distinction is worth internalizing.

  • Validate inspects the data and blocks the request if a rule is violated. It never changes the content. A prompt-injection detector is a natural validator: either the request is clean and proceeds untouched, or it is flagged and stopped.
  • Mutate inspects the data and rewrites it, for example by redacting a detected credit-card number so the rest of the request can continue. A mutating guardrail can also block when rewriting is not enough.

The practical consequence is that mutation lets you keep a request alive while removing the dangerous part, whereas validation is all-or-nothing. PII redaction is the classic mutating use case; secrets detection and content moderation are often validators.

Enforcement strategy and staged rollout

Deciding what a guardrail checks is only half the design. The other half is deciding what happens when it fires, and what happens when the guardrail itself fails. A hosted moderation service can time out. A detector can throw an error. If you have not decided in advance how to handle that, you will either block legitimate traffic during an outage or silently let everything through. There are three enforcement strategies:

  • Enforce blocks the request both when a violation is detected and when the guardrail errors. This is the strictest posture and treats an unavailable guardrail as a failure to prove the request is safe.
  • Enforce but ignore on error blocks on a genuine violation but allows the request through if the guardrail itself errors. This trades a small amount of safety for availability during guardrail outages.
  • Audit logs what the guardrail would have done but never blocks anything. Traffic flows normally while you gather evidence about how the rule behaves against real data.

These three map onto a sensible rollout sequence. Start in Audit so you can measure false positives against live traffic without risk. Once the rule looks accurate, move to Enforce but ignore on error so real violations are blocked while a flaky guardrail cannot take down your application. Finally, when you trust both the rule and its reliability, promote it to Enforce. Audit, then enforce-but-ignore-on-error, then enforce: that progression turns a guardrail from a liability into a dependable control.

The execution order and the streaming caveat

For a model request, the checkpoints run in a specific order. Input mutation runs first and blocks the pipeline until it finishes, because later stages need the rewritten prompt. Input validation then runs in the background while the model request is already in flight; if validation fails, the in-flight request is cancelled. After the model responds, output mutation runs, followed by output validation. Running input validation concurrently with the model call is a deliberate optimization: it hides the latency of the check behind work the system was going to do anyway.

There is one caveat that trips up teams repeatedly. Output guardrails are skipped for streamed responses. When a response streams token by token, there is no complete output to inspect before the user starts seeing it, so the output stage cannot run. If you need output guardrails to apply, you must turn streaming off by setting the request's stream flag to false. Input guardrails always run regardless of streaming, so the input side of your posture is never affected. The trade-off is concrete: streaming gives a snappier user experience, but you forfeit output inspection unless you disable it.

The Built-in catalogue

A mature gateway ships a library of guardrails so teams do not reinvent detectors. Several categories are worth knowing:

  • Content moderation flags hate, self-harm, sexual, and violent content, with adjustable thresholds so you can tune sensitivity to your audience.
  • PII/PHI detection finds personal and protected health information and can optionally redact it, making it a natural mutating guardrail.
  • Prompt injection detects jailbreak and injection attempts in user input before they reach the model.
  • Secrets detection catches API keys, JWTs, and private keys so they are not leaked into prompts or responses.
  • Code safety linter flags dangerous constructs such as eval, exec, or shell invocations in generated or submitted code.
  • SQL sanitizer flags risky SQL, such as DROP or TRUNCATE statements, or UPDATE and DELETE statements that lack a WHERE clause.
  • Regex pattern matching lets you enforce organization-specific patterns that no generic detector would know about.
  • Cedar and OPA guardrails provide default-deny access control for MCP tools and policy-based authorization decisions.

Three of these, content moderation, PII/PHI detection, and prompt injection, rely on hosted models and are available in the SaaS deployment. In a self-hosted environment you substitute external guardrail providers for those three, while the remaining detectors run locally. Beyond the built-ins, a gateway typically integrates many external guardrail vendors and lets you supply custom logic as a plain Python function. The point is not that any one detector is magic; it is that you assemble a layered set and apply them consistently.

Applying Guardrails: policies and per-request headers

There are two ways to put guardrails into effect. The first is org-wide policy. You register a guardrail under the gateway's guardrails section, then attach it under policies. A policy matches on attributes such as the calling identity, the target model, or a specific MCP tool, so you can say "every request from the support team to this model gets PII redaction" without touching application code. This is how you achieve uniform coverage and a single audit trail.

The second way is a per-request header, useful when one application needs a guardrail that the org-wide policy does not impose. You attach the guardrails in a header, and they run alongside any policy guardrails rather than replacing them. The header carries JSON naming the input and output guardrails by their group and name:

{
"llm_input_guardrails": ["my-group/pii-redaction"],
"llm_output_guardrails": ["my-group/secrets-detection"]
}

A full request that attaches a guardrail by header looks like this. Note the scope header, which controls how much of the conversation the guardrail evaluates:

curl -X POST "{GATEWAY_BASE_URL}/chat/completions" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-H 'X-TFY-GUARDRAILS: {"llm_input_guardrails":["my-group/pii-redaction"]}' \
-H "X-TFY-GUARDRAILS-SCOPE: 10" \
-d '{"model":"openai/gpt-4o","messages":[{"role":"system","content":"You are a helpful assistant."},{"role":"user","content":"Hello"}]}'

The scope header accepts all to evaluate the whole conversation, which is the default, last to evaluate only the most recent message, or an integer N to evaluate the last N messages. In the example above, only the last ten messages are inspected, which keeps large conversations from being re-scanned in full on every turn. System prompts are excluded from evaluation by default, so your own instructions do not trip the detectors you configured for user content.

Why the gateway is the right enforcement point

You could embed guardrail logic inside every application. Teams that try this discover the cost: each service carries its own copy of the rules, versions drift, a new application ships with none of them, and there is no single place to prove what was enforced. The gateway solves this structurally. Every request to every model and every tool already flows through it, so it is the one chokepoint where a control can be applied once and cover everything behind it. Policies live centrally, enforcement happens in the request path, and the audit trail is unified because there is a single component to record it. Guardrails defined at the gateway are independent of application code, which means a security team can tighten a policy without a release from every product team. That separation, controls owned by the people responsible for them and enforced where all traffic converges, is what makes guardrails trustworthy rather than aspirational.

Key takeaways

  • A guardrail inspects data flowing to and from a model or tool and either blocks it (validate) or rewrites it (mutate); it is deterministic code, not a prompt instruction.
  • Model requests are checked on input and output; MCP tool calls are checked pre-tool and post-tool, with a separate evaluation per tool call.
  • Choose an enforcement strategy per guardrail, and roll out in stages: Audit, then Enforce but ignore on error, then Enforce.
  • Input validation runs concurrently with the model call, but output guardrails are skipped for streamed responses; set stream to false when you need them.
  • Apply guardrails org-wide through policies that match on caller, model, or tool, or per request through a header with a scope that limits how many messages are evaluated.
  • The gateway is the right enforcement point because every request already passes through it, giving you one place to apply controls consistently and one audit trail to prove it.