The prompt is part of the attack surface.
When an AI system reads external content and uses tools, context becomes a security concern. What matters is which permissions that content can effectively acquire.
An assistant is asked to summarise a document. Alongside the actual content, the document contains an instruction: open additional files and send them to an external address. To a person, that sentence belongs to the document. A language model may treat it as an instruction to act. That boundary is where the security question begins for me.
In “When attackers become agents.”, I wrote about speed of action and responsibility. Building a product turns this into a concrete task: how do I prevent content being read from acquiring authority?
External content remains external content
Prompt injection can reach a system through documents, websites or tool responses. The OWASP guide describes these indirect attacks and recommends several layers of protection. An additional instruction in the system prompt is not a reliable security boundary.
For my design, this means that retrieved information may support an answer. It must not independently expand the task. If a document claims that processing requires more data, that is initially just a claim from an untrusted source.
There is a boundary between reading and acting
I would initially give a summarisation assistant exactly the read permissions its task requires. A sending tool would have no place in that task. Where actions are necessary, the application must check permissions, destinations and parameters outside the model.
Exporting data from someone else's workspace remains forbidden even if the model provides a convincing explanation. An approval should show exactly which data will go to which recipient. “May I proceed?” is not enough.
Outbound data flows belong in the design too
The document example is about more than a wrong answer. It is about whether information can leave its intended environment. For every tool, I would therefore define which data it may read and where it may transfer it. Credentials do not belong in a prompt as explanatory context.
This also changes how I look at convenience features. General network access may simplify a demo. In a product, I need to explain why the task requires it and how its scope is limited.
The boundary has to withstand the attempt
Before a release, I would deliberately add manipulated instructions to the document and inspect the entire workflow. Did the system read additional data? Attempt to send anything? Did the application block it? A polite final response tells me little about those questions.
I do not want to depend on the model recognising every attack. I want to know which consequences remain possible when it misses one. That is where I find out whether my security boundaries hold.