Guardrails
Layered policy enforcement, PII protection, and output validation — running on every call, below 13ms total.
Guardrails run automatically inside the engine on every intent call. Layered policy enforcement, PII protection, bias detection, output validation, and audit logging — safety that developers don't route around because it isn't optional application code.
Built-in policies
PII Redaction & Masking
Detect and redact PII in inputs and outputs — mask, hash, or replace with typed placeholders.
Content Filtering
Block harmful, off-topic, or brand-unsafe content using layered classifiers.
Bias & Fairness Filters
Detect and flag outputs with demographic bias, with pre-built hiring/lending/clinical detectors.
Role-Based Output Policies
Define what each user role can see, ask, and receive — enforced at runtime.
Grounding Verification
Flag or block hallucinated claims that lack source attribution from retrieval.
Full Audit Logging
Every input, output, and guardrail decision is logged with a tamper-evident trail.
Three-phase enforcement
| Phase | Latency | What runs |
|---|---|---|
| Pre-filter | < 5ms | Fast synchronous checks before the model call — harmful inputs, PII in prompts |
| Async validator | ~30ms | Heavier checks in parallel with the model response — PII redaction, bias detection, grounding |
| Post-filter | < 8ms | Final review before the response returns — role-based masking, compliance metadata |
Guardrails run in parallel with your workload, not in front of it — the tiered architecture keeps fast checks synchronous and heavy compliance work asynchronous, so total policy overhead stays under 13ms.
Guardrail Policies
Every tenant has a default policy that applies automatically — this is what runs on every intent, agent, and action call unless something more specific is attached. Beyond the default, you can create named, reusable Guardrail Policies from the dashboard's Guardrails page and attach each one to a specific Domain, Intent, Agent, or Action — the most specific attachment wins (an Intent's own policy overrides its Domain's, which overrides your tenant default).
Each policy configures:
- PII detection — redact or flag emails, phone numbers, SSNs, credit cards
- Content policy — prompt-injection detection, profanity/violence filters, and your own additional blocked topics (these only add to the platform's built-in safety floor — illegal activity, weapons, explicit content — which no policy can disable)
- Schema & action validation — enforce an intent's output schema and restrict which of your Actions the model may invoke
- Hallucination check and knowledge grounding — what to do when an answer can't be grounded in retrieved context
- Action sanitization (opt-in) — redact PII from an Action's outbound parameters or inbound response
Standalone Guardrails API
Guardrails aren't only something that runs inside an Intent call — you can call your policy directly, with no Intent, Agent, or Domain involved, to screen content from your own systems.
POST https://api.liyaengine.ai/v1/guardrails/check
Authorization: Bearer liya_prod_...
Content-Type: application/json
{
"stage": "pre_llm",
"content": "Please refund [email protected] for order #4821"
}Response:
{
"success": true,
"data": {
"passed": true,
"content": "Please refund [REDACTED] for order #4821",
"issues": [
{
"code": "PII_EMAIL_REDACTED",
"severity": "info",
"message": "1 email instance(s) redacted",
"action_taken": "modified",
"details": { "count": 1 }
}
]
}
}| Field | Description |
|---|---|
stage | pre_llm checks input-side stages (PII, content policy). post_llm checks output-side stages (schema validation, action validation, hallucination check). |
content | A string, or a JSON object for a post_llm response shaped like { message, actions }. |
policy_id | Optional — checks against one of your named policies. Omit to use your tenant default. |
data.passed | false means at least one stage blocked this content. Both passed and blocked checks return 200 — this field is how you tell them apart. |
data.content / data.response | The content after any stage modified it (e.g. PII replaced with [REDACTED]) — present for pre_llm / post_llm respectively. |
data.fallback | Present when passed is false on a pre_llm check — a user-safe message you can show instead of calling an LLM at all. |
This is the same pipeline POST /v1/run uses internally, so a passed/blocked verdict here always matches what would happen inside a real intent call against the same policy.