config_id, a reject message returned when the guard triggers, and type-specific configuration fields.
Guardrail positions
Guardrails are placed in one of two positions:- Input: Applied to user messages before they reach the agent
- Output: Applied to agent responses before they are returned to the user
config.yaml
Guardrail types
BAN_LIST
Blocks messages containing specific words or phrases.DETECT_PII
Detects personally identifiable information in text.NSFW_TEXT
Detects not-safe-for-work content.COMPETITION_CHECK
Flags mentions of competitor companies or products.BIAS_CHECK
Detects biased language in text.CORRECT_LANGUAGE
Validates that text is in one of the expected languages.GIBBERISH_TEXT
Filters nonsensical or garbled input.TOXIC_LANGUAGE
Detects toxic or harmful language.RESTRICT_TO_TOPIC
Keeps conversations within a defined set of allowed topics.DETECT_JAILBREAK
Detects jailbreak attempts in user input.PROMPT_INJECTION
Detects prompt injection attacks.RAG_HALLUCINATION
Detects hallucinations in RAG (Retrieval-Augmented Generation) responses by comparing the response against the retrieved context.CODE_SCANNER
Scans and validates code in messages, restricting to allowed programming languages.MODEL_ARMOR (Google Cloud)
Uses Google Cloud’s Model Armor service for content safety evaluation.Model Armor requires a Google Cloud project with the Model Armor API enabled. This guardrail type does not use the Guardrails AI hub.
CUSTOM_LLM
Uses a large language model as a custom guardrail with a prompt you define.
Supported models:
Custom LLM guardrails use a separate LLM call for evaluation. This adds latency and cost to each guarded request.
Summary table
Next steps
Guardrails overview
How guardrails fit into the agent request lifecycle.
Observability
Trace guardrail decisions alongside agent runs.
Troubleshooting
Diagnose configuration and provider errors.