GenAI Data Loss Prevention

According to 2026 research from Cyberhaven Labs, almost 40% of the data employees send to AI is sensitive, and this number is growing. Besides this, a report from Netskope’s 2026 Cloud and Threat Report indicates that rate of data policy incidents related to Gen AI application usage doubled this year, driven by shadow AI and personal accounts. This is not about attackers, but employees and their daily authorized work processes and interactions with AI tools.

This is why it is so challenging to secure and monitor. Legacy DLP tools were designed to inspect transactions, files, emails, and drives. But with generative AI, sensitive information is gradually shared, revealed, and incorporated into the conversation, for example, when an employee shares a customer record for formatting, a line of code for debugging, or a strategic document summary. Prompt leakage is a conversation, not a transaction, and that is why it is invisible to legacy data loss prevention tools. This blog explores multiple facets of Gen AI data loss prevention and how to build a Gen AI DLP program.

Why Legacy DLP Fails Against Gen AI

Each iteration of data loss prevention was developed to answer a similar question: is this particular file, message, or transfer authorized for egress? This framing of the problem implicitly accepts that data loss takes forms familiar to us from transactions: something with a beginning and an end that can be opened, read, hashed, or pattern-matched. Gen AI fundamentally challenges that assumption, and the points below highlight the reasons.

Conversational Leakage vs Transactional Leakage

A traditional DLP tooling views data loss events as transactions: an email message with an attachment, a file uploaded to a cloud drive, or a document copied onto a USB all represent some discrete data transfer with definable start and end boundaries. Any of these can be scanned or inspected by a policy engine to identify regulated data types at the moment of egress.

Prompt-based data leakage usually takes place within the body of a conversation and does not have clearly visible transaction boundaries. A user may copy a customer’s name in one message, the customer’s account details in another, and ask for a risk summary in the third. None of these messages individually contain fully formed records, but taken together they represent a data exfiltration event. A conversational prompt presents a challenge to a traditional DLP tool because it lacks clearly definable data transfer boundaries: the regulated data is not contained within any particular message, but is distributed across the conversation.

Why Regex Rules and Static Inspection Points Fail

DLP legacy solutions use regular expressions to define rules for protecting data of a certain type (e.g., Social Security Numbers), specific to a certain organization (e.g., a list of keywords for plagiarism check), or related to particular types of intellectual property (e.g., credit card API keys). This approach has proven effective wherever the target data is relatively structured. But fails against natural language prompts and their unstructured nature.

There are several reasons why a prompt-based attack cannot be caught by a regex rule:

• The value can be embedded in a natural language message in a form that is not recognized by a regex pattern.

• Even when there is a particular value or a pattern that is recognized, its sensitivity may depend on the type of data it appears with.

• Traditional DLP solutions operate on choke points, inspecting the data at specific places within the infrastructure (email relays, network gateways, etc.). GenAI traffic, on the other hand, is processed within a browser tab or a copilot window, and has to be intercepted at the application layer. Moreover, many generative AI applications operate on domains that are not controlled by the enterprise.

• New applications and websites that embed GenAI are created constantly, sometimes with the ability to use AI features turned on by default.

In general, traditional DLP tools inspect data structures, while the risky data is embedded in natural language conversations. Controlling access to conversations requires a different approach to data security.

What Real GenAI DLP Actually Requires

If the issue is conversational leakage, a better regex library isn't the solution. Effective GenAI DLP requires operating at the level of conversation itself, addressing the risk at the point of conversation and intent, not after the fact. This has important implications for what the solution actually needs to do. You don't need just one of these things; you need all of them.

Visibility, Enforcement, Remediation

Visibility is usually the easiest place to start with any program meant to reduce risk. When it comes to Gen AI, this often takes the form of logs indicating what tools employees are using and what they're asking for. Without visibility, you can't enforce policies. But visibility-only solutions only tell you about conversations that have already happened - they can't stop a single conversation from leaking data.

The truth is that you need to think in terms of a three-part security program:

• Visibility: processes and tools that allow you to understand the ecosystem of Gen AI tools in your environment, including unlicensed "shadow" implementations, and the types of data that can pass through them.

• Enforcement: policies that act at the moment of conversation to prevent data exfiltration attempts, ideally inspecting the contents of actual prompts as opposed to simply logging conversations for later analysis.

• Remediation: rules that modify the conversation or notify users when a policy is triggered, and update policies based on observed patterns in conversation.

A visibility-enforcement-remediation security stack provides value at all stages - it can detect conversations which may contain sensitive information, stop them from being sent to third-party models, and collect information about what triggered the interaction for later analysis. If you have visibility but can't enforce your policies, you're simply generating reports about conversations which will still occur. In contrast, a solution that can enforce policies but isn't collecting data about incidents can't update itself or improve its effectiveness over time.

