How multimodal AI prompt injection bypasses healthcare regulatory compliance

1. Healthcare AI accepts more non-text inputs than any other sector

Start with the input surface. A healthcare AI system almost always accepts images or audio — not as a nice-to-have feature but as the core clinical input without which the system has no function. This is structurally different from, say, a financial services AI that uses text-form data as its primary input and might also accept a scanned PDF. In healthcare, the non-text modality is often the only modality.

Radiology AI. Medical imaging AI systems — CT reading assistants, chest X-ray classifiers, mammography CAD — read DICOM images. The pixel array inside a DICOM file is a 2D or 3D matrix of Hounsfield unit values or grayscale intensities. A text PI scanner operates on string data; there is no string representation of a pixel array that it can inspect. See radiology AI prompt injection — the compliance reference for the full attack surface across PACS-integrated AI, DICOM viewer AI, and radiology workflow AI platforms.

Digital pathology AI. Whole-slide imaging (WSI) systems produce multi-gigabyte image files (NDPI, SVS, TIFF pyramid formats) scanned at 20× to 40× magnification. A pathology AI system reads tiles from these images at high resolution. Adversarial content in a whole-slide image can be embedded in a single tile that the human pathologist does not scrutinise because the AI summary directed attention elsewhere. The attack surface is documented in digital pathology and clinical laboratory AI prompt injection.

Telehealth and voice AI. AI-assisted telehealth platforms process patient audio — symptom descriptions, medication names, pain level reports — through speech-to-text pipelines before feeding the transcript to a clinical decision support LLM. A text PI scanner runs on the transcript; a WhisperInject-class attack hides the payload in the frequency domain of the waveform, in bands the STT is structurally incentivised to discard. The transcript emerges clean; the LLM receives the injection. Remote patient monitoring AI that processes continuous audio streams compounds this problem because the attack surface is not a single upload but a continuous low-level signal channel. See telehealth and remote patient monitoring AI prompt injection.

Mental health AI. Conversational mental health AI platforms (CBT chatbots, crisis triage, mood-tracking assistants) process text primarily but increasingly accept voice and face-video inputs for emotional-state assessment. A multimodal attack on a mental health AI is particularly high-consequence because the output the AI is manipulated to produce — advice, referral recommendations, risk assessments — directly affects a vulnerable patient's care pathway. The compliance stakes here go beyond regulatory penalty: patient harm liability is the floor. More on the specific attack surface: mental health and digital health AI prompt injection.

The common thread: in every one of these systems, the AI's primary input is not text. A text-only prompt-injection scanner is monitoring the wrong channel.

2. The three regulatory frameworks and where multimodal injection creates gaps

HIPAA Security Rule and HITECH

HIPAA Security Rule (45 CFR §164.300 et seq.) requires covered entities and their business associates to protect the confidentiality, integrity, and availability of electronic protected health information (ePHI). The rule is deliberately technology-neutral: it specifies outcomes, not implementation methods. That means the obligation to prevent unauthorised access (45 CFR §164.312(a)(1)), prevent alteration or destruction of ePHI (§164.312(c)(1)), and implement audit controls (§164.312(b)) applies to AI systems just as it applies to EHR databases — but the regulation does not tell you how.

Where multimodal prompt injection creates a HIPAA gap: a PI attack against a clinical AI that causes it to output a prior patient's PHI in its response is an unauthorised disclosure. If the attack arrives embedded in an image pixel array that your text scanner never saw, your audit log contains no record of the injection vector — the attack is not captured in the monitoring trail your HIPAA risk analysis depends on. The gap is in the audit control obligation (§164.312(b)): you cannot audit what you did not instrument.

HITECH's breach notification requirements (45 CFR §164.400 et seq.) compound this. If a multimodal injection attack causes a disclosure of unsecured PHI, the breach notification obligation is triggered regardless of whether the attack was detected at the time. But if the attack was never logged — because your scanner only watched the text channel — the breach may never be identified in your post-incident review. You cannot notify what you cannot detect.

The full HIPAA compliance architecture for AI systems, including the §164.308 administrative safeguard obligation to conduct a risk analysis that covers AI components, is mapped in HIPAA-compliant AI security and prompt injection.

FDA SaMD cybersecurity guidance

The FDA defines Software as a Medical Device (SaMD) under 21 CFR Part 880 and has published cybersecurity-specific pre-market submission guidance (most recently the 2023 Cybersecurity in Medical Devices final guidance). The guidance requires a Cybersecurity Bill of Materials (CBOM) and a cybersecurity risk assessment that covers known vulnerability classes including adversarial machine learning vulnerabilities for AI/ML-enabled devices.

