Prompt injection: definition, risk and defence
Why the Term Matters
As soon as an assistant reads emails, opens web pages or acts inside systems, every foreign source becomes a possible entry point. A model does not naturally separate your instruction from a sentence that sits inside a document. Ignore this and you build an assistant that leaks sensitive content on a stranger's command. That is why the question of prompt injection belongs in every build that hands an agent real permissions.
When It Is Relevant
- The assistant processes content from sources you do not control.
- An agent may trigger actions, not just generate text.
- Confidential data sits within the system's reach.
- External users or customers feed the system with their own inputs.
When Not
A pure text generator without tools, without data access and without external inputs carries low risk. When the model only rewrites a fixed, internally controlled text and no stranger feeds in content, defence against prompt injection is not the priority. The picture changes the moment the system opens outward.
Industries That Use It
- Banks and insurers: customer assistants must not reveal account data just because a manipulated document tells them to.
- Legal advice and law firms: contract reviews run on submitted foreign files whose content must never become an instruction.
- Public administration: citizen-facing systems process foreign inputs and need clear limits against slipped-in commands.
- Healthcare: assistants with access to patient records must be hardened against leakage through manipulated text.
Typical Use Cases
- A support assistant reads customer emails that contain hidden commands and gets tested against them.
- A research agent opens web pages that carry an instruction to siphon off data.
- A document assistant processes PDFs with embedded text that tries to redirect the system.
- A sales agent pulls data from a CRM whose free-text fields an attacker has filled.
- An internal chatbot receives poisoned entries through a knowledge base.
Decision Guide
| Signal | Prompt injection is a concern | Alternative |
|---|---|---|
| System processes foreign content | plan hardening and tests | curate internal sources strictly |
| Agent has action permissions | limit rights, add approvals | choose a suggestion-only mode |
| Only fixed internal text | low risk | standard checks suffice |
| Sensitive data within reach | actively prevent leakage | keep data out of the context |
Example
In a workshop a team builds an assistant that summarises incoming applications. In a test file the team hides a line that tells the assistant to output the internal scoring criteria. The prototype falls for it, and that is exactly what makes the risk visible. The team then hardens the separation between instruction and content and tests again. This describes the method, not an asserted client metric.
Service Connection
The fitting entry is the AI workshop, where the attack is tested on the prototype, then AI implementation and AI consulting for permissions and approvals.
Sources
This framing describes common practice when securing AI assistants and agents. The concrete threat picture and effective measures depend on the setup, the data sources and the granted permissions and should be checked in the specific project.