The short answer
Prompt injection happens when content encountered by an AI system steers it away from the intended task. A malicious instruction may arrive through a document or webpage, not only through a user’s chat message. Protect the surrounding application so a manipulated answer does not automatically become an authorised action.
The business risk is the access around the model
OWASP and NCSC describe why untrusted content can influence model behaviour. An instruction to ignore malicious text is not a complete security boundary. The practical consequence depends on which information and actions the surrounding system exposes.
OWASP — Prompt Injection (2025) · NCSC — Prompt injection is not SQL injection
Questions to ask before approving an AI assistant
The following is our proposed buyer worksheet. Ask for demonstrations in an authorised test environment, not simply a statement that the vendor has a filter. Use fabricated or explicitly approved test records.
| Question | A useful demonstration |
|---|---|
| Can retrieved content change the task? | A harmless test document asks the assistant to depart from its task. Check the output and any attempted actions. |
| Can it see another user’s records? | Two test accounts with different rights ask related questions. Verify that source permissions remain effective. |
| Can output trigger a consequential action? | The assistant proposes an unapproved change. Confirm that an independent permission or approval check blocks it. |
| Can it send information elsewhere? | Review permitted destinations and try a controlled request to an unapproved test destination. |
| Can we investigate a failure? | Reconstruct the source, model or configuration version, tool request and resulting application decision. |
An illustrative incident: a poisoned support document
Imagine an assistant drafting a customer-support response from a knowledge base. A test document contains an unrelated instruction to export customer records. The desired outcome is more than a polite refusal: the application must not expose a general export capability to that workflow. If the model produces a dangerous instruction anyway, a separate enforcement point should deny it. Record what happened at both the model and application layers. This fictional example is a design discussion, not a report of a customer incident.
Define success before you test
Write expected outcomes for each case: what data may be returned, which actions are allowed and when a person must decide. Include normal requests as well as malicious-looking ones so the test also detects controls that make the assistant unusable. A narrow pass does not prove universal resistance. Record the scope and repeat relevant tests after changing a model, prompt, retrieval source or tool integration.
How to use this in a supplier conversation
Ask the supplier to explain its responsibility and yours. Identify which controls are built into the product and which depend on your configuration. Keep unresolved questions in the purchase decision rather than allowing a convincing demo to stand in for evidence. For a deeper technical review, examine identity, retrieval permissions, output handling and operations together.
Know what sits between an AI answer and a real action
Request a scoped security assessment of an assistant, agent or supplier. Agree the questions and evidence before the review starts.
Request a proposal →Keep reading
- Before your AI agent gets access: seven decisions to make
- Will AI replace your team? Start with a 90-day plan.
Sources and method
OWASP — Prompt Injection (2025) · NCSC — Prompt injection is not SQL injection
AI-assisted editorial guide by SundAI. Sources checked on 18 September 2026. Evidence confidence: high for the cited descriptions of risks and research; this worksheet and its examples are proposed practice, not measured client outcomes or a security guarantee. Future scenarios are not predictions.