AI guardrails: protect AI apps from prompt injection, PII, and unsafe content

Every prompt your app sends to a model is a small act of trust. It might carry a customer's email address into a third-party API. It might be a user trying to talk the model out of its instructions. And the answer that comes back might be something you'd never want on your product's screen. Doing these checks inside each app — a regex here, a keyword list there, a "please be nice" system prompt — doesn't scale past the second app.

AI guardrails move that screening to the gateway. Every request passes through one policy on its way to a model, a tool, or an agent — and the response passes through it on the way back — so content safety, prompt-injection detection, PII redaction, and your own blocklist apply to every app the same way, without a line of app code.

This guide covers what guardrails check, what each decision (off / flag / block / redact) actually does to a request, the policy the gateway ships with, how to scope a stricter or looser policy to one route, tool server, or agent, what your code sees when something is blocked, and the mistakes that trip people up. Content safety, deterministic PII redaction, and custom blocklists are available on the free plan; prompt-injection detection and AI-powered PII detection require Developer or higher.

1. What are AI guardrails?

AI guardrails are policies that inspect AI inputs and outputs before they cross a trust boundary. They can block unsafe requests, redact sensitive data, detect prompt injection, or flag content for review. An AI gateway is the natural place to enforce them, because every application, model, tool, and agent already passes through it.

Concretely, a guardrail is a check the gateway runs on AI traffic before it reaches a model, tool, or agent — and, for tools and agents, on what comes back. It's the part that makes a gateway more than a proxy.

Your app ──→ AI Gateway ─────────────────────────→ Model / Tool / Agent
              │  content safety   (13 categories)
              │  prompt injection (jailbreak detection)
              │  PII redaction    (patterns + AI detection)
              │  blocklist        (your phrases and regexes)
              │
              └─ each layer: off · flag · block · redact
                 decisions recorded as metadata — content is never stored

Two properties matter more than the feature list. The checks run in memory on the gateway: content is read to screen it and then discarded, and guardrail observability records only the verdict (route, phase, category, action, latency) — never the prompt or response. (Response caching is a separate, opt-in feature that keeps recent responses for its configured TTL; it isn't part of guardrails.) And one engine guards three boundaries:

• LLM — the prompt going to a model and the response coming back
• MCP — each tool call's arguments going out and its results coming in
• A2A — each message exchanged with another agent

So one policy covers everything your agents do, not just chat.

Guardrails vs. system prompts vs. moderation APIs

A system prompt asks the model to behave a certain way; the model can be talked out of it, and it does nothing about what you sent in the first place. A moderation API classifies text when your code remembers to call it, one app at a time. A guardrail enforces policy outside the model's instructions and outside each app's code — on every request, in both directions, whether or not the model cooperates. Use all three; rely on the last one.

2. The five layers

Do AI guardrails add latency?

The two deterministic layers cost effectively nothing — pattern matching on the request body. The guard-model layers add a classification call before the model call; on the account in the screenshots below it averaged 358 ms per checked request, and the Observability page reports the figure for your own traffic. That's why the model-based layers are worth turning on deliberately, on the routes that need them, rather than everywhere by reflex. Input checks run before the model is called, so a blocked request is actually faster than a normal one — the provider is never contacted.

Plan availability shown here is current as of publication and may change — see Pricing.

3. Off, flag, block, redact — what each does

Input guardrails vs. output guardrails

Every content-safety category has an action for the prompt direction (input — what the user or app sent) and one for the response direction (output — what the model produced); the other layers have one action each. Input checks protect the provider, your data, and your budget; output checks protect the people reading the answer.

The Off / Standard / Strict / Custom buttons at the top of the page are presets over the whole table. Standard is the recommended policy in the next section; Strict sets every category to block in both directions; Custom lets you tune each cell.

4. The default policy, category by category

The current policy uses a 13-category safety taxonomy (the S1–S13 codes come from Llama Guard, the guard model in use today) plus a prompt-injection class. The Standard preset is deliberately asymmetric: it is stricter on what the model says than on what a user asks, because a question about a crime is often legitimate while an answer that helps commit one rarely is.

Read the bottom rows carefully before tightening them. Specialized Advice fires on medical, legal, and financial guidance — blocking it in the prompt direction would break a health or fintech assistant outright. Defamation and Intellectual Property are response-side concerns: you care that the model doesn't produce them, not that a user mentioned them.

5. When the guard model is down: fail open or fail closed

The model-based layers depend on a guard model answering within a short time budget. If it can't — it's overloaded, or briefly unreachable — the gateway has to choose between availability and strictness. That choice is yours: "If the guard model errors: Allow (fail open)" lets the request proceed unscreened and marks it; fail closed rejects it.

The default is fail open, and for most products that's right — safety tooling shouldn't become the outage. But it's not silent: a request that went through unscreened carries the response header X-HA-Guard: degraded, and the same flag lands in usage, so you can count exactly how many requests slipped past during an incident. Flip to fail closed on routes where an unscreened request is worse than a failed one.

6. Account-wide, per route, per tool server, per agent

The policy you configure under AI → Guardrails applies everywhere by default. Override it where one destination needs something different:

The pattern that comes up most: the account policy is Standard; the customer-facing chat route is Strict; an internal summarization route that processes support tickets full of names and phone numbers keeps PII redaction on but turns content safety off because the tickets themselves describe fraud and threats. Each is a one-click override on the route, and because apps call routes by name, the app doesn't know or care.

How to configure guardrails on a route

Open AI → Routes, pick the route, and click Edit. The Guardrails selector sits in the header next to the route name (visible in all three editors — Flow, Form, and JSON):

1. Inherit account — the default. The route uses whatever is set under AI → Guardrails; change the account policy and every inheriting route follows.
2. Off (no checks) — no screening on this route at all (internal batch jobs on trusted data).
3. Standard / Strict — the same presets as the account page, pinned to this route so later account changes don't touch it.
4. Custom… — click Customize and you get the full policy editor scoped to this route: the per-category content-safety table with prompt/response actions, the fail-open setting, injection detection, PII redaction, AI-powered detection, and a blocklist of its own. Save the route and the policy travels with it.

The same two fields exist in the route JSON, so a route's policy can live in version control with its targets and rules. guardrails_mode takes inherit, off, standard, strict, or custom; with custom, the guardrails object carries the policy:

{
  "name": "support-chat",
  "strategy": "fallback",
  "targets": [
    { "type": "local", "model": "local/llama3.2:3b", "timeout_ms": 8000 },
    { "type": "cloud", "provider": "openai", "model": "openai/gpt-4o-mini" }
  ],
  "guardrails_mode": "custom",
  "guardrails": {
    "pii_redact": true,
    "blocked_patterns": ["/sk-[a-z0-9]{20,}/", "internal-only"],
    "blocked_action": "redact",
    "moderation": {
      "enabled": true,
      "fail_mode": "closed",
      "input":  { "S1": "block", "S2": "flag", "S10": "block", "S11": "block" },
      "output": { "S1": "block", "S2": "block", "S10": "block", "S11": "block", "S6": "flag" }
    },
    "injection": { "enabled": true, "action": "block" },
    "pii_model": { "enabled": true, "action": "redact" }
  }
}

Reading that policy: PII patterns are redacted, leaked API keys and an internal phrase are redacted rather than blocked, four content-safety categories are enforced in both directions (with Specialized Advice only flagged on the way out), the guard model fails closed because this is a customer-facing route, injection attempts are blocked, and the AI PII layer redacts names and addresses. Categories you leave out of input/output are simply off for this route. The two model-based layers (injection, pii_model) are honoured on Developer and above; on the free plan they're ignored and the rest of the policy still applies.

For MCP servers and A2A agents the choice is simpler — Inherit account or Customize for this server/agent — and a custom policy screens the tool call's arguments and results (or the agent's messages) with the same four layers.

