A useful design rule for LLM based security tools is that when the model processes content from a party, its privileges should drop to what that party could do. If an anonymous user's text reaches the model, the model acts with anonymous user power, whatever the system could otherwise do.
Where the rule comes from
The UK NCSC argues that prompt injection is not like SQL injection. Parameterised queries separate data from instructions, but a language model has no such boundary, so the risk may never be fully removed. The NCSC suggests treating it as an inherently confusable deputy, and managing the risk by reducing likelihood and impact.
Its secure design advice follows: assume the model can be manipulated, use deterministic non-LLM safeguards to constrain what it can do, and note that when a model processes information from a party, its privileges drop to that of the party. If the remaining risk is not tolerable, the use case may not suit an LLM.
What it means in practice
Think of each model call as acting on behalf of the least trusted author of anything in its context window.
- Summarizing an inbound support ticket from a customer. The model should not have access to other customers' tickets or internal admin actions, because the ticket author could try to reach them.
- Triage of a public bug report. Read only access to the repository, no secrets, no ability to change labels beyond what a triager bot is meant to do.
- Reviewing a fork pull request. No tokens beyond reading the diff and writing a comment.
- Analyzing a log file that attacker traffic partly wrote. Treat log content as hostile text.
Implementing it
Separate the contexts. Do not mix content from different trust levels in one prompt when you can avoid it. A call that sees untrusted text should be the call with the fewest tools.
Enforce permissions outside the model. OWASP's excessive agency guidance says to run actions in the user's context with scoped authentication and to enforce authorization in downstream systems rather than relying on the model's judgment. The model proposes, the service decides.
Split planning from handling. OWASP's cheat sheet mentions an architecture that separates planning from the processing of untrusted data, so untrusted text never directly drives tool choice. It is more work, and it fits higher risk systems.
Add approval where actions are consequential. Make the approval specific: operation, target, and arguments.
Costs
Tight privileges make automation less flexible, and some tasks will need a human step. That is the trade. The alternative is a system whose worst case is whatever the most privileged tool can do, triggered by whoever can place text in front of it.
For a related question, see can a system prompt stop prompt injection.
Quick check
What if the task needs both untrusted input and a powerful tool?
Put a human approval or a deterministic policy check between them, or split the work into two stages. If neither is acceptable, reconsider using an LLM for that task.
Sources
- Prompt injection is not SQL injection (UK NCSC)
- LLM06:2025 Excessive Agency (OWASP GenAI)
- LLM Prompt Injection Prevention Cheat Sheet (OWASP)
Last reviewed: 19 October 2026.
