Skip to content

Engineering Guardrails for AI Systems, post series

AI guardrails work when model influence, deterministic enforcement, evidence, and recovery are designed as one system. This series follows an unsafe proposal from untrusted input to an external effect, then places controls at the boundaries that can still stop it.

What you will be able to do

  • Threat-model a chatbot, MCP server, or agent as a data flow with actors, assets, trust boundaries, capabilities, and destinations.
  • Separate model guidance and attack detection from policy, authorization, approval, and execution controls.
  • Preserve provenance and keep untrusted content from granting capabilities.
  • Test guardrails with effect assertions, adaptive attacks, benign hard negatives, and utility measurements.
  • Trace a guardrail bypass across prompt, model, policy, tool, and executor versions.
  • Turn incident findings into regression tests, safer defaults, and auditable release evidence.

The running workflow

The examples use a fictional customer-support assistant. It can read tickets, retrieve tenant-scoped account facts, draft replies, send to a verified customer address, and propose limited service credits. Later parts add MCP tools and longer-running agent behavior.

The domain stays deliberately small so the security boundary remains visible. Tickets and retrieved documents are untrusted data. Identity, tenant ownership, capabilities, verified destinations, approvals, and policy versions come from the host application.

Published reading order

  1. AI Guardrails Are Systems, Not Prompts, define influence, detection, enforcement, evidence, and recovery around external effects.
  2. Threat-Model an AI Application, map actors, assets, trust boundaries, capabilities, destinations, and failure paths.
  3. Design a Layered AI Guardrail Architecture, compose identity, context, policy, authorization, approval, execution, and output controls.
  4. Prompt Injection and Control-Data Separation, preserve provenance and prevent untrusted content from selecting capabilities or destinations.
  5. Guardrails for Production Chatbots, combine deterministic validation, structured screening, output policy, safe fallback behavior, and utility measures.
  6. Tool Calls, Approvals, and Least Privilege, treat model calls as proposals and bind canonical actions to authorization, approval, revalidation, and idempotency.
  7. Guardrails for MCP Clients and Servers, pin remote definitions, validate hostile results, bind tokens to resources, and constrain tool combinations against MCP 2026-07-28.
  8. Agents, Delegation, and Guardrail Propagation, propagate provenance, reduced capabilities, budgets, cancellation, and trace lineage through handoffs.
  9. Claude API and Agent SDK Guardrails, place enforcement around Claude Messages tool loops, Agent SDK hooks, and Managed Agents confirmations.
  10. OpenAI Agents and Codex SDK Guardrails, block unsafe workflow input before agent execution, wrap custom tools, preserve trace evidence, and constrain Codex execution.
  11. Deterministic Guardrail Testing, prove policy, workflow, failure, audit, authority, and effect invariants with fake models and recording executors.
  12. Adversarial Evals and Security-Utility Measurement, compare baseline, control, and adaptive attacks while measuring prohibited effects and retained utility.
  13. Trace Guardrail Bypasses and Boundary Hops, reconstruct causal paths from external receipts and identify the first preventable control failure.
  14. AI Guardrail Incident Response and Continuous Improvement, contain capabilities, convert failures into regressions, and restore service through security and utility gates.

The complete path moves from threat modeling through enforcement, provider-specific implementation, deterministic proof, adversarial measurement, causal reconstruction, and incident recovery.

Version baseline

The architectural examples are provider-neutral. Vendor-specific and MCP posts record the documentation, protocol, SDK, and model baselines used at publication. Treat those details as dated evidence, recheck them before copying configuration, and rerun the examples when a dependency or hosted behavior changes.