7. What your code sees

A redaction is invisible to the caller except in the content itself — the request continues with the replaced text, and the model answers as normal:

# prompt sent by the app
"Email the invoice to [email protected] and call 415-555-0134 if it bounces."

# what the model receives
"Email the invoice to [REDACTED-EMAIL] and call [REDACTED-PHONE] if it bounces."

A block is an error. The gateway answers 422 Unprocessable Entity with a JSON body carrying the reason, and nothing was sent to the provider:

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json

{"error": "blocked: request contains personal data"}

Handle it like any other 4xx: show the user a message and don't retry — a blocked request will be blocked again. The same 422 shape comes back for a blocklist match, a content-safety block, or an injection block, with the reason text differing.

A flag changes nothing the caller can see; it's recorded for you, not for them.

8. Seeing what was caught — without seeing the content

AI → Observability → Guardrails is the audit view: how many requests were checked, flagged, and blocked over today / 7 days / 30 days, the top categories, the routes generating them, average guard latency, and a per-event list with time, route, phase (input or output), category, action, and latency. What it deliberately does not contain is the prompt or the response — guardrail processing happens in memory and the gateway does not persist content as part of guardrail observability.

Use it the way you'd use a staging rollout: run a new category on flag for a week, look at what it would have blocked and on which routes, then switch to block with evidence rather than a guess. The Chat Playground gives you the same signal per request — send a prompt through a route and it reports whether the guard passed, flagged, or blocked it.

9. Common guardrail mistakes

• Turning everything to Strict on day one. Strict blocks all 13 categories in both directions, including Specialized Advice and Non-Violent Crimes — categories that fire on normal questions in many products. Start at Standard, watch the flags, then tighten what actually matters.
• Confusing flag with block. A flagged request goes through. If the dashboard shows dozens of flags and you expected them to be stopped, the category is on flag.
• Expecting a route override to apply to direct model calls. Overrides live on the route; calling a provider model by name skips them.
• Blocking where you should redact. For PII and secrets, redaction keeps the product working and still keeps the data home. Reserve block for content that shouldn't produce an answer at all.
• Fail-closed everywhere. It's the right call for a narrow set of routes; account-wide it turns any guard-model hiccup into a full outage of your AI features.
• Blocklist regexes that are too broad. /key/ matches "keyboard". Anchor them (/sk-[a-z0-9]{20,}/), and use redact for anything that might appear innocently.
• Relying on output blocking for streamed responses. See above — streams are flag-only on the way out.

10. Guardrails aren't the whole story

Guardrails decide whether a request should go. Routing decides where it goes. Spend limits decide how much you're willing to spend. Caching can avoid the model call entirely. All four live on the same gateway and apply to every app that calls it. LLM routing and the complete AI Gateway guide cover the rest.

11. Getting started

1. Sign in at hostanywhere.io → AI → Guardrails. Content safety, PII redaction, and the blocklist are on with the Standard preset on the free plan; the two model-based layers need Developer.
2. Add one blocklist entry you actually care about — a regex for your own API-key format is the classic — and set it to redact.
3. Send a prompt containing an email address through the Chat Playground and watch it come back as [REDACTED-EMAIL]; then try a jailbreak prompt and watch the 422.
4. Give it a week on flag, read Observability → Guardrails, then decide what to block.

Full reference in the guardrails documentation; the walkthrough video shows the whole setup and a live test of blocked prompts.