A free playbook, as a PDF and an EPUB
The LLM guardrails playbook
Least privilege, input and output checks, tool-call validation and red-team tests for a support agent that can refund and email.
The playbook is open in a new tab
If it did not open, open the PDF. For a reading app, download the EPUB. Both links work for a day; the form gives you new ones any time.
Build it live, with an engineer reviewing your choices
Secure AI Agents with Guardrails. Agents that each sign in with their own identity, act only within the user's permissions and refuse an injected instruction.
Look insidePages from the PDF, as they print.
Page 2: Contents 
Page 3: Every guardrail sits between Acme's agent and something it reads or touches. 
Page 23: By default an input guardrail races the agent, so a refund can run first. 
Page 34: In agent/guards/tools.py every tool call spends from a budget for its ticket. 
Page 54: Track the false positive rate next to the block rate, or the gate rewards blocking everything. 
Page 65: Decide for each check whether it fails closed or open, before it fails.
What the playbook covers
- 1
The guardrails between a ticket and a refund
Acme Inc's support agent, the four things it touches, and where each guardrail sits. Read the map once, then build it one chapter at a time.
- 2
Map the failures and baseline the agent
Step 1 on the map. Acme lists where attacks enter, writes tickets for each, and runs them against the demo agent for the number every later chapter must beat.
- 3
Cut what the agent is allowed to do
Step 2 on the map. The order-note attack from the baseline works because the demo agent can refund any amount and email any address with one shared key. Acme narrows each tool so the same attack has nothing to grab.
- 4
Screen tickets and tool results before the agent acts
Step 3 on the map. Acme screens what goes into the model: every ticket before the agent starts and every tool result before the model reads it. The screen reduces attacks; it never replaces chapter 3.
- 5
Check every tool call before it runs
Step 4 on the map. A screened ticket can still lead the model to a wrong refund, by mistake or by an injection the screen missed. Acme checks each refund and email call against the order, the customer and its own limits before the tool runs.
- 6
Check the reply before the customer sees it
Step 5 on the map. Acme checks each reply against what the tools returned, rewrites once with no tools, then falls back to a template.
- 7
Turn the red-team set into a CI gate
Step 6 on the map. Acme runs the red-team set against staging on every pull request and fails the merge when the rates move.
- 8
Give the guardrails an owner in production
Step 7 on the map. Attacks keep coming after launch and each guard will fail in some way. Acme decides how each check fails, logs every verdict, writes a runbook and names an owner who reviews it every week.
- 9
The page to keep
Every step on the map in one line each, with the file it lives in.