Prompt injection: Why a good system prompt is not enough
A research agent needs to read external websites. Those pages can also contain instructions unrelated to its task. This is an architectural question for any tool that connects AI, outside content and real actions, rather than an obscure issue reserved for security laboratories.
Research checked: 2026-09-09 · Cover: AI-generated illustration
When a source claims to give a new instruction
OWASP describes prompt injection as manipulation through input intended to alter a language model’s behavior. Indirect attacks arrive through documents, websites or tool responses. A source might claim that the next step requires sending a file to a different recipient.
That source has not granted permission. The application needs to enforce this distinction. A warning in a prompt can help, but it cannot replace limited tool permissions or validation of the proposed action.
Plan reading and acting separately
For research inside a content platform, I would first establish which sources may be read and which outputs are expected. Research material enters the context as labelled source data. It must not independently define new recipients, credentials or publication destinations.
In an outreach workflow, the distinction is concrete: reading a website and sending a message are different operations. The latter needs an intended recipient, acceptable content and appropriate authorization. A link on the page being read does not supply those conditions.
Give tools a narrow range of actions
I would separate tools around real tasks. A draft-writing function does not need permission to send. Searching approved records does not require exporting arbitrary databases. Before changes, the backend checks identity, destination and scope again.
This also helps with ordinary mistakes. If an agent picks the wrong tool, the possible impact is bounded. Security records should show what was attempted and why it was rejected without unnecessarily copying sensitive material.
The workflow at a glance
- 01Read sourceLabel external content
- 02Check actionVerify destination and permissions
- 03Execute narrowlyOnly the authorized task
A useful pre-release test
I would test with a synthetic document containing a conspicuous unrelated instruction. The factual summary should still work while the unrequested side effect does not occur. Additional cases should attempt to redirect otherwise permitted data to a forbidden destination.
The criterion is not whether the model prints a warning. It is whether an unauthorized action actually occurred. Such tests reduce a specific risk; they do not establish immunity to all future inputs.
