> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prismgateway.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Guardrails

> Rules your organization sets that run on every prompt and response, what they can do, and how to read the result

# 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:

```json theme={null}
{
  "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.

[อ่านภาษาไทย](/th/guardrails)