Guardrail Rules
The rule types the GenAI Engine runs on prompts and responses
Each guardrail rule checks prompts, responses, or both for one kind of risk. You create rules as defaults that apply to every task, or as task rules that apply to a single application. See the Rule Configuration Guide for request bodies and result formats.
| Rule | What it catches | Runs on | type | How it detects |
|---|---|---|---|---|
| Hallucination | Claims in a response that the provided context does not support | Response (requires context) | ModelHallucinationRuleV2 | LLM evaluator |
| Prompt Injection | Jailbreaks and attempts to override or leak the system prompt | Prompt | PromptInjectionRule | Local classifier |
| Toxicity | Hate speech, profanity, and harmful requests | Prompt, response | ToxicityRule | Local classifiers and profanity matching |
| Sensitive Data Leakage | Confidential information you define by example | Prompt, response | ModelSensitiveDataRule | LLM evaluator with few-shot examples |
| PII Leakage | SSNs, card numbers, email addresses, and other PII | Prompt, response | PIIDataRule | Local recognizers |
| Custom Rules | Keywords and regex patterns you define | Prompt, response | KeywordRule, RegexRule | Deterministic matching |
Choosing rules
The hallucination and sensitive data rules call the LLM configured for your engine, so they add latency and model cost to each validation call. Set up a provider first; see Configure Model Provider. The other rules run on models and logic bundled with the engine and need no external calls.
Most teams start with PII, prompt injection, and toxicity as default rules, then add hallucination and sensitive data rules per task where retrieval or confidential data is involved.
Updated about 2 hours ago