Skip to main content
Request guardrails check every text a model would see in a request — messages, system prompt, tool arguments and tool results — against your organization’s policy before the request leaves the gateway. Each category can count matches, rewrite them out of the request, or refuse the request outright. The check runs in memory on the request path, adds about a millisecond, and stores nothing: not the request, not the matches.
Guardrails are off by default. Nothing changes for an organization that has not configured a policy — no checks, no added latency. An organization admin turns them on from the portal’s Privacy & Data Controls page, and a policy change applies to new requests within about a minute.

​
Categories

Every pattern is anchored and tested against a false-positive corpus (git SHAs, UUIDs, base64 blobs, long hex strings, “sk-” in prose, order numbers that look like phone numbers, 16-digit numbers that fail Luhn, timestamps), so ordinary code and data pass untouched.

​
Modes

Each category has its own mode: When several categories match one request, block wins: the request is refused even if the other matching categories are set to redact or audit. A served request has every redact category rewritten and every audit category counted. Streaming is unaffected: a request is checked once, before the stream opens, and a served stream is never interrupted.

​
How a block looks

category is one of secrets, pii or injection. The response never carries the matched text — your integration can branch on error.type or error.code and tell the user which kind of content to remove.

​
What is recorded

Counts only, ever:
  • Usage record. A served request that matched gets a flag on its usage row: metadata.guardrails = { "<category>": { "mode": "audit" | "redact", "count": n } }. Blocked requests write no usage row (nothing was served or billed); the refusal is recorded in the gateway’s error log with the same per-category counts.
  • Activity feed. Each hit raises a client.guardrail.hit event in the portal’s Activity feed with the category, mode, count and request id, throttled to one event per category per organization per minute.
  • Analytics. The organization’s Analytics page shows hits per category per day, and the number of blocked requests.
The matched text, the request body and the redacted values are never written anywhere — the evaluation is in memory and its result is a count.

​
Allowlist

The prompt-injection category accepts a list of phrases that must never count as an attack — wording your own product legitimately sends, such as “ignore the previous ticket and start over”. Matching is case-insensitive and ignores extra spaces; any detector match that overlaps an allowlisted phrase is dropped. Up to 50 phrases of up to 200 characters each.

​
Coverage

Binary and base64 parts (images, audio, files), tool definitions and metadata fields are not scanned. The Bedrock Converse surface, embeddings, media generation and realtime voice are not covered yet.

​
Latency and availability

  • Budget. All patterns are precompiled and each text is scanned once; the evaluator has no network calls. A 10,000-token (~40 KB) request evaluates in about 1 ms, under a 2 ms p95 budget enforced by the test suite.
  • Policy reads. The gateway reads your policy from the same 30-second per-organization settings cache it already uses for fallback chains — no extra database read per request.
  • If the policy cannot be read. The last known policy keeps applying for up to five minutes. Past that, an organization whose last known policy enforced anything (redact or block in any category) gets 503 with Retry-After: 30 and details.reason = "guardrail_policy_unavailable" rather than being served unchecked. Organizations that never configured guardrails, or only audit, are never refused on this path.

​
Set it up

  1. In the portal, open your organization’s Privacy & Data Controls page and expand Request guardrails.
  2. Pick a mode per category. Start with audit to see what would match; move to redact or block once the counts look right.
  3. Use Test a sample to paste a prompt or tool result and see which categories match and what the current modes would do — the sample is evaluated server-side and discarded; only categories and counts come back.
  4. Save. New requests follow the policy within about a minute.