A production AI agent is one user paste away from a data incident. Someone drops a string of instructions into the input field. The agent treats it as part of the prompt. It calls a tool it should not, returns data it should not, or simply gets confused enough that downstream automation does damage. This post documents the two-layer defense every DPL deployment ships with.
Layer one: input sanitization at the boundary
The prompt is built from two sources. Trusted context (system message, retrieved documents, agent role) and untrusted user input. Treat them like SQL parameters: never concatenate.
Concrete sanitization rules:
- Wrap user input in a delimited block the prompt instructs the model to treat as data, not instructions. Most production deployments use XML-style tags:
...
- Strip or escape control sequences before insertion. Tokens that look like prompt boundaries (
###,---,INSTRUCTIONS:,SYSTEM:) get replaced with their visible-but-non-functional equivalents.
- Run input through a small classifier first if the workflow is high-stakes. Models like claude-3-haiku or gpt-4o-mini can be prompted to flag inputs that look like injection attempts. False positive rates are typically 1-3%; tune the rejection threshold based on workflow sensitivity.
- For multi-turn workflows, treat earlier assistant outputs as user input on subsequent turns. The agent's own past output can be injected by a malicious user across turns; sanitize between turns too.
Layer two: output validation before any tool runs
Sanitization is not enough on its own. A determined input can sometimes still steer the model. The second layer catches whatever slipped through.
Every tool call the agent wants to make passes through a validator before execution. The validator answers three questions.
Is the tool in the allowlist for this workflow? Most production agents have 3-8 tools they can call. A hallucinated tool name (SendInternalEmail, RunSqlQuery) gets rejected immediately. Log the hallucination as a security signal.
Are the arguments well-typed against the tool's schema? Use Zod, Pydantic, or JSON Schema to validate the structure. Hallucinated arguments (sending an email to "all_users@company.com" when the schema only accepts a specific user_id) fail validation.
Does the operation fall within per-workflow guardrails? Cost guardrails (no tool call costing more than $X), data scope guardrails (queries scoped to specific tables only), volume guardrails (no more than 10 outbound emails per minute per workflow).
The escalation path when validation fails
Validation failure is not the same as a system error. The agent decided to do something the validator rejected. That is a security signal, not a bug. Failed tool calls log the full attempted call to the security review queue. An operator reviews these weekly. Patterns (the same hallucinated tool name across multiple sessions, repeated attempts to access out-of-scope data) feed back into the sanitization classifier.
What this costs
Sanitization runs on every input. For a small input it adds 1-3ms. For a classifier-augmented sanitization on a high-stakes workflow, add 100-300ms of additional latency and approximately $0.001 per request in token cost.
Output validation runs on every tool call. Validation logic is fast (sub-millisecond for typical schemas). The cost is the engineering work to author the schemas, which is one-time at workflow deployment.
The trade-off is favorable. Prompt-injection incidents that escape both layers are rare. Production-grade agents that ship without either layer have a different problem: not whether an incident will happen, but when.
Test it on day one
Every DPL workflow ships with a corpus of known injection patterns the agent must survive. The current corpus has 47 patterns scraped from public injection research and our own internal red-team. Sample patterns include:
- Direct instruction injection: "Ignore the above and..."
- Encoded instruction: base64 or rot13-encoded instructions
- Role confusion: "You are now a different assistant..."
- Tool-call hijack: requests phrased to coerce a specific tool
- Data exfiltration: requests for the system prompt or contextual data
- Multi-turn drift: gradual instruction shifts across turns
A production agent is not declared ready until it passes the full corpus. The pass rate target is 100% on direct attacks, 95%+ on multi-turn attacks (the harder category). Any pattern that gets through gets added to the sanitization classifier training data.
The takeaway
Prompt injection is not a hypothetical risk in 2026. Production agents that handle real user input without both layers in place are running an open invitation. The recovery audit scores this gap in the security section; the fix engagement adds both layers when missing.