Are these five patterns the only shadow AI breach patterns?

No. They are the patterns I see most frequently in regulated environments. Other patterns include credential exfiltration through AI agents that summarize logs, model output reuse without attribution that creates IP exposure, and supply-chain compromise where a third-party model returns malicious output that the deployer's application acts on. The five named here cover the majority of the IBM 2026 dataset by frequency. The architectural causes overlap heavily.

How do we estimate our own exposure to these patterns?

A useful first-pass estimate is to combine three numbers: the percentage of employees using unauthorized AI (Cloud Radix puts the population baseline at 78%), the percentage of those interactions that touch regulated data classes (varies by industry), and the cost-per-incident floor IBM reports. The combination produces an annualized expected loss figure. The figure is approximate, but it generally moves the AI usage program from "we have a policy" to "we have a budgeted control."

What about model providers' enterprise plans - do they remove the breach surface?

They reduce some classes of exposure (data retention, training on customer data) and leave others in place. An enterprise plan with appropriate data handling terms removes the model-provider-side retention concern. It does not remove the deployer's audit and disclosure obligations under EU AI Act Article 12, HIPAA, or sector regulators. The deployer still needs the per-request record. The enterprise plan is a necessary but not sufficient layer.

How does the EU AI Act change the calculus on these patterns?

The August 2, 2026 high-risk obligations require automatic event recording over the lifetime of the system. For deployers running high-risk AI under the Annex III classifications, the breach record-keeping requirement becomes a per-request obligation. A breach that lacks the per-request record is a compounded violation: the breach itself, plus the failure to produce the evidence the regulator requires. The Article 99 penalty tier sits at 15 million EUR or 3% of global turnover.

What is the order of operations to actually close the gap?

The pattern I see work is: define the data classes the organization's regulatory regime cares about, get an AI usage policy approved that names the classes specifically, deploy the enforcement layer at the AI request boundary, validate that the per-request audit records are produced for every sanctioned and unsanctioned path, and then iterate on the policy as new tools and use cases emerge. Most organizations get stuck on step three because the enforcement layer is what produces the evidence steps four and five depend on.

Shadow AI Breach Examples: Five Patterns That Keep Repeating

IBM's 2026 Cost of Data Breach study of 600 breached organizations found that one in five experienced breaches linked to shadow AI. The incremental cost was $670,000 on average. Detection took 247 days, six days longer than the all-breach average. Customer PII exposure jumped to 65% in shadow AI breaches versus 53% across the full population. Netwrix found that 97% of organizations that suffered an AI-related breach lacked proper access controls for AI services.

The breach patterns I see repeat across industries. The five most common patterns share an architectural common cause. The enforcement layer that closes the gap is the same in every case.

I want to walk through the five patterns, the failure mechanism in each, and the architecture that removes the surface.

Pattern 1: Source code into consumer ChatGPT

A senior engineer at a public company pastes a stack trace into ChatGPT to ask for help. The stack trace includes file paths, function names, and a small inline configuration block. Below the trace, the engineer pastes a few hundred lines of the surrounding source for context. The model produces a useful answer.

The data movement here is structural. The HTTPS POST to api.openai.com on the consumer tier sends the prompt to OpenAI's API. Under the consumer terms in effect at the time, the prompt may be retained and may be used for model improvement. The company's IP is now outside the boundary. The legal exposure depends on the IP regime, the customer contracts that reference the code, and the trade-secret status of the algorithms.

The pattern is hard to detect because the engineer authenticated to ChatGPT with a personal account on a personal browser session. The corporate IdP saw nothing. The network DLP saw an encrypted POST to a domain the security team has not specifically inspected. The application logs at the SaaS vendor are at the model provider, not the company.

Samsung's 2023 disclosure was the canonical early version of this pattern. The repeat through 2026 is at scale: every engineer who has the same instinct produces the same data movement.

Pattern 2: PHI in clinical AI workflows

A clinician dictates a SOAP note into a transcription tool, then pastes the resulting text into a consumer AI tool to clean up the structure and suggest billing codes. The note contains the patient identifier, the visit date, the diagnosis, and the treatment plan. Under HIPAA, this is PHI by definition. The consumer AI tool does not have a Business Associate Agreement with the practice. The disclosure is a HIPAA violation.

Cloud Radix put the prevalence of this pattern at 57% of healthcare professionals. The Office for Civil Rights treats the disclosure as a HIPAA violation regardless of intent. The breach notification obligations under HIPAA's breach rule apply if the disclosure rises to that threshold.

The pattern compounds in prior-authorization workflows where the clinician summarizes records to support an appeal. The summary contains PHI from multiple visits. The data moves to the model on a single request. The deployer of the AI workflow is the practice, not the model provider, and the disclosure exposure sits with the practice.

