Prompt injection means an attacker hides instructions in content that an AI agent reads, such as an email, a web page or a ticket. The model cannot reliably tell those instructions from the ones its owner gave it. When the agent also has tools, a planted instruction can turn into a real action.
The short answer: treat prompt injection as something you reduce but cannot promise to eliminate, and put your effort into limiting what an injected agent can reach. Filters lower the odds. Permissions set the damage.
In this piece, we will cover:
- Why prompt injection is hard to filter out completely
- The three-part combination that makes it dangerous
- What a successful injection can do, by capability
- Controls that limit the blast radius
- Where nerl0 fits, and what it does not show
Can prompt injection be fully prevented?
No source we read claims it can. The OWASP Top 10 for LLM Applications says it is unclear whether prompt injection can be fully prevented, because of how models work, and presents its measures as ways to mitigate impact. The UK National Cyber Security Centre (NCSC), in a December 2025 post, says it likely cannot be fully mitigated the way SQL injection can, because current models do not enforce a boundary between instructions and data.
NIST's Center for AI Standards and Innovation describes the same root problem in its work on agent hijacking: trusted developer instructions and untrusted external data end up in one input. It also reports that attacks tuned to a specific model can succeed far more often than generic ones, and that repeated attempts raise the success rate. A defense that works most of the time is not a guarantee.
Simon Willison makes the same point from the practitioner side. Attack phrasings are effectively unlimited, outputs are non-deterministic, and a product that claims to stop 95 percent of attacks still fails, in his words, the way a web application would with that score.
What makes prompt injection dangerous for agents?
Willison calls the risky combination the lethal trifecta. An agent is exposed when it has all three of these:
- Access to private data. Often this is the reason the tools exist.
- Exposure to untrusted content. Any text or image an attacker could get in front of the model.
- A way to communicate externally. Web requests, loaded images or clickable links can all carry data out.
Remove one of the three and the chain breaks. Willison notes that a single tool can supply all three at once. His example is a GitHub MCP server exploit in which one tool read public issues, reached private repositories and opened pull requests that leaked private data. He also warns that tool protocols such as MCP make it easy to assemble the combination without noticing. The post on MCP servers as a doorway with credentials covers that side.
What can an injected agent do, and which control limits it?
Injection chooses the attempt. The agent's tools and credentials decide the outcome. OWASP's Excessive Agency entry names three root causes: more functions than needed, more permissions than needed, and more autonomy than needed. The table maps common capabilities to the risk they add and the control the sources suggest.
| Agent capability | Risk if injected | Control |
|---|---|---|
| Open-ended tool such as shell or URL fetch | Attacker chooses the action or the destination | Replace with a narrow, task-specific tool (OWASP) |
| Write access to a database or repository | Data changed or leaked through legitimate calls | Grant read-only rights where the task allows (OWASP) |
| Shared service account | Injected agent inherits everyone's access | Act in the user's context with minimal scopes (OWASP) |
| Outbound requests, images, links | A path to carry private data out | Do not combine with private data and untrusted input (Willison) |
| High-impact action without a person | Irreversible step runs unreviewed | Human approval for high-risk actions (OWASP) |
The NCSC puts the worst case plainly: assume an attacker could direct any tool the model can call. Design as if that is true.
How do you limit the blast radius?
- List the tools each agent can call. Include tools added through MCP servers and plugins, not only the ones your team built.
- Check each agent for the trifecta. Does it reach private data, read untrusted content and have an outbound channel? If all three, split the job across agents or remove one leg.
- Use a separate identity per agent. A shared account makes every agent as powerful as the strongest one. The non-human identity an agent runs as should match its task.
- Cut permissions to the task. Prefer read-only access and narrow scopes. Willison, quoted by the NCSC, frames it as dropping the model's privileges to those of whoever supplied the content.
- Enforce limits outside the model. OWASP calls this complete mediation: downstream systems check every request against policy instead of trusting the model's judgment. The NCSC likewise prefers deterministic safeguards to filtering alone.
- Log and watch. OWASP and the NCSC both recommend logging tool calls. The NCSC adds that repeated failed calls can show an attack being refined.
Filters and a firm system prompt still have a place. OWASP lists input and output filtering as one mitigation among seven. They sit on top of the permission limits, not in place of them. The NCSC warns that deny-lists of known bad phrases are weak because attacks can be reworded endlessly.
None of these controls makes injection impossible. They make a successful injection smaller. The NCSC says that if a system cannot tolerate the remaining risk, an LLM may not be the right choice for that job. Willison's view is that vendors cannot solve this for you when you combine tools yourself.
Where nerl0 fits
Most of the controls above depend on knowing what each agent can reach. nerl0 maps every AI agent and non-human identity and what each can reach. It connects read-only through each platform's own interfaces and reads configuration and permission data, never the contents of data stores.
The authority paths in the Security Graph show agent, credential, role and crown-jewel data store, and every step is an observed relationship. That makes the question "which agents hold a write permission and a route to a sensitive store?" something you can read instead of guess. You can put it to the Agent in plain language. If you activate it as a Question, it is measured again with every scan. For a walk through a path, see how to read the Security Graph. Terms such as crown jewel and blast radius are explained in the Academy glossary.
Issues carry severity, evidence, an owner and a recommended breakpoint. The next scan verifies the fix. Every answer states what it cannot show.
A path is a route that exists in configuration. "Proven" describes the route, not that anyone used it, and nerl0 does not tell you whether a given prompt would persuade an agent to follow it. It does not read the content an agent processes. See A route is not proof of use and Read-only by default.
Two related guides: the MCP server security checklist for the tools an agent connects to, and least privilege for AI agents for shrinking what it can reach.
Summary
Prompt injection is a design problem with no complete filter. OWASP, the NCSC and NIST all describe it as something to mitigate, not to switch off. The useful question is what the injected agent can reach. Avoid giving one agent private data, untrusted input and an outbound channel together, give each agent its own narrow identity, and enforce limits outside the model.
Sources
- The lethal trifecta for AI agents: private data, untrusted content, and external communication, Simon Willison's Weblog, accessed Nov 4, 2026
- LLM01:2025 Prompt Injection, OWASP GenAI Security Project, accessed Nov 4, 2026
- LLM06:2025 Excessive Agency, OWASP GenAI Security Project, accessed Nov 4, 2026
- Strengthening AI Agent Hijacking Evaluations, NIST, accessed Nov 4, 2026
- Prompt injection is not SQL injection (it may be worse), UK NCSC, accessed Nov 4, 2026
Sascha writes about what AI agents and non-human identities can reach, and builds nerl0 to keep that visible.