Context
What happened, and why it matters
An indirect attack can be hidden in a document, web page or message that an AI system later reads. If the system also has tools, the model may be persuaded to reveal information or request an unwanted action.
Filtering suspicious phrases is not a sufficient security boundary because natural language has too many equivalent forms and legitimate instructions can conflict. The architecture must assume some attacks will reach the model.
Impact reduction is therefore central: restrict data, restrict tools, separate trust zones, require confirmation and make actions observable. If the remaining risk is unacceptable, the use case may not be suitable for an LLM.
Separate the announcement from the outcome
The named source explains what its publisher announced or recommended. It does not guarantee availability, suitability or results for every organisation.
Check the current primary source
Confirm dates, account eligibility, contractual terms and current documentation before changing a live service. Fast-moving products may differ from the version described here.
Use a controlled change
Define the intended result, owner and rollback route. Test with a limited scope, review evidence and document the decision before wider use.
Details
A useful way to read the update
| Risk | Architectural response |
|---|---|
| Hostile user prompt | Treat model output as untrusted |
| Hostile retrieved content | Separate sources and minimise privileges |
| Unwanted tool call | Allow-list actions and validate parameters |
| Sensitive output | Restrict context and apply access checks outside the model |
| Hidden failure | Log, monitor and provide a human route |
Work through the guide
Signal board
Choose a lens to make the information easier to scan.
NCSC prompt injection article
Identify every untrusted input source.
Keep authorisation outside the language model.
Decision check
Put the update in your own context
Decision path
Move from news to a controlled change.
- 1ReadPrimary source
- 2CheckYour context
- 3TestLimited scope
- 4ReviewUseful evidence
- 5RecordDecision & owner
Practical response
What to do next
- 01
Identify every untrusted input source.
- 02
Keep authorisation outside the language model.
- 03
Limit tools to the narrow task.
- 04
Add human approval before consequential actions.
- 05
Run adversarial tests and review logs.
Work through the guide
A controlled route forward
Treat model output as untrusted
Identify every untrusted input source.
Keep authorisation outside the language model.
Limit tools to the narrow task.
Questions
How to use this update responsibly
What period does this article cover?
NCSC guidance current in 2026. The article was published on 17 September 2026; check the linked source for changes made later.
Does the announcement mean every organisation should adopt it?
No. Availability, cost, risk and usefulness depend on the specific workflow. A limited test with an owner and measurable acceptance criteria is more informative than a provider demonstration.
How should unverified discussion be treated?
Forum posts, rumours and individual reviews can reveal questions worth testing, but they do not establish prevalence or fact. Confirm material decisions through primary documentation, direct testing and qualified advice where necessary.
Relevant service
Need help applying this to your own setup?
Our security, privacy & accessibility service can help you review the current position, decide what is proportionate and plan a clearly scoped next step.
Explore Security, privacy & accessibilitySources
Read the original material
These sources support the factual description above. External pages can change after our publication date.