Skip to main content

Overview

Guardrails are a pipeline of rules that run before a request reaches any LLM provider. They can inspect, modify, or reject requests — giving you centralized control over every prompt that flows through GoModel. Guardrails work across all text-based endpoints:
  • /v1/chat/completions
  • /v1/responses
  • /v1/messages
Guardrails for images, TTS, STT, and video models are planned as a separate system and are not covered here.

Quick Start

Add a guardrails section to your config/config.yaml:
That’s it. Every request now gets the safety prompt prepended to its system instructions.

How It Works

  1. Messages are extracted from the incoming request into a normalized format
  2. The guardrails pipeline processes the messages (inject, modify, or reject)
  3. Modified messages are applied back to the original request
  4. The request continues to the LLM provider
Guardrails never see the raw API request types — they operate on a normalized message list. This means the same guardrail works identically for /chat/completions, /responses, and /messages.

Execution Order

Each guardrail has an order value that controls when it runs:
  • Same order → run in parallel (concurrently)
  • Different order → run sequentially (ascending)
Each sequential group receives the output of the previous group. If any guardrail returns an error, the request is rejected and never reaches the provider.

Configuration

Full Structure

Environment Variable

You can toggle guardrails without editing the config file:

Rule Fields

Guardrail Types

system_prompt

Adds, replaces, or decorates the system prompt on every request.

Settings

Modes

Adds a system message only if none exists. Existing system prompts are left untouched.
Behavior:
  • Request has no system prompt → adds one
  • Request already has a system prompt → no change

llm_based_altering

Rewrites selected message roles by calling an auxiliary model before the main provider request runs. This is useful for PII anonymization and other prompt-preserving rewrites. The default prompt is derived from LiteLLM’s data_anonymization guardrail, so a minimal config acts as an anonymizing preprocessor.

Settings

When llm_based_altering calls the auxiliary model, GoModel runs that call through the normal translated request path in-process. That means ordinary workflow selection, failover, usage, audit, and cache behavior still apply. The internal request uses:
  • path: /v1/chat/completions
  • user path: {guardrail.user_path or caller user path}/guardrails/{guardrail name}
  • request origin: guardrail
Guardrails are explicitly skipped for that internal request to avoid recursion.

Example

Examples

Single Safety Guardrail

The simplest setup — add a safety prefix to every request:

Multiple Guardrails in Parallel

Two guardrails running at the same order execute concurrently:

Sequential Pipeline

Guardrails with different orders run one after another. Later groups see the output of earlier ones:

Mixed Parallel and Sequential

How It Works With Different Endpoints

Guardrails operate on a normalized message format internally. The adaptation between API-specific request types and this format happens automatically:
You don’t need to think about which endpoint your users call. A single guardrail rule works identically for all supported text endpoints.

Errors and Rejection

If a guardrail returns an error, the request is rejected immediately. The error is returned to the client and the request never reaches the LLM provider. This is useful for future guardrail types that validate content (e.g., PII detection, content filtering). The system prompt guardrail does not reject requests — it only modifies them.