Skip to main content

Guard LLM Prompts

The LLM Gateway runs your existing runtime guards on every prompt before it reaches the provider. There is nothing to turn on: a runtime guard that applies to prompts also applies to gateway calls. It is the same enforcement as Prompt Guard in the browser and the guard hooks in Claude Code and Cursor, applied at the model API.

Which guards apply​

A runtime guard runs on a gateway call when all of these are true:

  • The guard is enabled.
  • Apply to Prompts is on in its filters. It is on by default.
  • Its Direction includes Input. The gateway only checks what goes to the model.
  • Its group, AI agent, and user risk score filters match the caller. The AI agent is the client label, such as claude-code or codex.

To exempt gateway traffic from a guard, turn Apply to Prompts off. That also exempts the browser Prompt Guard and the IDE hooks.

What is checked​

Coding agents resend the whole conversation on every call, so the gateway checks only what is new since the previous call: the newest user turn, including tool results that the client sends back to the model. Text is checked; images and files are not. The system prompt and earlier turns were checked on the calls that first sent them.

Token counting (/v1/messages/count_tokens) is not guarded, because nothing is sent to the model.

What happens when a guard fires​

Guard actionResult
BlockThe call is refused before it reaches the provider. The user sees the guard's own message if it has one, otherwise Willow blocked this prompt (<guard names>).
WarningThe call goes ahead, and the guard raises an alert.
RedactThe gateway does not rewrite prompts, so a redact guard uses its redact fallback action instead: block (the default), warn, or allow. See The guard editor.

Blocks and warnings raise the same prompt-guard alerts as the browser extension. See Alerts. A block also counts in the Blocked column on the Usage tab.

Refusals are sent as 400 errors so that Claude Code shows them to the user instead of retrying. The response also carries x-willow-deny-reason: guard_blocked.

Model-based checks​

The built-in Prompt Injection Detection and Person Name Detection checks run in Willow's detection service. If that service is not deployed and reachable, both checks score 0 and never fire, on gateway calls and on MCP tool calls alike. Willow SaaS runs it for you. On a hybrid deployment it has to run in your cluster: see Detection service on hybrid. See also Built-in checks.

LLM checks call your Bring Your Own AI model and add its latency to every gateway call they run on. Give them a Regex Precondition, or narrow the guard with filters.

When guards cannot be evaluated​

Guards are evaluated inside your organization's default run gateway. Two cases behave differently:

  • The gateway is isolated. If your hybrid gateway is in Isolated Mode, Willow cannot reach it to evaluate anything. Every gateway call fails with 503 Willow is temporarily unavailable rather than going through unchecked. Claude Code retries 503 errors silently, so users see a session that hangs.
  • A guard cannot be evaluated. If run is unreachable or returns an error for a guard, that guard is skipped and the call goes ahead, the same way guards on MCP tool calls fail open.

Both only matter when at least one active guard applies to prompts. With none, the gateway does not need the evaluator.

Test a guard first​

Use the Guards Playground to run sample prompts through a guard before you enable it. A guard that is too eager blocks your developers' coding sessions.

On this page