When a model only generates text, prompt injection may look like an odd answer or context leakage. Once it can search, email, query databases or publish content, the same attack becomes a permission and workflow problem. Security must ask not only whether a model can be persuaded, but what the system can do at worst.
1. The short answer
Injected instructions can arrive through user input, web pages, PDFs, email, code comments and knowledge documents. Concatenating every external string into one prompt blurs data and instructions. Separate material to read from instructions that are allowed to change behavior, and enforce the distinction again at the tool layer.
2. The context
Permissions matter most. A model should not inherit permissions the caller does not have, and a document claiming to be a system message should not gain authority. A tool gateway should recalculate access from user, task, resource and action while limiting sensitive fields, batch size and destinations.
3. The real trade-offs
Red-team the full chain, not just a chat box. Include malicious pages, hidden text, cross-document instructions, unauthorized retrieval, external exfiltration, duplicate execution and mixed-language attacks. Log output, tool calls and whether the server blocked the final effect.
4. How to put it into practice
Defense is not one filter. Input separation, least privilege, tool schemas, output validation, approval, audit and alerts must work together. Even if a model proposes a dangerous plan, the system should stop before an external side effect and create an observable event.
5. Common failure modes
Longer prompts do not fix a weak permission structure. Measuring one attack success rate is also insufficient. Teams need to distinguish malicious input, false positives and problematic source documents instead of silently discarding every suspicious case.
6. FDE perspective
Agent security is not about making a model incapable of mistakes. It is about containing mistakes within reversible, auditable and low-impact boundaries. Red-team tests should be a release requirement rather than a post-incident demo.
A practical checklist before shipping or buying
- Separate external evidence from executable instructions.
- Recalculate tool access by user, resource and action.
- Test the full chain rather than a chat prompt alone.
- Block dangerous plans before external side effects.
What to do next
Start with a read-only agent, add malicious documents and access-boundary cases, and log every block.
This article is based on public documentation and research from OWASP LLM Top 10. The FDE perspective is editorial analysis, not a quotation from the source.
Turn this read into a practical next step.
Matched to this article automatically; each tool is managed independently from the admin.