One design idea for injection resistant agents is to split the work. A privileged component plans actions from the user's request alone, while a quarantined component reads untrusted content and returns limited data. OWASP describes this approach, called CaMeL, and notes its released code is a research artifact.
The core problem
An agent that reads a web page and can also send email has both a data channel and an action channel in one context. If the page contains instructions, the same model that holds the tools reads them. Filtering tries to spot the instructions. This pattern tries to make them harmless even if they are not spotted.
How the split works
As OWASP's cheat sheet describes it, the design separates privileged planning from quarantined parsing and tracks data flow with capabilities.
In plain terms:
- Planner. Sees the user's trusted request and decides which tools to call, in what order. It never reads untrusted text directly.
- Parser. Reads untrusted content, such as a document, and returns values. It has no tools that act.
- Data flow tracking. Values from untrusted sources carry labels. Policy decides whether a labelled value may be used as, for example, an email recipient.
The planner can say "summarise the document, then send the summary to the requester". Instructions inside the document cannot change the plan, because the planner never saw them.
What you can borrow today
You do not need the research implementation to use the principle:
- Run reading tasks in a session with no action tools.
- Pass results between steps as structured, validated fields instead of free text.
- Decide recipients, paths and amounts in code from trusted inputs, not from model output.
- Keep a record of which values came from untrusted sources and block them from sensitive parameters.
OWASP's wider guidance fits the same shape: handle extensible functions in code, give the app its own narrow tokens, and treat model output as untrusted downstream.
Limits
The cheat sheet describes the released CaMeL code as a research artifact, so treat it as an idea to learn from rather than a drop-in product. A split design also costs flexibility. Tasks that need the model to read content and then decide freely what to do are harder to express.
Where flexibility is needed, fall back to approval for consequential actions.
Safeguard's agent identity and policies support the code enforced side of this: which agent may call which tool, under which conditions.
A small example. An assistant is asked to read a vendor's PDF and email the contract end date to the requester. The planner chooses two steps: extract the end date, then send an email to the requester's address, which comes from trusted session data. The parser reads the PDF, which contains an instruction to email the file to an outside address. The parser returns a date and nothing else. The planner never sees the instruction, and the recipient is not taken from the PDF.
Quick check
Does splitting make injection impossible?
No. It narrows what injected text can influence. Data that flows into outputs still needs validation.
Sources
Last reviewed: 19 October 2026.