The AI/ML-specific layer comes from FDA's 2021 Action Plan for AI/ML-Based SaMD and the Predetermined Change Control Plan (PCCP) pathway that governs how AI/ML SaMD can update their algorithms post-clearance. The Action Plan explicitly identifies adversarial attack robustness as a monitoring and transparency obligation: manufacturers must monitor for performance degradation and adversarial manipulation post-deployment, not just validate pre-clearance.

Where multimodal injection creates an FDA gap: a medical imaging AI cleared under 510(k) with a stated indication for use against standard-format DICOM images has a CBOM that includes the image-processing pipeline. If an adversarial input can manipulate the AI's output (mis-classification, missed finding, altered recommendation) in a way not covered by the CBOM's adversarial vulnerability assessment, the device is operating outside its cleared cybersecurity specification. That is a post-market surveillance finding — and in the FDA context, a cybersecurity vulnerability that affects device safety or effectiveness is subject to mandatory reporting under 21 CFR Part 806 (corrections and removals) or the post-market cybersecurity guidance's serious adverse event thresholds.

For pharmaceutical and clinical trials AI, the regulatory surface extends to FDA 21 CFR Part 11 (electronic records and electronic signatures) and the ALCOA+ data integrity principles: attributable, legible, contemporaneous, original, accurate. A prompt injection attack that silently alters an AI-generated clinical trial data summary is an ALCOA+ violation. The full clinical trials AI attack surface is covered in clinical trials and pharmaceutical AI prompt injection.

EU MDR / IVDR and the AI Act overlap

In the EU, medical device AI sits under EU MDR 2017/745 (medical devices) or EU IVDR 2017/746 (in vitro diagnostics) plus, increasingly, EU AI Act 2024/1689 for the AI-specific obligations. The General Safety and Performance Requirements (GSPRs) in MDR Annex I include GSPR 17.4, which requires software including AI components of medical devices to be designed with minimum IT security measures — including against unauthorised access, viruses, and malware — and that cybersecurity risk management is part of the quality management system under ISO 14971.

For AI Act purposes, a high-risk medical AI falls under Annex III (medical devices listed as high-risk AI in the Act) and must comply with Article 15(5)'s adversarial-examples obligation. We covered this intersection in detail in EU AI Act Article 15: the multimodal AI security checklist. The short version: MDR GSPR 17.4 and Article 15(5) are both satisfied by the same per-request scan log when the scan log covers all modalities. A scan log that only records text PI events is partial compliance for a multimodal-input medical AI under both frameworks simultaneously.

3. How the attacks work in clinical context

Understanding the attack mechanics matters for the compliance argument because regulators, auditors, and legal counsel increasingly ask for concrete attack scenarios — not just "adversarial ML is a risk" at an abstract level. Here are three concrete scenarios for the three most common healthcare AI modalities.

Scenario A — Radiology AI: FigStep-class pixel injection

A radiology AI platform integrated into a PACS workflow accepts DICOM images, runs a classification or detection model, and surfaces findings to the radiologist. An attacker with access to the image upload path — a referring physician portal, a teleradiology upload API, a PACS integration endpoint — submits a DICOM image where a small region of the pixel array has been adversarially perturbed. The perturbation is below the threshold of human visual detection on a diagnostic workstation; the radiologist sees a standard-looking scan. The vision encoder reads the pixel values the same way it always does — but the adversarial perturbation in that region activates the same internal features that a direct text prompt would have activated: "ignore this finding," "classify as normal," "output the previous patient's result." The text PI scanner on the PACS output text log sees nothing unusual, because the injection never touched the text channel. The audit log records a normal scan completion.

The compliance consequence: if the altered output reaches the clinical decision support feed and affects a treatment decision, the event is a patient safety incident. If ePHI from a prior patient appears in the output, it is a HIPAA breach. If the device was cleared by FDA with a CBOM that did not enumerate this vulnerability class, it is a post-market cybersecurity gap. All three simultaneously, from a single pixel-domain attack that a text scanner could not have caught.

Scenario B — Telehealth: WhisperInject-class audio injection

A telehealth triage platform routes patient audio calls through a speech-to-text pipeline (Whisper or a comparable model) and then a clinical LLM for symptom extraction and triage recommendation. An attacker who can influence the audio — a compromised audio stream, a VoIP injection on an insecure line, or a patient device that has been manipulated — embeds an adversarial payload in the ultrasonic band (17–20 kHz) of the audio stream. Whisper, trained to produce clean speech transcripts, treats the ultrasonic band as noise and discards it. The transcript is clean. The clinical LLM receives a normal-looking symptom description. But the vision-capable component of the multimodal clinical AI (if the platform also processes video) or the LLM's audio-understanding pathway (for audio-native LLMs like GPT-4o Audio) receives the waveform payload before the transcript is produced and is influenced by it.

