Guardrails.
Pluggable policies that inspect, transform, and enforce rules on every request before it reaches the provider.
Overview
Guardrails are the gateway's enforcement layer. Each guardrail defines a single policy — system prompt injection, PII redaction, output validation, or custom transformations. Guardrails are defined once and attached to any number of workflows, giving you reusable, composable safety policies that stay consistent across teams and models.
System Prompt Guardrail
Injects, overrides, or decorates the system prompt on every matching request. Three modes are available:
Inject
Prepends or appends content to the existing system prompt without removing anything.
Override
Completely replaces the system prompt with the configured text.
Decorator
Wraps the system prompt with a prefix and suffix, useful for adding instructions without removing user content.
LLM-Based Altering (PII Anonymization)
Uses a configurable LLM to detect and anonymize personally identifiable information in real time. You specify the detection model, system role, and the types of PII to mask (emails, phone numbers, SSNs, credit cards, etc.). The guardrail sends the message content to the configured LLM with a PII-detection prompt and replaces detected entities with anonymized placeholders before forwarding to the target provider.
guardrail:
type: llm_altering
config:
model: "<auxiliary model id>"
role: "You are a PII detection assistant..."
entities:
- email
- phone
- ssn
- credit_cardPipeline Execution
Guardrails attached to a workflow form a pipeline. Within the pipeline:
- Same-order runs in parallel — guardrails at the same pipeline order execute concurrently, reducing total latency.
- Sequential groups — guardrails in different order positions execute sequentially. Each receives the output of the previous group as its input, allowing multi-stage transformations.
Error Handling
If any guardrail in the pipeline encounters an error (timeout, LLM failure, validation rejection), the entire request is rejected immediately with a clear error message. Errors are not silently swallowed — the gateway treats guardrail failures as security-critical and refuses to forward unverified requests. This fail-closed behaviour ensures that a misconfigured or unavailable guardrail never results in ungoverned traffic reaching the provider.
Attaching to Workflows
Guardrails are attached to workflows by referencing their unique ID in the workflow's guardrail pipeline configuration. A single guardrail can be reused across many workflows. When a workflow is updated, the guardrail attachments are re-evaluated immediately — no restart required.