Skip to main content

Documentation Index

Fetch the complete documentation index at: https://to11.ai/docs/llms.txt

Use this file to discover all available pages before exploring further.

Security Pipeline

The gateway runs an inline security pipeline on every request before it reaches the upstream LLM provider. Detectors execute synchronously in the request path with fail-fast ordering — the first detector to return Block short-circuits the pipeline and returns 400 Bad Request.

Pipeline stages

The security pipeline runs three detector stages in order of increasing cost:
StageDetectorLatencyDescription
1Blocklist~nanosecondsCase-insensitive substring matching against a configurable word list
2PII Detection~500nsRegex patterns for SSN, credit card numbers, phone numbers, IP addresses, email addresses
3ONNX ML Detectors~millisecondsPrompt injection detection and content moderation (Phase 2)
This ordering is deliberate: cheap string matching runs first, so requests containing obvious blocklist violations never reach the more expensive regex or ML stages.

How it works

Incoming Request
    |
    v
[1. Blocklist]---BLOCKED---> 400 Bad Request
    |
    | PASS
    v
[2. PII Regex]---BLOCKED---> 400 Bad Request
    |
    | PASS
    v
[3. ONNX ML]----BLOCKED---> 400 Bad Request
    |
    | PASS
    v
Forward to LLM Provider
Each detector returns a DetectorResult with an action (Pass, Flag, Redact, or Block), confidence score, and optional detail message. When a detector blocks a request, the response includes which detector triggered and why. The request is never forwarded upstream.

Configuration

Enable the security pipeline in gateway.toml:
[security]
enabled   = true
blocklist = ["ignore previous instructions", "dan mode", "jailbreak"]
FieldTypeDefaultDescription
enabledboolfalseEnable the inline security pipeline
blocklistarray[]Strings for case-insensitive substring matching
When enabled = true, PII detection is always active. The blocklist is only checked if the blocklist array is non-empty.

Endpoint coverage

Not all endpoints have guardrails — binary inputs (audio files) and metadata-only endpoints (models, files) are not scanned.
EndpointInput guardrailsOutput guardrailsNotes
Chat completions / messages / responsesYesYesFull pipeline
EmbeddingsYesNoInput text scanned; output is float vectors
Image generationYesNoPrompt text scanned
Audio transcriptionNoNoBinary audio input
Audio speech (TTS)YesNoInput text scanned
FilesNoNoBinary/metadata only
Count tokensNoNoNo generation, no content risk
ModelsNoNoSynthetic metadata from config

Output guardrails and streaming

Output guardrail behaviour differs between streaming and non-streaming requests:
ModeBehaviour
Non-streamingFull response inspected before delivery. Violations return 400 Bad Request.
StreamingChunks are sent as they arrive. Response text is accumulated in a bounded buffer (64 KB cap). After the stream completes, accumulated text is checked — violations are logged for monitoring/alerting rather than blocking, since chunks have already been delivered.

Blocklist detector

The blocklist detector performs case-insensitive substring matching against every message in the request. If any message contains a blocklist entry, the request is blocked immediately.
[security]
enabled   = true
blocklist = [
  "ignore previous instructions",
  "dan mode",
  "jailbreak",
  "act as",
]

PII detector

The PII detector uses compiled regex patterns to identify sensitive data in request messages:
PatternExamples
Social Security Numbers123-45-6789
Credit card numbers4532-0151-1283-0366
Phone numbers555-867-5309
IP addresses192.168.1.100
Email addressesuser@example.com
PII detection runs automatically when the security pipeline is enabled — there is no separate configuration toggle.

ONNX ML detectors (Phase 2)

The ONNX-based detectors for prompt injection and content moderation are architecturally integrated into the pipeline but currently return Pass on all requests. When activated in a future release, they will run transformer models via the ONNX Runtime with the same fail-fast semantics. The ort (ONNX Runtime) dependency is isolated in the gateway-security crate so that changes to other gateway crates never trigger ONNX recompilation.