Input Guardrails vs Output Guardrails

Input guardrails screen what enters the LLM. Output guardrails screen what leaves it. The distinction sounds simple, but teams often implement only one side — and leave a predictable gap in the middle of the request path.

Most production LLM applications need both. Input controls reduce attacks and data leakage before inference. Output controls catch harmful or policy-violating completions even when the prompt was benign. Together they form the core of a guardrails strategy described in What Are AI Guardrails?.

For the moderation-specific angle — same split, narrower scope — see Input vs Output Moderation. This article focuses on the broader guardrails layer: injection, PII, output safety, and how they complement each other.

Definitions

Guardrails are not limited to "moderation." Input guardrails include prompt injection detection and PII/secrets scanning. Output guardrails include AI output safety and post-generation PII checks before logging.

What input guardrails solve

Input guardrails answer: Should this text reach the model or retrieval index?

Prompt injection

Attackers embed instructions in user text or retrieved documents to override system behavior. Input screening flags instruction overrides, role manipulation, and extraction attempts before they influence model reasoning.

• Direct attacks in chat — Prompt Injection Examples
• Indirect attacks via RAG — Indirect Prompt Injection in RAG

Output guardrails do not prevent injection from entering context; they only limit harm from the resulting completion.

Sensitive data in prompts

Users paste stack traces, config files, and credentials into chat UIs. Input PII/secrets detection blocks or redacts literals before third-party model providers or vector indexes see them.

See Prevent API Key Leaks in AI Prompts and Redact PII Before the LLM.

Abuse and policy at the door

Rate limits, auth, and input moderation (when used as an input-stage filter) reduce spam and disallowed requests early. This lowers cost and shrinks the attack surface before GPU time is spent.

What output guardrails solve

Output guardrails answer: Is this completion safe to show, store, or automate?

Harmful or deceptive content

Models can produce harassment, threats, phishing-style language, or instructions that violate product policy — even from innocent prompts. Moderate LLM Output covers server-side placement.

Unsafe markup and improper handling

Assistant HTML, Markdown with raw HTML, and javascript: links create XSS risk when rendered without validation. Output safety flags risky patterns; you still need sanitization and CSP — Improper Output Handling.

Data echo and leakage in responses

If sensitive context reached the model, the completion may echo PII or secrets. Post-inference PII scanning catches literals before they appear in the UI or support logs.

Downstream automation

When completions trigger workflows (send email, update tickets), treat output as untrusted input to those systems — LLM Output Is Untrusted Input.

Side-by-side comparison

Neither replaces the other. Input vs output moderation makes the same point for moderation-only stacks: input does not ensure safe HTML in replies.

Pipeline placement

User message ──▶ INPUT GUARDRAILS ──▶ LLM ──▶ OUTPUT GUARDRAILS ──▶ User
                      │                              │
                      │                              └── sanitize / CSP
                      └── injection, PII, abuse

For RAG, extend the input branch:

Documents ──▶ ingest scan ──▶ index
Query ──▶ retrieve ──▶ chunk scan ──▶ prompt assembly ──▶ INPUT GUARDRAILS ──▶ LLM

Guardrails Before or After the LLM discusses additional placement points (e.g., before tool execution).

Implementation with IdenticAPI

You can run input and output checks as separate API calls or orchestrate them through Unified Guard at each stage.

Pre-inference (input):

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": "Assembled prompt with user message and retrieved chunks...",
    "checks": ["prompt_injection", "pii_secrets"],
    "redact": true
  }'

Post-inference (output):

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 deliver to the user...",
    "checks": ["output_safety", "pii_secrets"]
  }'

Same API, different pipeline hooks. Map decision to allow, review, or block at each stage independently — a blocked input never calls the LLM; a blocked output never reaches the client.

Common mistakes

Scanning only the latest user message

Chat history and RAG chunks are part of the input surface. Assemble the full prompt, then scan once per turn.

Output-only stack for a public bot

You save pre-inference latency but accept injection and secret paste into provider logs. Public products typically need input guardrails.

Input-only stack with rich rendering

Injection screening does not validate assistant HTML. Add output safety and rendering controls.

Identical policy for both stages

Input may redact and continue on PII where output should block and replace with a fallback. Tune per stage.

When one side might suffice (temporarily)

Even "internal only" systems often need PII scanning on input for compliance.

Relation to content moderation

Content moderation is the subset focused on classifying harmful text — usually at output, sometimes at input for abuse. Guardrails include moderation plus injection, secrets, tool policies, and orchestration. See AI Guardrails vs Content Moderation.

Next steps

• Wire both stages in Add Guardrails to an LLM Application
• Orchestrate checks with Unified Guard
• Measure combined latency — AI Guardrails Latency

Input and output guardrails are complementary halves of the model boundary. Build both into your architecture early; retrofitting the missing half after an incident is more expensive than running two API calls per turn.