Prompt Injection & Guardrails Best Practices
This page distills the Prompt Injection & Guardrails section into one standalone checklist - positive, enforceable practices for isolation, validation, filtering, detection, and red-teaming.
It is meant for design reviews, production-readiness gates, and periodic audits - not as a one-time read.
How to Use This Checklist
- Work by category (A-E); new teams usually start with A and B before heavy filter stacks.
- Require evidence for each checked item - a code path, schema, log field, or red-team case - not a vibe.
- Use as a gate before any agent with tools, RAG, or untrusted documents reaches real users.
- Revisit after new tools, model changes, multi-agent handoffs, or injection incidents.
A - Threat Model and Scope
- Inventory every untrusted channel (user, tools, RAG, email, browser, peer agents) before launch.
- Classify tools by blast radius (read, write, money, identity, network, shell) and document owners.
- State what "safe failure" means for this agent (refuse, degrade, HITL) when injection is suspected.
- Keep a canary secret in staging to detect exfiltration during tests.
- Refuse to ship write tools until categories B and C have evidence.
B - Isolation of Untrusted Content
- Own message assembly in one host module - no ad-hoc joins of tool text into system policy.
- Keep system/developer policy out of tool free text and never promote tool results into the system role.
- Label untrusted blobs with source, length, and hash metadata when raw text must be shown.
- Prefer facts-only or dual-path views for privileged planners when free text is risky.
- Cap size and strip hidden markup from web/document tool outputs at the adapter boundary.
- Treat multi-agent plans as untrusted until validated like tool arguments.
C - Validation and Least Privilege
- Allowlist tools in host code, not only in the prompt.
- Validate every tool argument with Pydantic, Zod, or equivalent before execution.
- Enforce semantic allowlists (URL hosts, email recipients, path sandboxes, amount caps).
- Fail closed on validation errors; do not best-effort execute partial args.
- Separate chat text from executable actions - actions only through the dispatcher.
- Gate irreversible tools with HITL or dual control until residual risk is accepted.
D - Filters, Detection, and Response
- Stack cheap rules before expensive LLM judges on the hot path.
- Scan tool results and user text for suspected injection signals, not user chat alone.
- Emit structured alerts with
trace_id, severity, rule ids, redacted snippets, andcontent_hash. - Redact secrets from logs before they leave the security boundary.
- Correlate alerts with tool decisions (write tool after poison blob = page-worthy).
- Define graded responses (log vs soft refuse vs block writes) to limit alert fatigue.
E - Red-Team, Eval, and Governance
- Maintain a living red-team suite covering direct and indirect injection per write tool.
- Automate pass/fail on tool invocations, not only on polite refusal text.
- Block release on Critical/High red-team failures unless a signed risk accept exists.
- Add a regression case for every injection incident before closing the incident.
- Re-run the suite on model, prompt, tool, and memory changes.
- Assign a named owner for guardrail defaults and the red-team harness.
Applying the Habits in Order
- Inventory channels and tools (A).
- Isolate untrusted content and remove free text from privileged context (B).
- Lock tools with allowlists and schemas (C).
- Turn on detection logging and graded blocks (D).
- Automate red-team in CI and review alerts weekly (E).
Quick Anti-Patterns
| Anti-pattern | Why it fails |
|---|---|
| "We put do-not-comply text in the system prompt" | Models still follow tool poison |
| Executing raw model JSON without schemas | Injection becomes side effects |
| Scanning only user messages | Indirect injection wins |
| Logging full tool dumps to shared Slack | Re-injection and secret sprawl |
| Red-team once at launch | Regressions on the next model swap |
| Maximum tool belt for demos left in prod | Blast radius stays huge |
FAQs
Is ten practices enough for production agents?
The title frames ten core practices; the lettered groups expand them into enforceable checkboxes covering the full section.
Do we need every checkbox before a prototype?
No.
You need them before real users, real credentials, or write side effects.
Which category should we implement first?
Isolation (B) and validation/least privilege (C), then detection (D), then formal red-team (E).
How do we prove a checkbox honestly?
Point to code, config, CI jobs, or dashboards - for example the tool registry module, schema tests, or alert metric.
Can a guardrail library satisfy this list alone?
No.
Libraries help filters and some validators; isolation, tool design, and ops remain yours.
What if a stakeholder wants unlimited tools for a demo?
Demo on a locked profile with mock tools.
Do not disable allowlists on the shared production worker.
How often should the checklist be re-run?
Before first production traffic, after material tool or model changes, after incidents, and on a fixed quarterly cadence.
Does a stronger model remove the need for these practices?
No.
Stronger models can follow sophisticated injections more ably. Mechanical controls still matter.
How does this relate to general agent security?
This section focuses on instruction hijack and linguistic/tool boundaries.
Pair with sandboxes, egress controls, and credential scoping in the agent security section.
What do we do with unchecked items?
Track them as explicit debt with owners and dates - not as quiet failures to ignore.
Can we fork this checklist for our company?
Yes.
Keep the categories; replace tool classes and severity rules with your standards and link internal runbooks.
Where should new engineers start reading?
How Prompt Injection Attacks Actually Work, then Prompt Injection & Guardrails Basics, then this checklist as a gate.
Related
- How Prompt Injection Attacks Actually Work - threat model and attack channels.
- Prompt Injection & Guardrails Basics - hands-on first examples.
- Isolating Untrusted Content from Trusted Instructions - detail behind category B.
- Output Validation with Pydantic and Zod Against Malicious Content - detail behind category C.
- Guardrail Libraries and Content-Filtering Layers for Agents - filter stack map.
- Red-Teaming Your Own Agent for Injection Vulnerabilities - detail behind category E.
- Detecting and Logging Suspected Injection Attempts - detail behind category D.
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.