The Dividing Line: Detection vs. Remediation

As vendors mature, a clear distinction is emerging in what DLP vendors offer for coverage of generative artificial intelligence (GenAI). Most vendors can detect prompt content types, classify regulated information, and alert on such findings. However, the ability to detect prompt content does not directly prevent data loss since the alert only occurs after the prompt has passed through the model. The dividing line in 2026 between Gen AI vendors is the ability to remediate the detected prompt before it has left the company’s control. The critical difference between Gen AI security offerings is remediation, which manifests in the following areas:

• Prompt blocking in real-time versus alerts that occur after the prompt has been processed: Is the user’s request blocked immediately, or is the user only notified once an interaction has already taken place?

• User-level coaching versus user-level logging and security review: Does the user who submitted the prompt receive guidance on why their submission was rejected, or is the incident only logged and reviewed?

• Policy learning versus static policy: Does the blocked content inform future policies, or must policies be manually updated?

Currently, buyers of Gen AI DLP solutions are focused on how the vendor offering differentiates between detection and remediation. This trend highlights the shift in focus from alerting on risks to stopping data loss at the moment of prompt submission.

Core GenAI DLP Techniques

The concepts of visibility, enforcement, and remediation are abstract; the underlying technology that gives them form and shape consists of concrete measures. The four techniques below touch on different points in the processing chain. One thing they have in common is that a comprehensive GenAI DLP strategy will employ multiple techniques rather than rely on one particular approach.

Redaction

Redaction makes unauthorized data inaccessible to the model by removing it from prompts before they’re processed. Instead of denying access to the entire prompt, redaction allows the prompt to reach the model, but with sensitive data parts removed. This way, the model returns a result based on the processed request in which the PII or proprietary information has been removed or replaced with tokens.

Redaction is beneficial because it enables the user to get the response they expect while protecting sensitive data. For instance, if an employee asked the GenAI model to summarize a customer complaint, the result would still be useful to the employee even if the customer’s personal information had been redacted. The downside of the technique is that it requires natural language learning to identify and remove sensitive data, which can be challenging in some cases.

Masking and Tokenization

Masking and tokenization differ from the preceding methods in that they operate on the premise of substituting sensitive information with a different value prior to prompt sending, and subsequently swapping it back upon response receiving.

An example of such data treatment is hashing an actual customer ID to a universal value applicable to all customers, subsequently unhashing it by the model upon receiving a response. In this manner, a model can be trained to reason about “this customer” with the same hash value always referring to “this particular customer” without actually passing any sensitive data to the model. Such a scheme can be especially useful when a model needs to be trained to reason about the same entity several times during the same conversation turn, wherein the value would have to be continuously redacted and unsubstituted if simple masking was used.

Browser Isolation

Browser isolation moves the control point from the content layer to the access layer. That is, instead of controlling what a user inputs into whatever Gen AI app they’re using, it controls the ways in which they can reach that Gen AI application. The latter tends to be much more restrictive – and much more focused on keeping the user safe, rather than inspecting every character they type.

This is particularly valuable for shadow AI - users accessing unauthorized GenAI applications, typically on their own accounts, where the company cannot control or observe what data goes in or out. With isolated browsing, the company can control access to such apps - for example, denying pasting into them, uploading files into them, or other potentially sensitive operations. This is both a security measure and a means of enforcing compliance, and it works for all GenAI apps that the company isn’t directly hosting or controlling, which is most of them.

The GenAI Proxy/Gateway Pattern

The proxy or gateway pattern consists of routing all GenAI traffic through an inspection point that is controlled by the organization in order to enforce a policy. This inspection point takes the form of a single proxy gateway, which is placed between the user and all Gen AI applications in use. By using this pattern, organizations can ensure that there is a uniform policy applied to all traffic to the selected Gen AI applications, and that the organization has visibility of any prompts, uploads, or responses.

It is here that the difference between detection and remediation begins to become apparent. Because the gateway is in the path of the traffic, it can perform real-time processing of the prompts such as redacting or tokenizing restricted information, or refusing the prompt based on its contents, before the request is passed on to the Gen AI application. In short, a gateway provides a mechanism by which a prompt can be changed in real-time as it is being processed, which is a critical difference between this kind of network layer processing and any other type of inspection.

When combined with browser isolation, the proxy/gateway pattern creates a complete inspection environment that allows an organization to prevent data exfiltration from occurring. Both patterns work together to define what can and cannot be inspected, and once the content of a request has been inspected, the information can be removed or tokenized to prevent exfiltration. Neither of the patterns alone would be sufficient to achieve the same degree of prevention that they enable when used together.

Why Unified Discovery is Outperforming Fragmented Tools

The methods described above have one major flaw: all of them presuppose that the organization knows and understands precisely what constitutes sensitive and where this data is stored. And this fundamental assumption turns out to be a critical vulnerability for many organizations, which is why DSPM and DLP are being combined into a unified solution rather than being separate.