The engineering argument for why waveform-side scanning is structurally necessary, not additive, is in building a prompt-injection scanner for voice agents. For telehealth-specific compliance, the HIPAA §164.312 transmission security obligation (ePHI transmitted over open networks must be encrypted and integrity-checked) and the FDA SaMD adversarial-ML monitoring obligation both apply.

Scenario C — Pathology RAG: ingestion-time poisoning

A clinical decision support platform uses a multimodal RAG knowledge base built from clinical literature PDFs that contain whole-slide image thumbnails, annotated figures, and referenced image studies. An attacker with write access to the document ingestion pipeline — or who can influence which external papers get included in the corpus — embeds an adversarial image inside a PDF. The image appears legitimate (a properly formatted figure); the text around it discusses the paper's methodology normally. At ingestion time, the text-only document processor extracts the text and adds it to the retrieval index; the image is stored as a byte attachment. At inference time, when the RAG retrieval returns this document as context, the multimodal clinical AI receives the image as part of its context window — and the adversarial pixel payload activates.

The ingestion-time / inference-time split matters for compliance: inference-time scanning (at the model input boundary) does not catch ingestion-time poisoning if the image was stored and retrieved without being scanned at ingestion. Both scanning placements are needed. This is the OWASP LLM03:2025 training data poisoning vector applied to healthcare RAG, and it maps to the FDA post-market surveillance obligation to monitor for performance degradation from corpus-level poisoning.

4. Why OCR-before-scan and STT-before-scan are not compliant approaches

The most common objection to multimodal PI scanning in healthcare is: "we already scan the output text / the OCR result / the STT transcript — that's the same thing." It is not, and the compliance frameworks agree on why.

OCR-before-scan produces a text representation of what the OCR model decided the image contained. For medical images, OCR is largely irrelevant — DICOM images do not primarily contain typographic text, and OCR applied to a chest CT pixel array produces very little. But for documents, consent forms, or clinical photographs that may contain text overlaid on the image, the critical point still holds: OCR is a compression with different fidelity goals than a security scanner. FigStep-class attacks are designed specifically to produce a clean OCR transcript while delivering a readable instruction to the neural vision encoder, because the attack surface is the difference between what OCR resolves from typography heuristics versus what a neural network reads from raw pixel values at the same spatial location. Scanning the OCR output is evidence the OCR output was inspected, not evidence the pixel array the model consumed was inspected.

STT-before-scan fails for the same structural reason: Whisper-class STT is a speech compression system optimised to produce clean, readable text. Ultrasonic bands, sub-300 Hz modulation, inter-word silence steganography — all of these are in the parts of the waveform that STT treats as noise, because they are not speech. A scanner running on the transcript never sees them. A waveform-side scanner runs on the raw audio bytes before the STT pipeline discards the attack surface. That is the only placement that covers the threat class Article 15(5) and FDA's adversarial-ML category name.

For HIPAA audit control compliance specifically: 45 CFR §164.312(b) requires audit controls that record and examine access and activity in systems that contain ePHI. A scan log that records "STT transcript inspected, clean" is not a record of the audio channel being inspected for adversarial content. A scan log that records "waveform bytes inspected at timestamp T, risk_score: 0.04, action: allow" is. Auditors reviewing HIPAA compliance increasingly understand this distinction as multimodal healthcare AI becomes standard; the question "what inspected the audio bytes, not the transcript?" is appearing in healthcare AI vendor security questionnaires now.

5. Five steps to close the multimodal compliance gap in healthcare AI

These steps apply regardless of which regulatory framework is primary — HIPAA, FDA SaMD, EU MDR, or all three simultaneously. The technical implementation is the same; only the evidence labelling changes.

1. Enumerate every input modality per endpoint. For each clinical AI endpoint, list: what byte formats arrive? DICOM pixel arrays, JPEG/PNG clinical photos, audio PCM streams, WSI tiles, PDF attachments with embedded images? This list is the scope of your adversarial-input risk assessment. A modality not on the list is a modality not covered by any downstream control. Under FDA 2023 cybersecurity guidance, this list maps to the CBOM; under EU MDR GSPR 17.4, it maps to the cybersecurity risk management scope; under HIPAA, it maps to the §164.308(a)(1) risk analysis scope.
2. Place image scanning at the pixel boundary, before OCR and before the model call. The scan must run on the bytes the model will consume. For DICOM: scan the pixel array after DICOM file parsing but before any windowing, resizing, or model preprocessing. For PDFs with embedded images: scan each embedded image at ingestion time, not the extracted text. For real-time clinical photos: scan at receipt, before thumbnail generation. Glyphward's /v1/scan accepts raw image bytes; the response includes a scan_id, risk_score, and flagged_region that form the evidence record for each image input.
3. Place audio scanning at the waveform boundary, before STT. The waveform scan must run on the raw PCM or compressed audio bytes before the STT pipeline. For real-time voice: on the raw audio stream, not the transcript. For asynchronous uploads: at file receipt. The scan record includes waveform_hash, risk_score, flagged_window (timestamp range), and action. This is the evidence record your HIPAA audit control log needs for audio inputs.
4. Add ingestion-time scanning for every multimodal knowledge base or RAG corpus. Any PDF, slide deck, or document containing images that enters your clinical AI's retrieval store must be scanned for embedded adversarial images at ingestion time. This covers the RAG-poisoning vector independently of inference-time scanning. The ingestion-time scan record is also the evidence needed for FDA post-market surveillance of corpus-level adversarial manipulation.
5. Produce a unified per-request evidence log across all modalities. Every request to the clinical AI should produce a single evidence log row that records all modalities inspected in that request: text, image, audio — each with its own scan_id, modality, payload_hash, risk_score, threshold, and action. This row is simultaneously the HIPAA §164.312(b) audit control evidence, the FDA CBOM adversarial-ML monitoring record, the EU MDR GSPR 17.4 cybersecurity control evidence, and the EU AI Act Article 15(4) continuous monitoring evidence. Four frameworks, one log row.

