# Guardrails

Inspect request content before the model and response content after it — what the layer can catch, what it cannot, and how to roll a guard out safely.

Source: https://tokentriage.com/docs/guardrails/overview

---
Guardrails inspect supported request and response content in the Go gateway. They can observe, warn, redact, mask, tokenize or refuse within a detector's declared scope. Guardrails are off by default. An effective profile must select each binding before it runs.

Start with [the quickstart](/docs/guardrails/quickstart), inspect the resulting coverage receipts in monitor mode, and validate the intended failure posture before enforcement.

## Which guards act on which request

A guard you configured can be armed for one kind of request and absent from another, because what decides the binding set is not the same in both. Read this before you conclude a guard is not working.

A **saved-connection** request authenticates with a runtime key (`ttv_…`) and names its gateway in `X-Tokentriage-Gateway`. The credential's own kind decides that mode; no header, body field or client flag can enter or leave it. The guards that act are the ones compiled into the gateway's applied release: the guardrail profile that release pins, plus the platform's mandatory bindings. [Connect your app](/docs/get-started/connect-your-app) is that request shape.

A **request-supplied** request carries the caller's own provider key instead. It pins no gateway release, so the release's profile is not what guards it; the workspace configuration's published head is. Naming a gateway from this mode borrows nothing: a credential that is not a runtime key has an empty gateway allowlist, so such a request is answered `gateway_not_found` with a `404`.

A gateway you run yourself has neither of those. Its guards are the `guardrails:` block of its own configuration file, reached through `default_profile` and the profiles a key selects — the shape [the quickstart](/docs/guardrails/quickstart) arms.

| How the request authenticates | Which bindings act |
|---|---|
| runtime key (`ttv_…`) plus `X-Tokentriage-Gateway`, saved-connection mode | the gateway's applied release: the guardrail profile it pins, plus the mandatory bindings |
| the caller's own provider key, request-supplied mode | the workspace configuration's published head; no gateway release is pinned |
| a self-hosted gateway with no managed configuration | the `guardrails:` block of its configuration file |

One binding available only in a managed profile is the response-schema check, because it carries configuration the file format has no field for: [check a response against a JSON schema](/docs/guardrails/response-schema).

## What runs where

| Runtime | Guardrail protection |
|---|---|
| Go gateway | Embedded content inspection and supported transformations |
| Python and TypeScript gateway transports | Requests use the gateway's configured protection |
| Python and TypeScript local routing | Routing only; no guardrail enforcement |
| Rust/Wasm decision engine | Routing only; refuses content-protection requirements |
| Reference model sidecar | Unqualified; production activation rejected |

Local routers accept an explicit requirement flag: Python `require_guardrails=True` and TypeScript `requireGuardrails: true` refuse construction before engine or configuration access. Signed local-routing documents carrying guardrail or required-content-protection settings are refused rather than silently dropping those requirements.

## Read coverage independently of findings

A detector with no findings may have completed, been skipped, timed out, received unsupported content, or been denied an external call. Versioned receipts distinguish those states. They also separate selected actions from applied transformations and released bytes. Historical rows without receipts remain unknown.

The [inspection scope](/docs/guardrails/what-gets-inspected) includes recognized tool arguments and results. It excludes tool schemas, envelope metadata and semantic media content. The [failure matrix](/docs/guardrails/phases-and-streaming) determines whether unavailable protection permits traffic or withholds unreleased bytes.

`tokentriage guardrails list`, `guardrails explain` and the live dashboard capability response describe the running build. Review [activation restrictions and known limits](/docs/guardrails/air-gap-and-limits) before enabling an external tier or relying on streaming coverage.