Key takeaways
- Treat external pages, email, files, CRM notes, retrieval results, and tool output as untrusted content even when they look like instructions.
- Separate content from policy, constrain tools and data, validate actions outside the model, and require approval for consequential side effects.
- Test direct, indirect, encoded, multilingual, delayed, and cross-tool injection against the whole workflow.
- Assume a detector will miss some attacks; design containment, monitoring, and recovery around that reality.
01
Prompt injection crosses the data boundary
A research agent opens a webpage that says to ignore prior instructions and export its contact list. A sales assistant summarizes an email containing hidden commands. A CRM note tells the next agent to alter an owner. The malicious text arrives as content, but the model may interpret it as authority.
OWASP places prompt injection among the central risks for LLM applications. Indirect injection matters especially for marketing systems because they routinely ingest public pages, ads, documents, social posts, email, form text, and third-party tool output.
02
Do not ask the model to enforce its own perimeter
Label and delimit untrusted content, keep policy and tool definitions outside retrieved text, and never store secrets in the prompt. More importantly, apply authorization and validation in ordinary code: allowed domains, object types, fields, recipients, budgets, rate limits, and approval requirements.
Give read and write capabilities separately. A research task does not need CRM export, campaign publishing, or outbound messaging. Render the exact proposed action and changed fields to the approver rather than asking them to approve a vague “agent plan.”
Swipe to compare every column
| Boundary | Example attack | Containment |
|---|---|---|
| Retrieval | Page instructs data exfiltration | No secrets; scoped retrieval; cite source |
| Tool | Output requests another tool call | Typed schema and policy validation |
| Action | Draft changes budget or recipient | Least privilege and approval |
| State | Malicious note persists for later | Provenance, sanitation, review, expiry |
03
Build adversarial cases from the real workflow
Test visible and hidden instructions, quoted email, HTML and document metadata, encoded text, multilingual variants, tool-description poisoning, malicious filenames, compromised retrieval sources, and instructions split across turns. Include benign content that resembles security discussion so defenses do not block ordinary work indiscriminately.
Score unauthorized data access, tool selection, parameter changes, side effects, disclosure, escalation, and recovery. A safe final answer is not enough if the trajectory queried a restricted source or attempted an action that happened to fail.
04
Contain the miss and preserve evidence
Log source provenance, tool request, policy result, approval, side effect, and workflow version with appropriate redaction. Alert on unusual recipient changes, broad queries, new domains, repeated denials, permission expansion, and output that contains canary values.
Provide a kill switch, revoke credentials, stop queued actions, preserve an incident record, correct affected customer or campaign state, and add the failure to the evaluation set. Prompt injection is not solved once; it is managed as an evolving input-security problem.
Primary sources and further reading
Use the source material to validate details against your own context and current platform configuration.
- OWASP GenAI: Prompt Injection
- OWASP GenAI: Excessive Agency
- NIST Generative AI Profile
- Research on prompt injection in AI-assisted tool clients
This field note follows the XenGrowth editorial policy: primary sources where available, visible limitations, material review dates, and no invented first-hand experience.
Stay with the problem