The architectural problem is that the EHR-to-AI data path was never reviewed because the AI was added by the clinician, not by the IT team.

Pattern 3: MNPI through research and analyst workflows

A buy-side analyst at an asset manager is preparing a research note ahead of an earnings release. The analyst has the company's preliminary internal estimates from a meeting with the CFO. The analyst uses an AI tool to summarize the company's last four years of reported figures and asks the tool to assess whether the estimates are consistent with the trend. The estimates are pasted into the prompt.

The estimates are MNPI. The disclosure to an external AI model is a control failure under SEC compliance obligations. Pre-announcement earnings figures pasted into a consumer model is a pattern that produced multiple internal investigations through 2025 and 2026.

The traditional surveillance stack at the asset manager covers email and chat. It does not inspect prompt content sent to AI APIs on the analyst's workstation. The deeper problem is that the firm's AI usage policy may name the consumer ChatGPT as shadow, but the policy is not enforceable at the request layer.

The DORA Article 28 obligations for EU-domiciled asset managers and banks codify the vendor-AI governance requirement starting January 2025. The architecture has to support the per-request evidence.

Pattern 4: Customer PII through embedded SaaS AI features

A customer success manager uses a sanctioned SaaS tool to triage support tickets. The SaaS vendor adds an AI feature in a quarterly release that summarizes tickets across the customer's interactions. The CSM uses the feature. The feature sends ticket content - which includes customer names, email addresses, account identifiers, and sometimes account-specific configuration - to a model the vendor hosts under a downstream contract.

The vendor's processing of the data is covered by the existing SaaS contract, but the new AI feature's data path was not part of the original procurement review. The customer's data has now been processed by an additional sub-processor that the customer's privacy notice may not list. Under GDPR, the controller-processor chain extends to the new processing.

The breach surfaces when a customer asks the support organization for a copy of every place their data has been processed in the previous twelve months. The new sub-processor is not on the list. The disclosure obligation triggers.

This pattern is the one that catches organizations whose shadow AI program was built around the approved-vendor list. The vendor was approved. The new feature was not.

Pattern 5: Prompt injection on agentic workflows

An organization deploys an internal AI agent that reads from a shared document store and can take actions in the ticketing system on behalf of the user. A document in the store, originally produced by an outside party and not sanitized, contains a prompt injection payload. The agent reads the document, the injection alters the agent's behavior, and the agent takes actions in the ticketing system the user did not authorize.

The breach mechanism is that the user authenticated to the agent, the agent authenticated to the model API, the agent had legitimate access to the ticketing system - and the injection altered the action the agent took. The OWASP LLM Top 10 places prompt injection at LLM01 for a reason.

The blast radius depends on the actions the agent is authorized to take. Agents that can email externally, change CRM records, or move money have larger exposure. The agent's permissions, granted through static credentials shared across all of its work, do not narrow when the user's permissions are narrower.

The architectural problem is the post-authentication gap. Authentication answers "who is calling." The injection succeeds because authorization at the action layer does not check what this specific request, against this specific data, is permitted to do.

The architectural common cause

The five patterns share three properties. The data path is at the AI request layer. The legacy DLP, CASB, and surveillance stacks do not inspect that layer with prompt-aware classification. The deployer's audit log does not contain the per-request record the regulator or auditor expects to see.

Identity context is missing at the request layer in patterns 1, 2, and 3. Data classification at prompt level is missing in patterns 1, 2, 3, and 4. Policy enforcement at the action layer is missing in pattern 5. None of the five patterns is a model safety problem. All five are control plane problems at the HTTP AI request boundary.

The 247-day detection time IBM reports is the consequence of the control gap. The detection signals exist only after the data has moved.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits at the AI request boundary as a stateless proxy between users and agents and any LLM. Every request is evaluated against identity, role, prompt-level classification, and policy. The decision is recorded as a per-decision audit record under the deployer's control.

For pattern 1, the source-code class is detected and the request is blocked or redacted before the prompt reaches the consumer API endpoint that is not on the sanctioned list. For pattern 2, the PHI class is detected and the request is routed only to the model with the BAA. For pattern 3, the MNPI class is detected and the request is blocked. For pattern 4, the new AI feature's endpoint is evaluated against the data classification policy regardless of which SaaS wrapper it lives inside. For pattern 5, the agent's per-action requests are evaluated against the user's authorization scope, with the injection-altered action failing the policy check.

The audit record produced by the proxy is the artifact the regulator asks for. The 247-day detection delay shrinks to per-request determination.

If your shadow AI program is producing acknowledged policies and the data is still moving, the gap is at the request layer. Let's talk today.