Guardrails

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, 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 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 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.

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 includes recognized tool arguments and results. It excludes tool schemas, envelope metadata and semantic media content. The failure matrix 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 before enabling an external tier or relying on streaming coverage.