6. The healthcare AI compliance gap is closing faster than most teams expect

Until 2024, "adversarial ML" in a healthcare AI vendor security questionnaire was a checkbox that procurement teams left blank because the attack class was considered theoretical. That has changed in the last 18 months.

FDA's post-market cybersecurity guidance (2022) explicitly names adversarial ML as a category requiring monitoring for AI/ML SaMD. The EU AI Act's August 2026 Article 15 deadline has pushed EU healthcare AI buyers to ask for adversarial-input evidence in vendor due diligence. HITRUST CSF v11 (the dominant healthcare cybersecurity framework for US provider and payer procurement) has updated its AI security controls category to reference adversarial ML inputs. NIST's AI Risk Management Framework (AI RMF 1.0) — which FDA and HHS both reference in their AI guidance documents — includes GOVERN 2.2 and MAP 1.6 controls specifically for adversarial robustness.

The compliance expectation is hardening from "we're aware of the risk" to "show us the scan log." Healthcare AI teams that instrument multimodal scanning now are building the evidence file in advance of the questionnaire, not scrambling for it. The five steps above are the implementation; the evidence format is the same across all four frameworks.

For a scanner that supports DICOM-format inputs alongside JPEG/PNG, with per-request scan logs formatted for HIPAA and FDA audit trail export, see the healthcare AI prompt injection scanner reference. For the full compliance architecture across the HIPAA Security Rule, HITECH, and FDA SaMD cybersecurity guidance in one document, see HIPAA-compliant AI security and prompt injection. Glyphward's Pro tier ($29/mo) includes per-request scan logs with modality tagging, payload hashing, and webhook delivery for SIEM integration — the complete evidence trail the frameworks above require.

FAQ

Further reading

• HIPAA-compliant AI security and prompt injection — the full compliance architecture: §164.308 administrative safeguards, §164.312 technical safeguards, HITECH breach notification, and the per-modality evidence format for each requirement.
• Healthcare radiology AI prompt injection — the PACS integration attack surface, DICOM-routed adversarial image vectors, and FDA SaMD compliance mapping for radiology AI systems.
• Telehealth and remote patient monitoring AI prompt injection — WhisperInject-class audio attacks against STT-to-LLM pipelines, RPM continuous audio stream vectors, and HIPAA transmission security implications.
• Digital pathology and clinical laboratory AI prompt injection — whole-slide imaging attack surface, CLIA regulatory implications, and ingestion-time versus inference-time scanning placement for pathology RAG systems.
• Clinical trials and pharmaceutical AI prompt injection — FDA 21 CFR Part 11 ALCOA+ data integrity implications and adversarial manipulation of clinical trial AI data summaries.
• Mental health and digital health AI prompt injection — patient safety implications of multimodal injection against conversational mental health AI, and the compliance obligations unique to this high-consequence modality.
• Healthcare AI prompt injection scanner — Glyphward's scanning capabilities for DICOM, audio, and document inputs with per-request HIPAA and FDA audit log export.
• EU AI Act Article 15: the multimodal AI security checklist — the eight-item pre-August 2026 checklist for high-risk AI providers; covers the EU MDR / AI Act overlap for medical device AI.
• Building a prompt-injection scanner for voice agents — the engineering argument for why waveform-side scanning is structurally necessary when STT discards the frequency bands where audio PI lives.
• The multimodal prompt-injection threat model (2026) — the full attack taxonomy across text, image, and audio; FigStep, AgentTypo, WhisperInject, and indirect injection via retrieved context.
• Glyphward pricing — free tier for evaluation; Pro at $29/mo includes per-request scan logs with modality tagging, payload hashing, webhook, and SDK; Team at $99/mo adds SSO, audit log export, and Slack alerts.