Fragmented tools create a discovery gap

DLP focuses on data-in-motion, examining prompts and transfers, and DSPM focuses on data-at-rest, scanning repositories and clouds for sensitive information. By operating independently, DLP ends up protecting data it never knew was sensitive, and DSPM can discover a sensitive data repository but has no way to prevent that data from being pasted into a prompt.

Close the gap by unifying classification

If your discovery and enforcement processes share a common classification foundation, then a sensitivity label identified by DSPM can immediately be leveraged by DLP at the point of prompt-submission; you only have to manage one definition of sensitivity, not two.

Consolidated tools solve a coverage challenge specific to Gen AI

Traditional, manually authored DLP rules simply cannot scale to the rate at which new data repositories and GenAI tools are introduced. Through continuous rediscovery and reclassification, a unified approach to data security enables policies to dynamically update as the environment changes, rather than requiring scarce security resources to constantly update and maintain static rules.

Fewer blind spots and false negatives: fragmented solutions often fail silently

A repository containing sensitive data goes undiscovered, or a DLP policy is configured but fails to account for the vector by which it will be accessed. With a consolidated approach to data discovery and protection, new repositories are immediately protected from being exposed through Gen AI, reducing the risk that a blind spot will appear in your security posture.

How to Build a GenAI DLP Program

Technical measures are not sufficient for a GenAI DLP program, since there's also the requirement to dictate and formally enforce a policy for the responsible use of GenAI in the first place. An effective program requires both: technical measures to enforce the policy as well as a documented policy to which users are formally expected to adhere.

Start with discovery, not enforcement

Before any policy can be written, the organization must develop a comprehensive list of all available Gen AI tools in its systems, including those not officially sanctioned but in use via personal accounts, which requires visibility into activity beyond just the enterprise software layer. In addition, the data being used in these tools also requires classification to understand how much regulated personal data, source code, or other sensitive information is being processed. This step is critical because it grounds policy decisions and enforcement measures in actual risk rather than assumptions. Discovery must come before enforcement.

Deploy technical controls for enforcement at the point of risk.

Enforcement should occur at the point of entry by using a gateway or proxy mechanism that allows organizations to inspect prompts before they are sent to a third-party Gen AI system, and then either redact or tokenize sensitive information so that it cannot be used during model training. For the long tail of tools that lack enterprise-grade integration, browser isolation can provide an additional layer of control. These measures also need to tie back to the same DSPM infrastructure that classifies data, since tools and data both change dynamically, and the policy needs to update automatically for both, rather than having policies that must be manually updated each time a new tool appears on the network or a new type of data is discovered.

Publish an AUP with specificity

An Acceptable Use Policy (AUP) should clearly define which tools are approved for use and which are not, noting that personal or shadow AI deployment is outside the scope of the organization's ability to audit or protect. In addition, a policy should specify which categories of data are prohibited for use within a Gen AI model, using examples that employees are likely to recognize rather than vague language regarding "regulated personal information" or "proprietary data." An effective AUP also clarifies the responsibilities of individuals and teams, including who can approve the use of a specific Gen AI tool or model and who is responsible for responding to violations.

Make policy decisions at the moment of action

A policy that only takes effect when an employee prints a manual document is far less effective than one that stops a high-risk action before it occurs. This is why it is important to make policy decisions at the point of action by providing contextual guidance when a request is blocked. This could take many forms, but the most common is a short explanation of why a particular request failed and how an employee might avoid it in the future. Similarly, repeated or high-risk violations should result in escalation to a human rather than being automatically logged and forgotten.

Treat the program as continuous

Gen AI programs have much shorter product cycles than most enterprise software, meaning that the tools and use cases defined six months ago are likely to have changed significantly by now. It is important to regularly revisit and update an organization's understanding of its toolset and data classification, treating this maintenance as an ongoing aspect of a Gen AI DLP program rather than a task done once at the beginning. As technical enforcement rules and remediation processes are updated, these changes should feed back into the AUP, which should also be treated as a continuous process rather than a static document.

At their best, DLP programs for generative AI operate at the intersection of technical enforcement and policy, with the two informing and supporting each other. The policy provides a baseline standard of behavior, while technical tools serve to enforce these principles at the moment of action.

Secure and Govern your GenAI Agent Stack with Akto

Akto focuses on the risks associated with everyday authorized user behavior that accidentally leaves data exposed. Developers give Codex access to private repositories, salespeople summarize pipeline information in ChatGPT, lawyers redline contracts in an AI application, all without actually interacting with the security layer. Over 71.2% of data exposure incidents involving GenAI come from ChatGPT, 77% of employees paste information into AI applications, and 82% of workers use non-corporate accounts, which are vulnerable to data extraction.

