Traditional DLP was built for a threat model centered on known egress channels: email attachments, USB drives, cloud storage uploads, clipboard events, print jobs. The detection engine asks a clear question, "is a file or a block of text leaving through this channel?", and applies pattern matching or fingerprinting to what is in transit. This model has significant coverage gaps for how data moves through generative AI tools, and understanding why requires going back to what the transport layer actually looks like.
The Transport Mechanism That DLP Did Not Model
When an employee types a prompt into ChatGPT and presses enter, the browser sends an HTTPS POST request to chat.openai.com/backend-api/conversation. The request body is a JSON payload containing the prompt text, conversation history, and model parameters. It looks indistinguishable from any other HTTPS application traffic to a network-layer inspection tool that is not doing deep content inspection of POST bodies to that specific endpoint.
Legacy network DLP typically inspects outbound email (via SMTP or the Exchange transport rule layer), file uploads to cloud storage (via inline proxy or CASB), and clipboard events (via endpoint agent). None of those inspection surfaces sees the content of an HTTPS POST body to a third-party web application, unless the security stack has explicit configuration to do deep HTTPS inspection on that destination domain, which most environments do not deploy because it breaks certificate pinning in many applications and generates TLS decryption overhead across all HTTPS traffic.
The result is a structural blind spot: employees can paste any volume of sensitive material into a public AI tool's prompt box, and the exfiltration event registers in network logs only as an HTTPS request to a known SaaS domain. The content is invisible to the tools that were built to find it.
Five Vectors That Bypassed Your Existing Controls
Direct browser prompt input. The primary vector. Employee opens chatgpt.com, claude.ai, or gemini.google.com in Chrome, types or pastes a prompt containing sensitive content, and submits. The content travels in an encrypted POST body. No file was created. No clipboard operation was logged. No email was sent. The user's browser history shows a visit to a known AI domain. Legacy DLP has zero insight into what was typed.
IDE-integrated code assistant context windows. GitHub Copilot, Cursor, and similar tools send context to the model automatically, often including surrounding code, imported module paths, and variable name spaces that the developer did not explicitly select. The developer may never see what was sent in the context window. From the endpoint agent's perspective, no clipboard copy occurred and no file was written to an upload directory. The data movement happened inside the IDE's network calls.
Browser extension AI assistants. A browser extension with "read and change all your data on the websites you visit" permissions can capture page content and send it to an AI API on behalf of the user. These extensions often operate on DOM-level data that email DLP, endpoint clipboard agents, and CASB tools never process. An extension that reads a CRM record and sends it to GPT-4 as part of a "summarize this for me" feature creates no file, no email, and no cloud storage event. It creates an HTTPS API call.
API key holders sending data programmatically. Developers and data analysts with personal API keys to OpenAI, Anthropic, or Cohere can send POST requests directly from scripts, notebooks, or local applications. No browser UI, no clipboard event. The content travels as an HTTP request body from the employee's machine. Your CASB sees traffic to api.openai.com and may flag the volume, but the content is inside TLS.
Custom GPT and agent workflows. Employees building custom GPT configurations in ChatGPT Enterprise, or using tools like n8n, Zapier AI steps, or Make.com AI nodes, can construct workflows that pull data from connected SaaS tools (CRM, ticketing system, Google Drive) and feed it to an AI model automatically. These workflows can run on a schedule or in response to triggers. The data movement is systematic and ongoing, not a one-time paste. From a DLP perspective, the trigger is an API call between SaaS platforms, which looks like normal application integration traffic.
Why the Pattern-Matching Model Breaks Down
Even for security teams that attempt HTTPS deep inspection, the pattern-matching approach that worked well for email and file DLP runs into a different problem with AI prompts: the data is often semantically sensitive without matching a known pattern.
An API key has a recognizable format. A credit card number has a Luhn-verifiable structure. These are the easy cases for regex-based detection. The harder case is an employee who pastes a customer support ticket that contains a customer's name, their account ID, the issue they are having, and some internal notes about the account status. None of that individually triggers a credit card pattern or an SSN regex. But it is clearly customer data that should not be sent to a public AI inference endpoint.
The threat model for AI prompt exfiltration is not primarily "employee accidentally includes a credit card number." It is "employee routinely sends customer context, deal details, or internal strategy information to AI tools as part of their workflow, and nobody has visibility into this." The volume of semantically sensitive but pattern-free content in the average prompt stream is the core risk, and it is exactly what pattern-matching DLP cannot address.
The Control Points That Actually Help
We are not arguing that existing DLP investments have no value. Email DLP still catches a significant volume of incidents. CASB tools that categorize SaaS application traffic can at least surface AI tool usage rates and user volume baselines. Endpoint agents can restrict which applications can access clipboard content. These controls add friction and visibility that is not worthless.
The honest position is: these controls address a different threat surface than AI prompt exfiltration, and adding them up does not close the prompt-layer gap. The gap requires a control point at the prompt layer itself, one that sees the content before it is encrypted into an HTTPS POST body and sent to an AI endpoint.
The control architecture that addresses this is inline prompt inspection at the browser layer, operating before the network call is made. A browser extension with the appropriate permissions can read the prompt content in the input field, classify it against a policy, and act on it (block, redact, or log) before the submission reaches the AI tool's API. This is the same layer where the data is visible in plaintext, before TLS wraps it and it disappears from network inspection.
A concrete scenario: an account manager at a 180-person B2B software company is using ChatGPT to draft a renewal proposal. She pastes a customer's contract terms, ARR figures, and some internal notes about the account's likelihood to churn. All of that goes into the prompt. Email DLP would not fire. No file was uploaded. The CASB sees a request to chatgpt.com. An inline prompt inspection layer sees the contract language and the revenue figures, classifies them as internal financial data and customer record context, and either blocks the submission or logs the event with content category tags for the SIEM.
That gap between what legacy DLP sees and what inline prompt inspection sees is the core problem we built Unbound to close. The threat model evolved when AI tools became mainstream work tools. The security stack did not evolve at the same pace. That is not a criticism of the teams that built and maintain these stacks. It is an observation about how quickly the threat surface moved, and what the practical coverage gap looks like today.