The Shadow AI Data Pipeline Your Security Team Hasn't Mapped Yet

Every organisation running a security programme has a mental model of where sensitive data lives and how it moves. That model almost certainly does not account for the dozens of generative AI services your employees started using in the last eighteen months. The risk is not theoretical future misuse. It is an active, unmonitored data pipeline operating right now, and the architectural response it requires is meaningfully different from updating an acceptable-use policy.

Companion piece to our broader work on ungoverned AI adoption. See Shadow Agents: AI Risk & Enterprise Governance for a deeper look at how shadow AI agents mirror shadow IT risk patterns and what controls CTOs need to govern agentic automation.

The Prompt Is the Data Transfer

When an employee pastes a customer contract into a public LLM interface to get a summary, they have transmitted that document to a third-party inference endpoint. The fact that no file was "uploaded" in the traditional sense does not change the data residency outcome. The prompt is the payload, and in most mid-market environments it crosses the network boundary with no inspection, no logging, and no classification applied.

This matters architecturally because conventional DLP tooling was designed around file transfer and email egress. It looks for structured data patterns moving in recognisable formats. A paragraph of unstructured text containing a client name, a contract value, and a renewal date will pass through most DLP rules without triggering anything, even though the informational content is equivalent to a spreadsheet export.

The volume compounds the exposure. Employees are not making one or two requests per day. Productivity-oriented use of LLMs frequently involves dozens of interactions per session, each carrying fragments of internal context that individually look innocuous but collectively reconstruct sensitive business information.

How the Exfiltration Architecture Actually Works

Browser-Based Prompt Interception

The most common path is direct browser access to a public LLM service. Traffic is TLS-encrypted to the endpoint, which means network-layer inspection cannot read the payload without SSL/TLS termination infrastructure in place. Without a forward proxy configured to decrypt and inspect HTTPS traffic to AI service domains, the content of every prompt is invisible to your security stack.

Even where SSL inspection is deployed, the inspection policy needs to be tuned specifically for generative AI endpoints. A generic HTTPS inspection rule will generate too much noise across all traffic. The operationally useful configuration targets the specific API and web domains of the LLM services your employees are actually using.

File and Document Upload Paths

Most major LLM interfaces now accept direct file uploads. A user can drag a PDF, a spreadsheet, or a code file into a chat window, and the service will process it as context. This creates a distinct exfiltration vector that sits outside the prompt interception problem entirely.

File upload paths are often easier to control at the network layer because they involve recognisable multipart HTTP requests to known endpoints. The challenge is that the list of endpoints changes as new services emerge, and mid-market security teams rarely have the capacity to maintain that list in near-real-time. Relying on a static blocklist is a losing position.

OWASP LLM Top 10 as a Detection Framework

The OWASP Top 10 for Large Language Model Applications provides a structured vocabulary for categorising the threats that ungoverned AI tool use introduces. Two categories are directly relevant to the data pipeline problem: sensitive information disclosure and insecure output handling.

Sensitive information disclosure in this context refers to the risk that data included in prompts is retained, used for model training, or exposed through another user's interaction with the same service. The practical control response is to treat every external LLM endpoint as an untrusted third party, applying the same data handling constraints you would apply before sending information to any external SaaS vendor.

Insecure output handling is the less-discussed risk on the inbound side. When employees paste LLM-generated content back into internal systems, including code into repositories or summaries into CRM records, they may be introducing content that was influenced by prompt injection from other inputs the model processed. This is not a hypothetical attack surface in 2026.

The Mid-Market Governance Gap

Enterprise organisations with mature security programmes can deploy purpose-built AI gateway products that sit between employees and external LLM services, applying classification, redaction, and policy enforcement at the request level. These tools exist, they work, and they are priced and operationally sized for teams with dedicated security engineering capacity.

Mid-market organisations typically have neither the budget nor the staffing to operate that class of tooling. The result is a governance gap that cannot be closed by policy alone. An acceptable-use policy tells employees what they should not do. It does not create any technical control that prevents them from doing it, and it does not generate the audit log you would need to detect a violation or respond to a breach notification.

The architectural minimum that is actually achievable at mid-market scale involves three components: TLS inspection on a defined set of AI service domains, a forward proxy with logging enabled for those domains, and a classification layer applied to outbound content before it reaches the proxy. None of these require enterprise-grade tooling. All of them require deliberate configuration and someone accountable for maintaining them.

Building Enforceable Controls Without Enterprise Tooling

Define the Service Inventory First

You cannot enforce policy against services you have not identified. The starting point is a DNS and proxy log review to enumerate which AI services are already in active use. This exercise consistently surfaces services that security and IT leadership were unaware of, because employees adopt tools through personal accounts and browser extensions that bypass corporate procurement entirely.

Once the inventory exists, services can be tiered by risk: public consumer interfaces with no enterprise data agreements sit in a different category from enterprise-licensed services with contractual data processing terms. The tiering informs the enforcement posture for each domain class.

Proxy Configuration and Logging as the Control Layer

A forward proxy with SSL/TLS inspection enabled for AI service domains is the foundational technical control. It creates the inspection point, the audit log, and the enforcement surface for content-based rules. Without it, every other control is advisory.

Logging at this layer should capture request metadata, destination domain, authenticated user identity, and content size at minimum. Full content logging raises its own data handling questions and may conflict with employee privacy obligations depending on jurisdiction. The right configuration for your organisation depends on your legal context, but the logging architecture needs to be designed before an incident occurs, not reconstructed afterward.

Policy Enforcement at the Request Level

Content-based rules applied at the proxy can block or flag requests containing patterns associated with sensitive data classifications. This is not a replacement for a mature DLP programme, but it is a meaningful control layer that mid-market organisations can implement without specialised AI security tooling.

The rule set should be treated as a living configuration. New data classification patterns, new AI service domains, and new upload mechanisms will require ongoing updates. Assigning clear ownership of that maintenance function is as important as the initial configuration.