1. Discovery – Identifying all AI touchpoints

It is necessary to determine where data can be lost to protect it. Akto highlights all the places where AI applications can be used: browsers with ChatGPT, Codex on endpoints, and personal accounts on corporate devices. MCP servers, agents, and “skills” that carry out various functions are subject to checks as well. In addition, all traffic is examined to identify malicious MCP servers and “skills.” A priority level is assigned to each discovered violator. The findings are consolidated in a unified inventory, which includes all the AI-related objects found: agents, MCP servers, skills, and personal accounts, along with the number of interactions and violations.

2. Enforce – Applying data safety guardrails

The DLP engine enforces security policies in real-time to prevent data exfiltration. Akto offers several built-in AI data loss prevention guardrails for the most common use cases and suggests applying them consistently across the board:

• PII filtering with customizable policies that specify which PII to mask and how (OWASP ASI03 standard)

• Secret detection to stop the injection of API keys and other secrets when using AI applications (OWASP ASI03 standard)

• Detection of proprietary source code

• Restrictions based on roles and teams that define what data can be sent to particular models

In addition, various policies can be used to protect data during model training: encryption, tokenization, masking, or deletion of sensitive fields. All policies can be set up as rules for different AI service accounts.

3. Compliance – Mapping to relevant frameworks

All chatbot activity, policy enforcement actions, data classification, and data labeling actions are mapped to the relevant standards: NIST AI RMF, ISO 42001, SOC 2, GDPR, and HIPAA.

Akto highlights organizational posture trends in terms of discovery, policy enforcement, data exposure, and compliance with a breakdown of findings by agents, MCP servers, LLMs, and skills. The number of critical/high/medium/low violations helps determine whether there are any critical security posture issues currently.

Final Thoughts on GenAI DLP

GenAI data loss is no longer a hypothetical possibility - it is an urgent production concern that traditional DLP is not equipped to handle. Protection requires visibility, enforcement, and ongoing testing of both employee and organization-developed applications and models.

Akto helps organizations discover, test, and secure homegrown GenAI applications and LLM APIs against data exfiltration and prompt injection attacks. Book a GenAI Security demo to secure your GenAI investments.

FAQs on GenAI Data Loss Prevention

1. What is GenAI data loss prevention, and how is it different from traditional DLP?

GenAI DLP focuses on protecting data from exfiltration through prompts, uploads, and the resulting model output – areas that traditional DLP was not built to address. While legacy DLP inspects files and metadata, GenAI DLP acts inside the conversation to analyze natural language in real-world context before it leaves an enterprise for a third-party model.

2. Why doesn’t legacy, regex-based DLP detect GenAI prompt leakage?

Regex works on structured data – phone numbers, social security numbers, etc. – but GenAI prompts are unstructured natural language. An employee can describe or rephrase sensitive data without using any regex patterns. Legacy DLP tools are also placed on network choke points – but GenAI is used directly inside browser tabs, which never go through those inspection points.

3. What is “conversational” data leakage?

“Conversational” refers to the fact that data exfiltration happens as part of a larger, multi-turn conversation rather than being isolated or easily identifiable as a discrete event. Sensitive information could appear across several prompts that individually don’t appear to contain regulated data but collectively represent an entire regulated record when sent to a model.

4. What’s the difference between detection and remediation in GenAI DLP tools?

Detection refers to identifying and categorizing a sensitive prompt – and is typically accomplished through alerts. Remediation refers to modifying or eliminating the prompt before it reaches the model. Detection is table stakes, but the ability to perform remediation is what differentiates a monitoring tool from a true governance solution. In 2026, tools that can’t remediate are not fit for purpose.

5. What are the core techniques used in Gen AI DLP (redaction, masking, tokenization)?

Redaction works by removing any sensitive elements from a prompt before it reaches the model. Masking and tokenization obscure sensitive strings by substituting them for dummy values in the prompt but reverse the substitution when returning the response. All are used in conjunction with browser isolation and gateway inspection to provide comprehensive GenAI security.

6. What is a GenAI proxy or gateway, and how does it work?

A GenAI gateway is a security tool that acts as a man-in-the-middle for all traffic to and from GenAI applications. Because it possesses the encryption keys for all traffic, it can inspect the contents of a prompt and modify or eliminate any information that should not be sent to an external model.

7. What is MCP DLP, and why is it such a hot topic?

MCP (Model Context Protocol) DLP works with model agents to protect data inside tool calls from exfiltration. Traditional DLP is concerned with data that a user actively sends to a model, but agents can access databases, files, and other content without requiring direct input from an employee. There are no built-in protections for data that appears in response to an agentic tool call, and it represents a significant security risk. MCP DLP is a hot topic in 2026 because it plugs a critical security gap as enterprises move to adopt more agentic applications.