Agent Guardrails Architecture

Guardrails are the runtime controls that keep an agent inside safe, on-policy behavior — filtering what goes in, what comes out, and what it's allowed to do. They sit around the model as independent checks, because you cannot make a stochastic model safe by prompting alone.

A guardrail is a deterministic (or separately-modeled) check placed on the data path into or out of the agent. The architecture is defense-in-depth: layer cheap fast checks before expensive ones, and never rely on the model policing itself. The three placements are input, output, and action. Source: compiled from LLM guardrail patterns

The three layers

• Input guardrails — run before the model: prompt-injection / jailbreak detection, PII detection/redaction, topic and length limits, and relevance gating. Catch hostile or out-of-scope input early.
• Output guardrails — run on the response: content/safety classifiers, schema validation, hallucination/grounding checks (does the answer cite retrieved sources?), and secret/PII leak scanning before anything reaches the user. For user-facing apps, consider OpenAI Moderation API (omni-moderation-latest) as a free text/image harm classifier on ingress and egress — scores are policy signals (filter, review queue, account throttling), not automatic blocks. Pair with The Eval Loop (Slop Is an Output Problem) rubrics for product-specific quality gates.
• Action guardrails — run on tool calls: an allowlist of permitted tools, argument policy (no rm -rf, spend caps), human-in-the-loop approval for high-impact actions, and sandboxed execution. The tool runtime is the enforcement point.

Patterns

• Layered (cheap → expensive). Regex/blocklist first, then a classifier, then an LLM judge — short-circuit early to control latency and cost.
• Guardrail-as-judge. A separate model scores the output against policy — the safety form of reflection; ground it, don't let the actor grade itself.
• Fail closed for high-impact actions. When a guard is uncertain about an irreversible action, block and escalate rather than allow — the opposite of a silent fallback.

Design implications

• Independent of the prompt. Guardrails are separate components, not system-prompt instructions the model can be talked out of.
• Defense in depth. Prompt-injection defense is not solved by any single check; combine input filtering, least-privilege tools, and sandboxing (MicroVM and Sandbox Isolation Architecture).
• Latency budget. Each guard adds latency; order them cheap-first and run independent guards in parallel.
• Observe and tune. Log guardrail triggers (false positives/negatives) to tune thresholds — guardrails you can't see, you can't calibrate (Observability Architecture).

This is the runtime complement to Kevin's Production Safety stance: never let an agent take an irreversible production action without a hard, model-independent gate.

Architecture Position

---

Timeline

• 2026-07-01 | Architecture category refresh added this page to the Safety and observability family, linked it to Architecture System Map, and kept it standalone because it owns this boundary: Runtime controls for safe agent input, output, and side effects. Source: User request, 2026-07-01

• 2026-06-12 | Added OpenAI Moderation API as a consideration for user-facing input/output guardrails (free harm classifier; policy signals, not auto-block). Source: User capture + OpenAI moderation guide, 2026-06-12

• 2026-06-02 | Page created. Captured guardrails as deterministic checks independent of the prompt, the input/output/action three-layer model, the layered + guardrail-as-judge + fail-closed patterns, and implications (defense-in-depth, latency ordering, observability), tied to production-safety. Source: compiled from LLM guardrail / safety-architecture patterns