How to Add Guardrails to an LLM Application

Adding guardrails to an LLM application means inserting enforceable policy checks at every trust boundary in your request path — not bolting on a single filter after launch. The goal is predictable behavior: block or review high-risk input, screen untrusted output, and validate agent actions before they touch your infrastructure.

This guide maps a practical pipeline architecture you can adapt to chat, RAG, and agent workloads. For terminology, start with What Are AI Guardrails?. For placement trade-offs, see Guardrails Before or After the LLM.

Define trust boundaries first

Before choosing detectors, list what crosses a boundary you care about:

1. User → your API — messages, files, session metadata
2. Your API → model provider — assembled prompt including history and RAG
3. Model → your API — completions and tool-call payloads
4. Your API → user — rendered text, stored transcripts
5. Agent → tools — database writes, HTTP calls, email sends

Each arrow is a guardrail insertion point. Skipping a boundary leaves a hole — for example, scanning only the latest user message while chat history still contains secrets from a prior turn.

Reference architecture

A production LLM application with RAG and optional tools:

┌──────────────┐
│   Client     │
└──────┬───────┘
       │ HTTPS
       ▼
┌──────────────────────────────────────────────────────────────────┐
│                     Application API                               │
│  ┌─────────────┐   ┌──────────────────┐   ┌─────────────────────┐ │
│  │ Auth +      │   │ Input guardrails │   │ Prompt assembly     │ │
│  │ rate limits │──▶│ (injection, PII) │──▶│ (system + history   │ │
│  └─────────────┘   └──────────────────┘   │  + RAG chunks)      │ │
│                                            └──────────┬──────────┘ │
│                                                       │            │
│                                                       ▼            │
│                                            ┌─────────────────────┐ │
│                                            │ LLM provider call   │ │
│                                            └──────────┬──────────┘ │
│                                                       │            │
│                       ┌──────────────────┐            │            │
│                       │ Output guardrails│◀───────────┘            │
│                       │ (safety, PII)    │                         │
│                       └────────┬─────────┘                         │
│                                │                                   │
│         ┌──────────────────────┼──────────────────────┐        │
│         ▼                      ▼                      ▼            │
│  ┌─────────────┐      ┌──────────────┐      ┌──────────────┐     │
│  │ Render /    │      │ Agent loop   │      │ Logs / audit │     │
│  │ store       │      │ (tool calls) │      │ (metadata)   │     │
│  └─────────────┘      └──────┬───────┘      └──────────────┘     │
│                              │                                     │
│                              ▼                                     │
│                       ┌──────────────┐                             │
│                       │ Action       │                             │
│                       │ guardrails   │                             │
│                       └──────┬───────┘                             │
│                              ▼                                     │
│                       ┌──────────────┐                             │
│                       │ Tool runtime │                             │
│                       └──────────────┘                             │
└──────────────────────────────────────────────────────────────────┘

The diagram is logical, not a mandate to run every check on every request. A read-only Q&A bot might skip action guardrails. An internal agent with database access needs the bottom branch even when there is no user-facing chat UI.

Step 1: Input guardrails

Run input checks on the assembled prompt — system instructions, user message, chat history, and retrieved chunks — immediately before the provider call.

Prompt injection — detect instruction overrides and extraction attempts in user text and RAG content. See Detect Prompt Injection and Indirect Prompt Injection in RAG.

PII and secrets — block or redact sensitive literals before they reach a third-party model. See Redact PII Before the LLM.

Implementation options:

• Separate API calls per detector when you are incrementally adopting controls.
• Unified orchestration when you want one integration point — Unified Guard runs prompt_injection and pii_secrets (and others) in parallel with a consolidated decision.

curl -X POST https://www.identicapi.com/api/v1/guard \
  -H "Authorization: Bearer idapi_test_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Full assembled prompt including history and retrieved chunks...",
    "checks": ["prompt_injection", "pii_secrets"],
    "redact": true
  }'

When redact is true, use redacted text from the PII check result before forwarding to the provider.

Policy mapping: map block decisions to a user-visible fallback; map review to a queue or stricter secondary model; never forward raw flagged injection payloads to the LLM "for logging."

Step 2: RAG-specific controls

Retrieval introduces untrusted document content. Add guardrails at ingest and at query time:

Document Prompt Injection explains why indexed text can carry hostile instructions.

Step 3: Output guardrails

After the model returns, screen completions before render, storage, or downstream automation. Output moderation catches harmful text the model generates even from benign prompts — see Moderate LLM Output.

For web UIs, pair moderation with sanitization and CSP — Safe AI-Generated HTML and Prevent XSS from AI Content.

Post-inference unified check example:

curl -X POST https://www.identicapi.com/api/v1/guard \
  -H "Authorization: Bearer idapi_test_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Model completion to screen before showing the user...",
    "checks": ["output_safety", "pii_secrets"]
  }'

Buffer streaming responses server-side; run output checks on the assembled message, not on partial tokens delivered to the client.

Step 4: Agent action guardrails

When the model emits tool calls, validate each proposal before execution:

• Schema validation on arguments
• Permission checks (read vs write, tenant scope)
• Policy decisions: allow, review, or block

Secure AI Agent Tools and AI Agent Permissions cover permission design. For orchestrated checks that include agent_action, pass the structured payload to Unified Guard:

{
  "checks": ["agent_action"],
  "agent_action": {
    "tool_name": "send_email",
    "action": "send",
    "arguments": { "to": "user@example.com", "subject": "Update" },
    "context": "User asked to notify the customer about their ticket."
  }
}

Do not shell-interpolate or eval model-produced strings. Treat tool arguments like untrusted input.

Step 5: Fail behavior and observability

Define what happens when a guardrail API errors or times out:

• Fail closed — block the LLM call or tool execution; show a safe fallback. Common for high-trust products.
• Fail open — allow with alerting. Lower friction, higher risk.

Document the choice per check type. Secrets detection often fails closed; low-risk internal copilots may differ.

Log request_id, check names, and verdicts — not raw secrets or full prompts in production info logs. Correlate guardrail decisions with user sessions for incident review.

Integration patterns

Middleware in your API layer

Express, FastAPI, or Next.js Route Handlers are natural homes for guardrail calls. Keep API keys server-side. Run checks in the same process that builds the provider payload so client bypass is impossible.

Separate guardrail service

Larger teams sometimes extract a dedicated policy service. The contract stays the same: input in, verdict out, strict timeouts. LLM Security Middleware discusses where this fits relative to proxies and gateways.

Orchestrated vs discrete detectors

Start discrete if you are learning the problem space — Prompt Injection Shield, PII & Secrets Detection, AI Output Safety. Consolidate to Unified Guard when parallel checks and consistent aggregation reduce latency and code paths. See How to Combine Security Guardrails.

Rollout checklist

1. Inventory trust boundaries and data flows
2. Add input screening on the assembled prompt
3. Add output screening before render
4. Add RAG ingest and retrieval scanning if applicable
5. Add action guards before tool execution
6. Define verdict → behavior mapping in version-controlled config
7. Measure latency impact in your environment — Guardrails and Latency
8. Run adversarial tests — Prompt Injection Testing

Guardrails are incremental. Ship input and output checks first; expand to agents and unified orchestration as your surface area grows. The architecture diagram above is the target state — implement the branches your product actually needs.