An employee asks an AI agent to summarise a contract. The document may contain a sentence aimed not at the employee but at the model: ignore the task, call a tool or send information to a different recipient. The employee never authorised that action, but the model receives the instruction-shaped text alongside the content.
That is the prompt injection problem: untrusted data attempts to become authority. Conventional software has familiar boundaries between data and executable instructions. AI systems need deliberate controls around that boundary.
Text from a document is not permission
An email, webpage, search result or retrieved file may be useful evidence. Its author should not gain authority to direct the agent, especially if the agent can read private records and invoke APIs.
Malicious instructions do not always say “ignore previous rules”. They may resemble normal documentation, task notes or an instruction embedded in a workflow. Filtering a list of suspicious words is not enough.
The strongest boundary lives outside the prompt
System instructions can reduce risk, but they are not access control. Tool calls need independent checks: on whose behalf is this action performed, which resource is involved and is the operation actually allowed?
Avoid universal high-privilege credentials. Separate reads from writes, minimise tool access, constrain destinations for data sharing and require meaningful approval for high-impact actions.
If model output feeds a command, query or executable input, validate it against a strict contract. Structured data reduces some attack paths but does not make the proposed action inherently safe.
Test the workflow, not just the wording
Security tests should include untrusted emails, documents, search results and tool outputs. Inspect which actions the agent attempted, where data would have gone and which controls blocked unauthorised operations.
Risk depends on what the system can do. A reader of public articles needs different safeguards from an agent authorised to edit payment details or customer access.
The answer to prompt injection is not faith in a perfect prompt. It is an architecture where somebody else's text cannot grant itself permission.
See the OWASP Top 10 for LLM Applications for the wider risk landscape.