Prompt injection is a risk when an AI system treats material it is supposed to read as instructions about how it should behave. In healthcare, the concern becomes more consequential when the same system can also retrieve records, send messages or change workflow status. The central safeguard is to control its authority outside the model, not merely ask it to ignore suspicious text.
A clinical document is evidence, not an administrator
Imagine a fictional assistant reading an external document to prepare a referral summary. Alongside ordinary information, the document contains language that attempts to redirect the assistant away from its assigned task. This is a defensive illustration, not a report about a commercial product or instructions for constructing an attack.
The document may legitimately contain clinical instructions for a person, such as an agreed follow-up plan. That does not make it a source of authority over the software's permissions. The application must distinguish describing a clinical request from granting the ability to execute it.
The NCSC's December 2025 discussion of prompt injection explains why this differs from conventional injection vulnerabilities: language models do not provide a dependable instruction-versus-data boundary simply because developers ask for one. Its practical emphasis is on managing consequences, not assuming a stronger prompt eliminates the problem.
Follow the risk from reading to acting
For a reference-only workflow, a successful diversion might contaminate the answer or its choice of evidence. For a connected agent, the same diversion could influence which record is accessed, which destination is selected or whether an unfinished task is marked complete. These are possible failure pathways to test, not interchangeable levels of harm.
A useful assessment therefore starts with the action boundary. What can the system read? What can it propose? What can it commit? Which external destinations can it contact? What prevents a document from expanding that authority?
The important question is not whether the assistant appears sensible during an ordinary demonstration. It is whether an inappropriate request can cross a consequential boundary when the model behaves unexpectedly.
Keep authorisation in ordinary controls
The proposed design is to make permissions explicit in application logic. A model output can request an action, but the surrounding system should check whether that action is permitted for the authenticated user, patient, task and destination. A plausible explanation from the model should not satisfy those checks.
For example, an assistant authorised to draft correspondence need not also possess permission to send it. A tool that reads selected records for a defined task need not receive organisation-wide access. Where approval is required, the approving person should see the actual action, recipient and relevant context, not merely a conversational statement that everything is ready.
The NIST zero-trust architecture publication, published in August 2020, is a useful wider security reference for resource-specific authentication and authorisation. It is not a healthcare-AI certification or a requirement that every NHS organisation adopt one particular technical architecture.
Labels and filters help, but should not carry the whole burden
Clear separation between trusted instructions and retrieved material is sensible design. Input screening, restricted formats and warnings may also reduce some risks. The mistake would be treating those measures as a proof that external content can no longer influence the model.
A proposed safety review should ask what happens after those measures fail. Is the output still constrained to a draft? Does a non-AI permission check block an unapproved destination? Can the tool alter an existing record without a meaningful confirmation? Are sensitive credentials available to the model when they could instead remain with a controlled service?
This is a change from prevention-only thinking to consequence control. It accepts that the model may be confused while refusing to let that confusion redefine the authority it holds.
Test the complete workflow in an authorised environment
Testing should use synthetic or appropriately authorised material in a controlled environment. The goal is not simply to count whether the model repeats an unwanted phrase. It is to establish whether the surrounding application prevents prohibited access, disclosure or action.
A clinical and technical team can agree a small set of protected boundaries: patient identity cannot change because an external document suggests it; a draft cannot become a sent message without the required authorisation; a failed task cannot be reported as complete without supporting system evidence.
Include legitimate but unusual documents as well as adversarial test material. A filter that blocks necessary clinical information may create a different failure. The assessment should therefore record inappropriate actions, correct refusals, unnecessary refusals and the work required to recover.
No such tests are reported in this article. These are proposed evaluation criteria, and any performance claims would require an actual documented run against the intended system configuration.
Plan for detection and recovery
A useful audit trail should distinguish the source material, the model's proposal, the permission decision and the action that actually occurred. Access to that evidence must itself be controlled and proportionate; incident investigation is not a reason to retain unrestricted copies of patient information everywhere.
If an inappropriate action is suspected, the team should be able to suspend the affected permission without unnecessarily disabling unrelated care. It also needs to identify potentially affected patients, messages or records and determine which consequences cannot be reversed technically.
The NCSC's secure-deployment guidance, published in November 2023, places incident-management arrangements within secure deployment. For a healthcare service, the local plan should connect that technical response with clinical continuity and patient communication.
Source-visible reference is a different use case, not immunity
A reference tool with no authority to send a message presents a different action risk from an agent with write access. Its answers can still mislead a reader, including through contaminated source material or faulty interpretation.
iatroX's methodology, checked on 10 October 2026, describes a source-grounded reference workflow. That description is not proof of immunity to prompt injection or a published security test. Clinicians should inspect important source claims and keep patient-identifiable information within approved systems.
The defensible aim is bounded usefulness: let the software assist with a specified task while ensuring that neither a retrieved document nor a model-generated explanation can quietly award it greater authority.
Frequently asked questions
Can a strong system prompt eliminate prompt injection?
It should not be treated as a guarantee. Consequential permissions need enforcement outside the model so that an unexpected response cannot redefine what the system may do.
Is prompt injection only relevant to agents that can write to records?
No. It can also affect answer content and evidence selection, although tool access can create additional opportunities for operational harm.
What should a healthcare buyer ask to see?
Ask for the exact permission boundaries, authorised testing of those boundaries and evidence that prohibited actions remain blocked when the model is misled. A successful conversational demonstration is not the same as an end-to-end security evaluation.