Guardrails

A guardrail is a rule your organization’s admins configure in the console. It runs inside Prism on every chat, messages, embeddings, and image request, either before the prompt reaches the provider or after the response comes back, and it can block the request, rewrite the text, or record what it saw. This page is for developers calling the API: what a rule can do to your request and how to tell.

What a rule can do

Action	Before the provider	After the response
`deny`	The request is refused with `400 guardrail_denied`. No credit is held.	The response is replaced with `400 guardrail_denied`. The tokens the provider produced are still billed.
`mask`	Matching text is rewritten (for example an email becomes `[EMAIL]`) and the rewritten prompt is what the provider sees.	The response text is rewritten before it reaches you.
`log`	Nothing changes; the match is recorded in Prism’s logs and metrics.	Same.

Built-in checks: regular expression match and replace, personal data masking (emails, Thai phone numbers, card numbers, Thai national ids, IBANs), JSON schema validation of a response, word and character counts, a model allowlist, and a webhook to your own service.

Streaming responses

Rules that run after the response run on a streamed body only in log mode. The bytes have already been sent by the time the stream ends, so a deny or mask rule cannot apply to a stream. When a deny rule on the response applies to your route and model, a request with stream: true is refused up front with 400 guardrail_requires_non_streaming; send stream: false instead. Response rules only see text content, so a response that carries only tool calls is not inspected.

Reading the result

Header	Meaning
`x-prism-guardrails`	Comma-separated `check:outcome` pairs in the order the rules ran, for example `piiMask:masked,regexMatch:pass`. Outcomes are `pass`, `denied`, `masked`, `logged`, `error` (the check could not run and the request continued), and `skipped` (a mask that could not be applied).
`x-prism-trace-id`	Present on a denied request so support can look it up.

A denied request returns:

{
  "error": {
    "message": "Request blocked by guardrail \"No secrets in prompts\".",
    "type": "invalid_request_error",
    "code": "guardrail_denied",
    "details": {
      "guardrail": { "id": "…", "name": "No secrets in prompts", "plugin": "regexMatch" },
      "checks": [{ "plugin": "regexMatch", "outcome": "denied", "data": { "matched": true, "index": 0 } }]
    }
  }
}

details.checks from the built-in checks never contains your prompt or the response text, only what the check reported about them. A webhook rule’s data is whatever your organization’s own endpoint returned.

Limits

A rule that cannot finish in time, or a webhook that does not answer, counts as error and the request continues; your admins can choose to fail closed instead, in which case a deny or mask rule that could not run refuses the request. Each request has a budget for how much text its rules may inspect (by default 131,072 characters across all messages); past it the rules are skipped, or the request is refused when the deployment fails closed. A rule edit takes up to a minute to reach every request. Guardrails are available when the deployment has enabled them. อ่านภาษาไทย

Get started

Core API

Organizations

API reference

Guardrails

Guardrails

What a rule can do

Streaming responses

Reading the result

Limits

​Guardrails

​What a rule can do

​Streaming responses

​Reading the result

​Limits

Guardrails

What a rule can do

Streaming responses

Reading the result

Limits