I have a confession. When my team proposed hosting an executive boardroom at the Gartner Cybersecurity & Risk Management Summit on data loss protection, I had my doubts about attendance. As a tech category, DLP doesn’t give CISOs the warm fuzzies.
But every seat was taken. We even had to turn people away at the door.
That’s because security leaders came to talk about something bigger. Within just a few years, employees across every department have started feeding sensitive company data into AI, and the so-called “DLP solutions” companies have now are useless. CISOs need better answers for data security. Not tomorrow – now.
Thanks to everyone who joined us in the executive boardroom. Here are six takeaways from the event.
DLP PTSD Is Real
The feeling was unanimous: the old DLP playbook based on regex-based policies has failed. It catches too many false positives or miss real threats entirely, and someone has to sort through the wreckage. Security teams are spending money and burning hours and still losing data.
My co-host for the session was Matthew Mudry, CISO at Alera Group, and he has lived this. At one point he had a small army focused on sorting real alerts from false ones. Credit card numbers flagged as contract numbers, and PHI flags on everything. A universal experience for CISOs that’s given DLP a bad reputation and maybe even triggered a few anxiety nightmares.
Matthew called it “DLP PTSD.” We’ve all been there.
Nitay Milner , ORION Security Co-Founder and CEO, and Matthew Mudry, CISO at Alera Group, discuss a new model for data loss protection.
AI Has Changed the Risk Math
ChatGPT, Claude, Claude Code, and Gemini are running directly on endpoints, with more employees using these desktop and browser apps every day, often with extremely sensitive data. Tools like Cursor let non-technical employees build unauthorized apps that connect directly to internal data sources, without security ever knowing they exist.The surface area is orders of magnitude larger than it was three years ago. Writing more policies is not a response to that and it doesn’t scale.
The only way to keep up with AI-driven exposure is with AI-driven detection. You can’t fight this with more analysts and policies. The answer for data security in today’s world is agentic technology that understands context, learns what normal looks like, and flags what doesn’t fit.
CISOs Need Data Movement Visibility
Matthew’s approach at Alera inverted the conventional playbook. Instead of starting with data classification, the two-year DSPM scan, the labeling project, the policy architecture, he started with a simpler question: where is data actually going right now?
Not long after deploying ORION Security agents, his team had answers. And the other thing he said that was interesting: once he had clean, accurate data, the conversation with his board changed completely. He could show them exactly what was leaving and where. That is what a DLP resetlooks like.
Pre-Classification Delays Protection
Someone in the room asked about Matthew’s choice to not pre-classify data before deploying ORION. His answer was direct: he’s not against classification. He’s against it being the thing that has to happen before you can protect anything.
ORION classifies data in motion, and those detections feed back into compliance and labeling workflows. Protection doesn’t have to wait.
This matters especially now, when AI tools are creating exposure faster than any labeling project can move.
The only way to keep up with AI-driven exposure is with AI-driven detection.
Fragmented DLP Means Fragmented Signal
Most enterprise data loss protection programs aren’t one program. They’re three or four point solutions covering different surfaces: endpoint, email, network, AI, SaaS apps, etc. Each with its own policies and alert queue.
The problem is data doesn’t respect those boundaries. When you look at email, endpoint, AI channels, and SaaS together, you see a completely different story than when you look at each in isolation.
Context is everything. A file download that looks routine on its own looks very different when you can see it was then zipped, renamed, and uploaded somewhere else. That full trace only exists if you are looking at all of it at once. Fragmented signal means more noise, missed incidents, and tuning cycles, which is exactly the failure mode everyone in that room has lived.
Data Security Done Right Gets Everyone in Sync
One of the more interesting moments in the session came when Matthew described how his security team had built a shared workspace with HR. When a relevant HR situation arises, HR flags it in the system. When ORION detects unusual data movement patterns, the security team flags it back. Both sides are working from the same context.
It sounds simple, but almost no one is doing that. Most security teams are either monitoring everyone equally or waiting for an incident before they escalate. The HR partnership lets security focus attention where the risk is actually elevated, not because anyone is assumed to be doing something wrong, but because context-aware protection is more accurate than blanket coverage.
It also shifts the security-HR relationship from reactive to collaborative. And when the two teams are in sync, response time improves.
The Conversation Is Just Starting
We’re at a moment where the traditional DLP approach has failed, and a new playbook is being written.
I co-hosted the executive boardroom not knowing if we’d have good attendance. DLP doesn’t exactly have a fan club. But the room was full because the data protection problem is real and getting harder, and security leaders know it.
What stood out was how much everyone agreed on: AI has made this urgent, and they needed answers to this problem yesterday.
If you were in that room, or find this conversation interesting, I’d genuinely like to hear how you are thinking about this. What’s working? What’s still broken? Is that checkbox we all knew as a “DLP tool” even relevant in today’s world? That discussion was the best 45 minutes of the conference for me, and I don’t think we got close to finishing it.
DLP for Claude stops confidential data, source code, regulated records, and case files from leaving in a prompt or upload before it reaches Anthropic.
Claude is built for long-form, high-trust work, so the data people put into it tends to be among the most sensitive in the company.
Anthropic’s Claude Compliance API gives security teams real visibility into Claude Enterprise activity. It reports what happened. It doesn’t stop a paste at the moment it happens.
ORION Security covers Claude as a browser tab, a desktop app, and Claude Code; deploys in 30 minutes; and reads intent and context to allow, stop, or coach in real time. One customer runs the whole program with one person, less than two hours a day.
Enterprise teams want to run on Claude. Lawyers draft with it, analysts summarize hundred-page filings with it, engineers review code with it through Claude Code. For a CISO, whether to allow Claude use is already settled. The open question is how to let people use it while preventing sensitive data loss. ORION Security was built for that question, and this guide covers it for Claude.
What Is DLP for Claude?
DLP for Claude is a set of controls that stop confidential company data from leaving in a Claude prompt or upload. It watches what a person is about to send, at the browser or the endpoint, decides whether the content is safe to share, and stops or coaches the user before the text reaches Anthropic’s servers. Teams keep working, and the data stays in.
The distinction that matters is where the work happens. Old data loss prevention guarded the exits: the file transfer, email gateway, USB port. Claude is a conversation in a browser tab and a coding assistant in a developer’s terminal. Stopping a leak there means catching the action while the data is still in the room.
Why Claude Is a Distinct Data-Loss Risk
Claude carries a different risk profile from other AI tools because of what people use it for. Its long context window invites whole documents, full contracts, complete case files, and entire codebases. The work skews toward law, healthcare, finance, and engineering. The data going in is bigger, and it’s more sensitive.
A salesperson summarizing a deck is one kind of exposure. A lawyer pasting a privileged settlement agreement, an analyst dropping in a quarter of regulated financials, an engineer running Claude Code against a private repository: these are large data transfers and hard to undo. One ORION Security customer, a U.S. mortgage servicer, had engineers using Claude Code with no view into data sharing in those sessions. Claude earns trust on hard work, and that raises the stakes for data loss.
The 5 Ways Enterprise Data Leaks Through Claude
Enterprise data leaves through Claude in a handful of repeatable ways, and almost none of them are malicious. Someone pastes a full document for analysis. An engineer runs Claude Code against a repository that holds secrets. A regulated record goes in for summarizing. A strategy file goes in for redrafting. An employee opens a personal Claude account the company never sanctioned.
Typical scenarios include the long-document paste, where a whole contract or case file goes in for review; Claude Code against private repositories, where source and embedded secrets travel together; regulated records, where PHI or financial data goes in to be summarized; deal and strategy documents, where unreleased material goes in for redrafting; and the personal account, where someone uses free Claude on company work. Each one is an employee moving fast, with no control watching the surface.
Does Claude Have DLP Built In? The Compliance API, and What It Doesn’t Do
Claude Enterprise includes real governance. In May 2026 Anthropic shipped the Claude Compliance API, which routes Claude conversation content and activity events into existing security tools through 28 partners, among them Microsoft Purview, Forcepoint, Netskope, and Varonis. Security teams get Claude activity in the dashboards they already run. That’s genuine visibility, and it matters.
The Compliance API reports on data that’s already reached Claude. It’s a governance and monitoring feed, read after the fact, and it covers Claude Enterprise. The employee on Claude Team or a free account sits on consumer terms, where inputs can train the model by default, so the most casual use is the least covered. Prevention has to happen earlier, at the surface where the paste occurs, in the moment before the data leaves.
Swipe to see the full table →
Capability
Claude Compliance API (native)
Real-time DLP at the surface (ORION Security)
When it sees the data
After it reaches Claude
Before it leaves the endpoint or browser
What it does
Reports and routes activity into your DLP and SIEM
Allows, stops, or coaches the action in real time
Coverage
Claude Enterprise
Claude Enterprise, Team, free accounts, and Claude Code
Role
Governance and visibility
Prevention at the point of risk
The Compliance API reports what already reached Claude, which is useful for audit and monitoring. ORION Security works one step earlier, at the surface where the paste happens, and stops the leak before it reaches Claude at all. Governance after the fact from Anthropic; prevention before the fact from ORION Security.
Why Generic DLP Misses Claude
Generic DLP misses Claude because it was built to watch files, email, and network egress, not text and documents moving through a browser tab or a coding assistant. Its detection depends on matching a pattern set in advance: a credit card number, a file label, a known fingerprint. A long passage of pasted legal analysis matches none of those, so it passes straight through.
The category is sound. The policy model under it is what failed. Match-a-pattern was always going to lose once data started leaving as free text and whole documents. A control now has to see the action where it happens and judge it as it happens. That takes a different architecture, and AI is what makes it work, built for this surface from the start.
How Claude DLP Works: Capture, Classify, Act
Claude DLP works in three moves. It captures what a user is about to send, at the browser or the endpoint. It classifies whether the content carries sensitive data. Then it acts on a verdict, by intent and context: allow it, stop it, or coach the user in the moment. The decision lands before the prompt reaches Anthropic.
Underneath, a set of agents enrich every action the same way. They classify the content with language models, trace where it came from, and read the context around it: who’s sending it, from where, to where, and whether that’s normal for them. An analysis agent then returns the verdict. The same engine runs across every AI tool, so Claude, ChatGPT, and Copilot all pass through one analysis. The system learns your environment as it goes and isn’t trained on your data.
What ORION Security Does for Claude
ORION Security makes Claude safe to use rather than something to fence off from employees. It gives a security team one place to see all data movement into Claude and every other AI tool, classify what’s sensitive, and act before a leak leaves, by intent and context. Teams keep using Claude on real work, and the sensitive data stays in.
Two capabilities matter most here. ORION Security can be taught what your organization treats as sensitive, even when it isn’t a standard pattern, so a data type unique to your business gets caught where a generic classifier would wave it through. And it works without a policy-writing project up front, then lets you add hard rules on top of the AI’s classification when you want them. For the mortgage servicer running Claude Code, that turned an unseen risk into an enablement story: engineers kept their speed, and the security team finally saw what was being sent. Precise detection also cuts noise instead of adding to it. One ORION Security customer saw false positives fall from 10,000 a week to under 100.
What Securing Claude Looks Like in Practice
Securing Claude means watching every way data can move through it under one engine, so a paste, upload, and a Claude Code session all run through the same path and verdict. Coverage is the whole range, not a short list of preset scenarios. The common cases are easy to picture.
A lawyer pastes a privileged agreement to get a plain-language summary. An analyst drops a regulated financial model in for review. An engineer points Claude Code at a repository that holds API keys. An employee opens a personal Claude account to finish work off the clock. Each runs through the same analysis and choice: allow it, stop it, or coach the person in the moment. A large U.S. insurance brokerage runs its entire program this way with one person, less than two hours a day, where its old DLP needed a dedicated team and still couldn’t see the browser.
Setup and Integration Requirements
Agentic DLP for Claude should run light. ORION Security deploys in 30 minutes, the same across the browser, endpoint, and cloud AI tools, and it starts seeing data movement without a six-month policy build. Where you already run the Compliance API for Claude Enterprise, ORION Security adds the prevention that feed was never meant to provide.
Ask any DLP vendor three questions. Which surfaces does your tool cover: browser, endpoint, Claude Code, or only one? How long until it sees real Claude traffic, thirty minutes or several months? And how many people does it take to run? Legacy DLP earned its name by failing all three: a dedicated team, a long rollout, and a browser it couldn’t watch. ORION Security customers run their program with one person, less than two hours a day.
Claude DLP Best Practices
The best practice for Claude is to allow it with guardrails, not ban it. Detect at the surface where the paste and the upload happen, set policy by data type and intent, cover Claude Enterprise, Team, free accounts, and Claude Code together, and coach employees the moment they’re about to cross a line.
Bans backfire. Block Claude outright and the work moves to personal accounts on consumer terms, where inputs can train the model and the security team sees nothing, which is worse than where it started. Compliance follows from getting prevention right. It’s the downstream win, not the headline. When a privileged document or a regulated record never reaches a third-party model, the obligation that would have been breached never comes into play, and the audit takes care of itself.
Frequently Asked Questions
Does Claude have DLP built in?
No. Claude Enterprise adds account controls and, through the Compliance API, routes activity into your security tools. That’s governance and visibility, read after data reaches Claude. Stopping an employee from pasting confidential data into a prompt takes dedicated DLP at the browser or endpoint.
Does the Claude Compliance API replace a DLP tool?
No. The Compliance API reports Claude Enterprise activity into your DLP and SIEM, which is valuable for audit and monitoring. It doesn’t stop a sensitive paste in real time, and it doesn’t cover Team or free accounts. ORION Security adds what the API leaves out: prevention at the surface, before data reaches Claude.
Can DLP block data from being submitted to Claude?
Yes. Claude DLP can stop a risky submission, redact the sensitive part, or coach the user before the content reaches Anthropic. A precise tool chooses the lightest action by intent and context, so most work is never interrupted.
Is Claude safe for regulated industries?
With surface-level DLP in place, yes. Legal, healthcare, and finance teams use Claude on real work when a control reads each action and keeps regulated records from leaving. Without that control, the long documents these teams paste create exposure.
Does securing Claude mean blocking it?
No. The goal is safe adoption. Blocking pushes employees onto personal accounts with zero visibility. Good Claude DLP lets teams keep using the tool while confidential data’s caught before it leaves.
What about Claude Code?
Claude Code is covered as its own surface. ORION Security sees what a coding session is about to send and catches source code and embedded secrets before they leave, so engineers keep their speed and the security team keeps its view.
Welcome to our DLP for AI blog series. Read our previous article on DLP for ChatGPT.
DLP for ChatGPT stops sensitive data, source code, customer records, and financial models from being sent through a ChatGPT prompt to OpenAI.
Generic DLP misses it. Legacy tools watch files, email, and the network. ChatGPT is text-pasted into a browser, a surface it was never built to see.
ChatGPT Enterprise secures the account, not the data an employee types into it. Useful, but it’s not DLP.
The goal is safe adoption. Let teams use ChatGPT and catch leaks by intent and context. ORION Security covers ChatGPT as both a browser tab and a desktop app, deploys in 30 minutes, and can be taught your company’s own sensitive data types. One 5,000-employee customer runs the whole program with one person, less than two hours a day.
Enterprise teams want to run on ChatGPT. Marketing drafts with it, engineers debug with it, and finance models with it. For a CISO, whether to allow ChatGPT use is already settled. The open question is how to let people use it while preventing sensitive data loss. ORION Security was built for that question, and this guide covers it.
What Is DLP for ChatGPT?
DLP for ChatGPT is a set of controls that stop sensitive company data from leaving in a ChatGPT prompt. It watches what a person is about to send at the browser or the endpoint, decides whether the content is safe to share, and redacts, warns, or stops it before the text reaches OpenAI’s servers. The aim is to keep teams productive while the data stays in.
The distinction that matters is where the work happens. Old data loss prevention watched the exits: the file transfer, email gateway, USB port. ChatGPT is a different surface; it’s a conversation in a browser tab with a website the company wants people to use. Stopping a leak there means catching the action as it happens, while the data is still in the room.
Why ChatGPT Is the Top Data Leak Vector in Enterprise Teams
ChatGPT is the top data leak vector in enterprise teams because the data leaves as text, not as a file or an email. Someone pastes source code, a customer list, or a financial model into a prompt to move faster. The information reaches OpenAI in seconds, and the controls bought years ago register nothing, because the data doesn’t move through the channels they watch.
This isn't a hypothetical risk. In 2023, within 20 days of allowing ChatGPT, Samsung was hit with three separate leaks: an engineer pasted source code to fix a bug, another fed in internal meeting notes, and a third uploaded a chip-test sequence. Samsung banned the tool outright. Most enterprises since have chosen the harder path: keep the productivity, control the leak.
Every CISO already knows this is happening inside their own walls. They know engineers paste secrets, support staff paste customer records, and that shadow AI is everywhere. The part they rarely say aloud is that the controls they own can’t see any of it. The data at risk is consistent: source code, customer records and PII, financial models, internal strategy and deal documents, and HR files. None of it leaves as an attachment, which is exactly why it slips through.
5 Ways Enterprise Data Leaks Through ChatGPT
Enterprise data leaks into ChatGPT in a handful of repeatable ways. An engineer pastes source code to debug it. A support agent pastes customer records to draft a reply. An analyst pastes a financial model to summarize it. A manager pastes an internal strategy or deal document to rewrite it. An HR partner pastes employee data to reformat it.
None of these are malicious. They're accidental exposure by people trying to do their jobs well, which is what makes the pattern so consistent and so hard to fix with awareness alone. The rare malicious insider is the catastrophic tail. The daily volume is ordinary people moving fast, with no control watching the browser.
Why Generic DLP Misses ChatGPT
Generic DLP misses ChatGPT because it was built to watch files, email, and network egress, not text typed into a browser. Its policy model depends on recognizing a pattern set in advance: a credit card number, a document label, a file fingerprint. A paragraph of unreleased strategy pasted into a prompt matches no signature, so it passes straight through.
The category is sound. The policy model underneath it is what failed. Match-a-pattern was always going to lose to read-the-intent once data started leaving as free text. Legacy tools watch the USB port and the mail gateway. A browser session is neither, so a control has to see the action where and when it happens and judge it in real time. That's a different architecture, and AI is what makes it work, built for this surface from the start.
How ChatGPT DLP Works: Capture, Classify, Act
ChatGPT DLP works in three moves. It captures what a user is about to send, at the browser or the endpoint. It classifies whether the content carries sensitive data. Then it acts on a verdict, by intent and context. The decision happens before the prompt reaches OpenAI.
The act step is where tools separate. Block everything that looks risky and you bury the team in friction, and they move to a personal account where you see nothing. But if the tool can understand intent and context, the user, data type, and destination, you can choose the appropriate action: let it through, coach the user, or stop it outright. Detection is table stakes. The work is in acting precisely, without a person triaging an alert queue.
Does ChatGPT Have DLP Built In?
ChatGPT Enterprise includes real security controls, but not data loss prevention in the sense an enterprise needs. It doesn’t train on your data, and it adds SSO, encryption, admin governance, and retention settings. What it doesn’t do is stop an employee pasting a customer database into a prompt. Its controls protect the account and the tenancy. They don't protect the data a person chooses to type in.
That distinction decides what you still need. ChatGPT Enterprise secures the platform. It doesn’t secure the behavior, and it only covers ChatGPT. The same employee governed inside ChatGPT Enterprise can open Claude, Gemini, Copilot, or a personal ChatGPT account in the next tab, with none of those controls present. Real ChatGPT DLP works at the surface the person is using, across every AI tool, rather than inside one vendor’s walls.
Detection Methods Compared: Browser, API, and Endpoint
Three methods detect ChatGPT data leaks, and each sees a different slice. Browser-level controls watch the tab and see the paste itself. API or network controls inspect traffic to OpenAI and see the request. Endpoint controls run on the device and see local activity. Rely on one and you leave a door open.
Swipe to see the full table →
Method
What it sees
Strength
Blind spot
Browser-level
The paste or typing inside the ChatGPT tab
Catches the action at the source, before it sends
Misses native desktop apps and unmanaged browsers
API / network
Traffic headed to openai.com
Works across devices on the network
Misses content once encrypted, and off-network use
Endpoint agent
Activity on the managed device
Broad device visibility
Heavier to deploy, blind to unmanaged devices
The lesson is that no single surface is enough. A tool that only watches the browser misses the desktop app. A tool that only watches the network misses encrypted traffic. Real ChatGPT DLP combines surfaces, so the paste is caught whether it happens in a managed browser, a desktop app, or a tab the employee opened on their own. ORION Security covers all three: a lightweight sensor on the endpoint, an extension in the browser, and API connections for cloud AI tools. ChatGPT is covered whether an employee runs it as a desktop app or opens it in a browser tab.
What ORION Security Does for ChatGPT
ORION Security makes ChatGPT safe to use rather than something to ban. It gives a security team one place to see all data movement into AI tools, classify what’s sensitive, and act before a leak leaves, by intent and context. Teams keep using ChatGPT, and the sensitive data stays in.
Underneath, ORION Security treats every action the same way. When data moves, whether it’s a paste into ChatGPT or a file leaving a folder, a set of agents enrich it: they classify the content with language models, trace its full lineage, and read the context around it, who sent it, from where, to where, and whether that’s normal. An analysis agent then returns a verdict in real time: allow it, stop it, or coach the person in the moment. The same engine runs across every AI tool, so ChatGPT, Claude, and Copilot all pass through the identical analysis. The system learns your environment instead of training on your data, and grows more accurate as it goes.
Two capabilities set this apart for ChatGPT. The first is custom classification: ORION Security can be taught what your organization treats as sensitive, even when it isn't a standard pattern. An airline customer needed frequent flyer numbers recognized as protected data, something a generic classifier would never flag. The second is policy flexibility: you can start without writing a single policy, then build them on top of the AI’s classification when you want to, for example a hard rule that one specific file type can never leave the company.
The outcomes a CISO feels are visibility, adoption, and quiet. Security teams see all data movement in one place, so any event can be followed from the person who touched a file to where it went. We finally know what's happening with our data is the line customers reach for. HR, finance, and engineering use ChatGPT on real work without the security team holding its breath. And precise detection cuts the false-positive load instead of feeding it: one ORION Security customer saw false positives fall from 10,000 a week to under 100. This is a data-loss problem with a new surface. Solve DLP properly and the AI exposure is solved with it.
What Securing ChatGPT Looks Like in Practice
ORION Security covers the full range of ways data leaves through ChatGPT, because it watches any data movement through one engine. A paste, an upload, or a file leaving a folder all run through the same path, so coverage is the whole range, not a short list of pre-set scenarios.
The common ones are easy to picture. An engineer pastes source code to debug it. A support agent pastes customer records to draft a reply. A finance analyst pastes a model full of regulated figures. An employee drops confidential information into a personal ChatGPT account the company never sanctioned. A managed ChatGPT instance gets wired to another AI agent nobody approved. Each runs through the same analysis and the same verdict: allow it, stop it, or coach the person in the moment.
Two customers show it working. A U.S. mortgage servicer provided engineers, who had no prior visibility into what was being sent, with ORION Security AI assistants. That gave the security team visibility and caught sensitive code before it left, and adoption became an enablement story instead of a quiet risk. A U.S. insurance brokerage with 5,000 employees has one person using the ORION Security dashboard less than two hours a day, where its old DLP needed a dedicated team, constantly tracking alerts.
Setup and Integration Requirements
Agentic DLP for ChatGPT runs light. ORION Security deploys in 30 minutes, the same across the browser, the endpoint, and cloud AI tools. It starts working without a six-month policy-building project: you connect it, and it begins seeing data movement straight away.
Ask any vendor three questions. Which surfaces does it cover, browser, endpoint, and SaaS, or only one. How long until it sees real AI traffic, 30 minutes or six months. And how many people does it take to run. Legacy DLP earned its reputation by failing all three: a dedicated team, a long rollout, and a browser it still couldn't see. ORION Security customers have run their program with one person, two hours a day.
ChatGPT DLP Best Practices
The best practice for ChatGPT is to allow it with guardrails instead of banning it. Deploy detection at the surface where the paste happens, set policy by data type and intent, cover every AI tool your teams touch, and coach employees the moment they're about to cross a line.
Bans backfire. As one security leader put it, you can’t dam a river, the water finds another way. Block ChatGPT outright and usage moves to personal accounts where you have zero visibility, which is worse than the problem you started with.
Compliance follows from getting this right. A working ChatGPT DLP program keeps GDPR, HIPAA, and CCPA obligations intact, because the regulated data that would trigger a violation never reaches a third-party model. Treat compliance as the downstream benefit of stopping loss. Protect the data first, and the audit takes care of itself.
Frequently Asked Questions
Does ChatGPT have DLP built in?
No. ChatGPT Enterprise adds account-level controls such as SSO, encryption, no training on your data, and admin governance, but it doesn't stop an employee pasting sensitive data into a prompt. That requires dedicated ChatGPT DLP at the browser or endpoint.
Can DLP block data from being submitted to ChatGPT?
Yes. ChatGPT DLP can redact the sensitive part of a prompt, warn the user, or stop the submission before it reaches OpenAI. A precise tool chooses the action by intent and context, so most work is never interrupted.
What is the difference between traditional DLP and ChatGPT DLP?
Traditional DLP watches files, email, and network egress for known patterns. ChatGPT DLP watches the browser and endpoint for sensitive text typed or pasted into a prompt and decides in real time, a surface and a moment legacy tools were never built to see.
What types of data are most at risk in ChatGPT?
Source code, customer records and PII, financial models, internal strategy and deal documents, and HR files. All of it leaves as text rather than as an attachment, which is why it slips past older controls.
How does ChatGPT DLP handle GDPR and HIPAA?
By keeping regulated data from reaching a third-party model at all. If a customer record or patient detail is redacted or blocked before it leaves, the exposure that would breach GDPR or HIPAA never occurs.
Does securing ChatGPT mean blocking it?
No. The goal is safe adoption. Blocking pushes employees onto personal accounts with zero visibility. Good ChatGPT DLP lets teams keep using the tool while sensitive data is caught before it leaves.
Can security teams see what employees paste into ChatGPT?
Yes, with browser or endpoint-level ChatGPT DLP. Security teams get visibility into what data is moving into AI tools and can follow any event back to the user, the data, and the destination.
Welcome to our DLP for AI blog series. Stay tuned for future articles on DLP for Claude, DLP for Microsoft CoPilot, and DLP for Google Gemini.
Agentic DLP is data loss prevention run by autonomous AI agents that evaluate context and stop unsafe actions before data leaves. Instead of matching data against pre-written rules, agentic DLP decides whether each action is safe and prevents risky ones in real time.
The word that matters is agentic. An agent here is a piece of software with enough understanding to make a decision without human intervention. It sees a file move, a paste into a chat window, or an upload to a site, and decides where it’s a legitimate action. AI is the architecture underneath that decision, not a sticker on the box. ORION Security built DLP this way because a human review queue can’t keep up with prevention at the speed data travels today.
This is a different job from the one legacy DLP tools were built for. A legacy system asks one question: does this content match a rule? An agentic system asks harder, more useful ones: who is doing this, with what data, in what context, and is this action safe?
The 4 Traditional Types of DLP, and How Agentic Changes the Model
Traditional DLP came in four flavors, split by where it watched: network, endpoint, cloud, and email. Each one inspected traffic in its zone and compared it against policies. Agentic DLP doesn’t add another zone. It changes the engine, replacing the policy match with an agent that reasons about intent across every zone at once.
Network DLP watched data crossing the corporate perimeter. Endpoint DLP sat on laptops and caught local actions like copying to a USB drive. Cloud DLP scanned data sitting in sanctioned SaaS apps. Email DLP inspected outbound messages. Each worked inside its own walls, and each leaned on the same policy match to decide what to allow.
That split made sense when data lived in predictable places. It stopped making sense once an employee could paste a customer contract into a browser-based AI tool that belongs to none of those four zones. Agentic DLP unifies coverage for DLP across surfaces, endpoints, SaaS, cloud, email, storage, web, and the AI tools people now use every day, and applies one reasoning engine to all of them.
A wave of tools added AI to that same policy model and rebranded as next-gen DLP. The model underneath didn’t change; the AI just sorts the alert queue faster. Agentic DLP is the real innovation, because the agent makes the decision in context of the behavior.
Scroll to see the full table (Agentic DLP) →
Capability
Legacy DLP
Next-Gen DLP
Agentic DLP
Core model
Policy and pattern match
Same policy match, AI added on top
Agents reason about intent and context
What AI does
Nothing
Scores and sorts alerts
Makes the decision
Coverage
Single zone
Broader, still zone-based
All surfaces, including AI tools
Action
Alert for a human to triage
Alert, better sorted
Autonomous action before data leaves
Setup effort
Heavy policy authoring
Heavy policy authoring
Minimal, learns normal movement
Shadow AI visibility
None
Limited
Built in
Why Legacy DLP Fails in an Agentic AI World
Legacy DLP fails because the policy model failed, not because protecting data stopped mattering. A rule can only catch what its author thought to describe. People now move data in ways no policy author anticipated, through AI tools that didn't exist when the rules were written, and the gap between what the rules cover and what employees do day to day has become the whole risk.
Most data exposure is accidental. An engineer pastes confidential information into a prompt to get help faster. A salesperson drops a confidential deck into a free AI summarizer. An AI browser, acting for a user, uploads a contract to a third-party site on its own. None of these is malicious. None of these matches a classic exfiltration signature. A rules engine sees nothing wrong.
Shadow AI made the gap permanent. Every security leader knows employees use unsanctioned tools, knows developers paste code into prompts, and knows the company has AI activity it can't see. Few say it aloud, because naming the problem means admitting the current tool doesn't solve it. That silence is the untenable status quo that agentic DLP is built to end.
What Does Agentic DLP Do? 4 Primary Use Cases
Agentic DLP earns its place through four jobs: providing the security team with one view of all data movement, flagging shadow AI and SaaS, dramatically reducing false-positive alerts, and supporting a security environment that lets the business move faster. Each job maps to a problem a security leader already has and already struggles to staff against.
Visibility into all data movement comes first. One place to easily see every trace, click any event, and follow who touched a file, where it came from, what they did with it, and where it went. As one customer put it: "we finally know what is happening with our data."
Safe AI adoption is the second job. A security team can turn on Cursor, ChatGPT, and Claude for engineering, finance, and HR without fear that sensitive data walks out through a prompt. The aim is to make AI usage safe, not to ban it. Blocking the tools just pushes the activity underground.
False-positive alert collapse is the third. Agentic decisions cut the noise that buried legacy teams. For one ORION Security customer, a U.S.-based identity-verification company, AI auto-triage saved an estimated 196 analyst hours in a single quarter. Another ORION Security customer watched its alert volume fall from 10,000 a week to under 100. Resource efficiency follows: with coverage handled by agents, a customer shared that one person spending less than two hours a day can run what used to need a dedicated team. Security stops being the brake, and becomes the thing that lets people adopt new tools with confidence.
How Agentic DLP Works: Detection, Coverage, Response, and Behavior
Agentic DLP works across four layers: detection that reads data and context together, coverage that spans every surface data crosses, response that acts on its own, and behavior modeling that learns what normal looks like. The agents tie these layers together, so a single decision draws on all four at the moment data moves.
Detection is where AI replaces pattern matching. Instead of asking whether text matches a rule, the system reads what the data is and the situation around it, the user, the destination, the sensitivity, and forms a judgment. That judgment holds up against cases a static rule would miss, like paraphrased confidential information or a screenshot of a contract. As a security engineer at one ORION Security customer described the switch: "it's not regex, it's not patterns, it's a prompt."
Coverage spans endpoints, SaaS, cloud storage, email, web, and the AI tools in active use, so there is no zone where data can slip out unwatched. Response is the autonomous part: whether the right action is to allow, warn, or stop depends on intent and context. The agent decides which, then acts before data leaves rather than filing an alert for someone to read later. Behavior modeling lets the system learn each organization's normal movement, so it flags the genuine outlier instead of drowning analysts. On methodology, what matters is what the agents decide and measure, not the internal mechanics, which stay protected.
If you want to see what one view of all your data movement looks like, across endpoints, SaaS, cloud, and the AI tools your people already use, ORION Security will show you.
Frequently Asked Questions about Agentic DLP
What is the difference between DLP and SIEM?
SIEM collects and correlates security events so teams can see and report what happened across the environment. DLP decides whether a data action is safe and stops the unsafe ones in the moment. Agentic DLP feeds SIEM cleaner signal and acts where SIEM only records. They sit side by side, not in competition.
Is DLP obsolete?
No. The legacy policy model is what failed, not the goal of stopping data loss. With AI pushing more data into more places, preventing loss matters more than ever. Agentic DLP is how the category catches up: the same job, done by agents that read intent instead of rules someone wrote in advance.
What are the 4 types of DLP?
The four traditional types are network, endpoint, cloud, and email DLP, split by where each one watches. Agentic DLP doesn't add a type; it changes the engine, applying one reasoning layer across all of those surfaces and the AI tools that now sit outside them.
I recently co-hosted a webinar with Lawrence Pingree on what he calls The Great DLP Reset. Lawrence leads data security and AI research at Software Analyst Cyber Research (SACR), is a former Gartner analyst, and one of the most experienced independent voices in the category.
His research also validates everything that drove Nitay Milner and me to launch ORION Security. Data moves faster and further than it ever has, and ORION is built for that reality.
Lawrence calls traditional DLP a “faded, broken padlock,” and we couldn’t agree more. I once had the challenge of implementing DLP at a fast-growing software company, and I know what it feels like to constantly tune policies and still not reach prevention mode, while watching the false positives pile up.
As he said, this creates a “ticket factory.” I talk to CISOs all the time who are frustrated with their own ticket factories, with their DLP getting so stuck in the tune phase that they never reach prevention.
The Impact of AI on DLP
AI use has exploded across organizations in the past few years. Something Lawrence and I kept coming back to in the webinar is that most companies have a shadow AI problem: they don’t know what AI tools their employees use or how they use them. So they don’t know what policies to create, because you can’t write a policy for tools you can’t see.
Modern DLP manages this challenge. A good analogy is the breakthrough the security industry made with endpoint detection and response (EDR) about 10 years ago. Signature-based antivirus couldn’t catch what it didn’t already know about, and EDR changed that by evaluating behavior and context instead. Policy-based DLP has the same limitation: if there’s no policy for it, it gets through.
ORION is leading that same kind of shift, just applied to DLP.
ORION at the Forefront of the DLP Reset
Nitay and I didn’t set out to build a better version of what already existed. We wanted to rebuild the foundation. That meant moving away from the policy approach and embracing real-time, agentic DLP.
The core problem with policy-based DLP is it depends on someone having seen and defined the threat before it can be caught. A skilled security analyst doesn’t work that way. They catch incidents by understanding context: who is moving this data, what it is, where it’s going, and whether that behavior is normal for the person in that role.
Here’s what’s interesting: security analysts mark false positives all the time. The industry average is over 90%. And if a security analyst can differentiate between legitimate activity and suspicious activity using their judgment, an AI agent can be trained to do it as well, at machine speed, across every interaction simultaneously.
ORION’s proprietary AI agents analyze data in motion, evaluating every action across identity, behavior, content, lineage, and environmental context. Our system understands intent and delivers a verdict on whether an action reflects normal business activity or actual exfiltration, in real time, without requiring a policy to be written first. That includes endpoints, browsers, SaaS, email, and AI tools, including the unmanaged sessions and agentic workflows that legacy tools weren’t built to handle. There are no policies to write, tune, or maintain, because ORION learns continuously and adapts as the environment changes.
This is what the reset actually looks like.
Learning to Love DLP
One of the things Lawrence and I agreed on completely is that the future is autonomous prevention, not detection and response. The way we think about it at ORION: once we have enough confidence in an AI agent’s performance on a specific use case, and once the false positive rate is low enough, we turn it on in fully autonomous mode. It can block, redact, or quarantine without waiting for a human to approve each decision. This allows your team to focus on the cases that actually need their expertise.
AI also lets security teams do more with less. As AI agents take on the work of monitoring data movement and flagging real incidents, your team stops rewriting rules and starts working actual threats.
What Lawrence laid out in the webinar tracks with what we see every day. The future of DLP is a data control plane, unified discovery, context, real-time enforcement, and AI-driven decision-making working together toward a prevention outcome that actually works. It’s a system that runs continuously, learns the environment, and catches real incidents without someone having to babysit it.
Based on what we’re seeing from customers, including some of the largest global enterprises, we know this is possible because it’s already working.
The CISO at a large financial institution, and a valued customer, gave us the best compliment in a recent conversation: “I hated DLP before ORION.”
Do you think you could learn to love your DLP? We think so. If your team is stuck in tuning mode and ready to see what prevention actually looks like, let us show you a demo.
At ORION Security, we talk a lot about the Great DLP Reset, caused by complex legacy tools, brittle policies, and piles of false positives. The industry needs to start over, and ORION Security is committed to leading this long-overdue change for data loss protection.
In this article, we address an important aspect of this transformation. It challenges the belief that has shaped how organizations approach data security: that data security posture management (DSPM) needs to come before DLP. Here is why that thinking no longer holds.
What Reduces Security Risk the Fastest?
In our conversations with security leaders, one question tends to reframe the entire conversation: What will reduce my risk the most, and the fastest?
Our response differs from what many cybersecurity vendors have pitched for years, which is to adopt DSPM first. This follows the model to first classify your data at rest to identify shadow data and protect the crown jewels, get your labels in order, then build your DLP on top of that foundation.
There are a few problems with that approach. First, it means waiting 6-12 months before you have any meaningful path to enforcement and protection against data leaving your organization as it is moves through email, endpoints, SaaS applications, and personal cloud accounts. Data exfiltration remains the highest and most common form of data risk most organizations face. Every week spent cataloging data at rest to build a DSPM foundation is a week where data in motion is moving without any real oversight, and that is where breaches actually happen.
Why the DSPM-First Model Falls Short
DSPM itself isn’t a bad tool. The problem is it prioritizes the wrong thing.
DSPM was designed to answer inventory and governance questions: Where sensitive data lives, who can access it, and is it properly secured at rest. All legitimate questions. The traditional thinking is that you need those answers before you can build DLP on top. So organizations stand up DSPM, build out their data catalog, generate classification labels, and then use those labels to configure DLP rules.
But even when this sequence works as intended, the best you end up with is a DLP program built on static rules derived from a static classification. The rules reflect what the data looked like when the scan ran, and they fire based on pattern matching against content rather than any understanding of context or behavior. A label that says PII tells you what’s in the file, but nothing about whether sending it right now to this recipient through this channel represents a real threat or a routine business activity.
After months of foundation building, you still can’t tell the difference between a file shared legitimately or being exfiltrated. The employee downloading a customer list to upload to their personal Google Drive; the engineer pasting source code into an AI tool; the salesperson forwarding a contract to their personal email before leaving the company; none of these are stopped by a classification label. They are stopped by understanding context at the moment of movement, and that is something the DSPM-first model wasn’t built to provide.
Data Intelligence in Motion: The Agentic DLP Model
The security industry has spent decades building tools that answer the wrong question. DSPM asks, where is my sensitive data? Legacy DLP software asks, does this content match a known pattern? Both questions are static. They treat data as something you catalog and monitor, rather than something you understand.
Data intelligence in motion is a different proposition entirely. It asks, what is this data? Why is it moving? Who is moving it? Does that movement represent a risk right now? That shift from cataloging to comprehending is what makes the new model fundamentally different, not just incrementally better.
The assumption behind the DSPM-first approach was that legacy DLP tools needed classification labels to function. Without pre-tagged data, the rules could not fire, so you had to build the catalog before you could build the enforcement. That dependency made DSPM feel mandatory, and for a long time it was.
ORION Security breaks that dependency. Our agentic DLP solution classifies data at the moment it moves, understanding what it is and whether it’s sensitive from context alone, not from metadata. The work DSPM does at rest is already complete by the time data reaches the point where it could cause harm.
ORION Security AI reads and comprehends unstructured documents, emails, chat attachments, code, and screenshots, and reaches a verdict on whether that data is sensitive based on what it is, who is sending it, where it’s going, and what the surrounding context looks like.
At a healthcare organization, a patient record forwarded to an outside clinician is clearly distinguishable from that same record leaving the organization through a personal email account. ORION knows the difference without being told and without needing a prior classification scan.
When ORION Security deploys, it starts building a picture of your data landscape from the ground up, based on what is actually moving. Every file that transits an endpoint, every document sent through email, every upload to a SaaS application gets classified in real time, in context, at the moment of movement. Within days of deployment you have a live, accurate map of where your sensitive data is going and who is moving it, built from actual behavior rather than a periodic scan of storage that was already stale the moment it finished running.
Our classification intelligence accumulates continuously and gets more accurate over time without anyone maintaining a rule library or running another scan. Because our proprietary AI is evaluating full context rather than matching patterns against static labels, organizations can move from monitoring to active blocking in weeks, something that would have taken months or even years following the traditional DSPM-first path.
For the security leader asking what reduces risk the most and the quickest, the answer is addressing data in motion first. ORION makes it possible to do that without any prerequisites.
Where DSPM Still Fits
None of this means DSPM has no value. For organizations that need to understand their full data inventory, enforce access controls around data at rest, or address specific compliance requirements around data discovery, DSPM is a meaningful investment. ORION integrates natively with leading DSPM platforms, such as Microsoft Purview and Sentra, and can absorb their classifications to make detections even more precise.
But the sequencing question deserves a more honest answer than the industry has been giving. The assumption that DSPM has to come before DLP was built for a world where DLP tools could not function without pre-classified data. That world has changed.
For organizations that have not started a DSPM deployment yet, starting with ORION means real protection is in place immediately. For organizations already mid-way through a DSPM program, ORION doesn’t displace that work. It runs alongside it.
The DLP Reset Starts Here
The sequencing debate is happening in CISO offices and budget reviews across the industry, and the framing is usually some version of, “We need to know what we have before we can protect it.” That framing was reasonable for a long time. What is worth pressure-testing is whether it’s still correct given what’s available today, because the more useful question is which approach reduces risk the fastest with the most efficient use of budget and headcount.
While the DSPM first model was always in service to the goal of stopping sensitive data from leaving the organization, it did not treat it as a priority. Data leaving is always data in motion, and ORION was built to prioritize exactly that, looking at data the moment it moves, classifying it in context, and acting on it automatically before it crosses a boundary. The inventory of what you have follows naturally and is built from real movement rather than periodic scans.
If the question on your team’s mind is what reduces risk the most and the quickest, the answer is that protection starts at the point of departure, and with ORION that starts on day one.
At ORION Security, we spend a lot of time talking with security teams struggling with the same problem: traditional data loss prevention (DLP) approaches can’t keep up with how data moves today.
Lawrence Pingree agrees. In fact, it’s central to his research on what he calls “The Great DLP Reset,” which he shared in a recent webinar co-hosted with ORION Security.
Lawrence, who leads research at Software Analyst Cyber Research (SACR), is one of cybersecurity’s most experienced voices. He’s a former Gartner analyst who has published more than 300 research notes, advised many of the top security vendors in the market, and helped define categories like EDR, SASE, and SD-WAN.
I highly encourage CISOs and their teams to dig into this research to fully understand how to manage and deploy DLP in today’s world. Below are key insights from his presentation during the webinar, edited for clarity.
Q: Why does traditional DLP fail to prevent data loss?
Lawrence: Classic DLP primarily existed in firewalls, secure web gateways, and endpoints; proxies built to enforce control over data at fixed points. It was heavily reliant on regular expressions and exact data matching. Back then, the perimeter was different. There was this notion of an ”inside” and an “outside” of every environment. It wasn’t porous like it is today.
Q: Why do so many DLP programs end up spread across disconnected tools?
Lawrence: We call it the fragmented DLP approach, and it’s central to the problem. You have a little bit of capability around email, some in the endpoints, maybe one feature across SaaS with some CASB (cloud access security broker). You need to configure different platforms to get to one use case across the board. And you have misalignment between the capabilities you have in the different tools.
Q: Is DLP still relevant in 2026?
Lawrence: It’s more relevant than ever, but the category needed a reset. While DLP has ebbed and flowed over the years, it’s back now because SaaS sprawl and cloud data gravity have come into play, and business apps and tools have evolved to include generative AI and agentic workflows.
Q: What is shadow AI, and why is it a data loss risk?
Lawrence: Quite simply, more people are uploading their organization’s data in things like spreadsheets into AI tools because it’s useful. But that data may not be approved for sharing; it might even be regulated. And there have been a lot of use cases where prompt injection and agentics have demonstrated the ability to exfiltrate data, even in apps like Microsoft Copilot. All of these are potential risks.
Q: On the flip side, how does the use of AI in DLP detection reduce false positives?
Lawrence: AI enables something that deterministic policies never could: contextual judgment at machine speed. That cognitive function brings beauty to context because you can storyline various contextual elements together: the identity role, the data involved, the application, location, history and behavior, and business context. AI can look at every interaction and make an assessment: is this actual data leakage or just benign activity? It paints the picture of the actual scenario versus an individual event.
Q: What does real-time DLP enforcement look like compared to the old way?
Lawrence: Legacy DLP is kind of a faded, broken padlock. The classic perimeter approach just doesn’t work. We’ve reached a DLP rearchitecture point where we’re moving to more runtimes. We’ve got to move to a more real-time environment focused on prevention versus detection and response. The future state is AI-enabled autonomous policies, both in creation and fine-tuning.
Q: How should security leaders evaluate and modernize their DLP program?
Lawrence: Start by scoring your current program honestly. Look at your time to discover and classify meaningful sensitive data. Look at your policy model and your tuning burden. Are you running a ticket factory? You shouldn’t be. Add context to every decision: fuse identity, entitlements, posture, and user behavior to cut down on false positives and focus on real material risks. Strive for one set of policy intents across the various surfaces. The overall goal should be this: credible AI-era controls.
Q: Where do AI-native DLP vendors fit in the modern security landscape?
Lawrence: A new category of vendors is emerging that was built for this era from the ground up. You have vendors like ORION Security, which I consider more of the context-rich version, integrating AI to build better controls, better understanding, and cognitive function around the way interactions are happening within the enterprise.
Final Thoughts
I really enjoyed the hour I spent with Lawrence Pingree discussing this massive reset. The shift from traditional DLP to AI-native, context-aware data protection is accelerating as organizations adopt SaaS, cloud platforms, copilots, and autonomous AI agents.
As Lawrence puts it, the data control plane isn’t a box. It requires unifying discovery, context, enforcement, and AI-driven decision-making into a prevention outcome that actually works.
At ORION Security, we built our platform around exactly what Lawrence describes: AI that evaluates the full context of every interaction, not just whether it matches a rule. If your team is stuck in tuning mode and ready to see what prevention actually looks like, we’d love to show you what we’ve built.( Request a demo.)
A fundamental change in how data moves inside organizations occurred in the last year.
The use of generative AI tools is increasing, with AI becoming embedded directly in everyday workflows. Tools like Microsoft Copilot, ChatGPT, Gemini, and countless AI-powered agents are integrated into browsers, SaaS apps, developer environments, and internal systems. In many cases, enabled by default.
As this adoption rises, so does the threat of data loss.
For years, DLP was built around a relatively simple model: data is stored, transferred, and occasionally shared. This meant monitoring files, scanning for patterns, and enforcing policies at known control points, such as email, uploads, and endpoints. That model, which had many flaws to begin with, no longer holds.
With AI, we started constantly seeing how:
Employees paste internal documents into AI chats to summarize/rewrite them
Teams adopt AI tools outside approved channels without oversight
Agents interact with internal systems and external APIs in ways that are hard to trace
Data flows through browser extensions, plugins, and embedded AI features
Data is constantly being interpreted, transformed, and recombined, creating a new kind of risk surface that doesn’t map to traditional methods.
As we spoke to security teams, a pattern emerged. They were missing controls and visibility, but more importantly, there was often no clear way for them to even describe the problem:
What are the actual risks introduced by AI? Where do they occur? How do they differ from traditional data loss scenarios? And, most importantly, how do you prioritize what to fix?
There was no shared map of this new landscape or a structured way to reason about how data leaks in AI-driven environments. So we built one.
A Modern Data Loss Threat Modeling Framework
At its core, the goal was simple: create a structured way to map how data actually leaks in AI-driven environments, and make it usable for security teams. The full framework is available at dlptest.io/ai-threat-model
At a high level, the framework is simple. It breaks the problem down into three parts:
Types of risks (what can go wrong)
Concrete scenarios (how it happens in practice)
Surfaces (where it happens)
Risks
We identified a set of core data loss risks that are specific to AI:
Data leak via prompt
Context leakage
Data exfiltration
Modifying shared artifacts
Oversharing
Prompt injection
These represent the different ways sensitive data can be exposed when interacting with AI systems.
Scenarios and Surfaces
Each risk (Data leak via prompt Data exfiltration) is presented as multiple occurrences, and tied to where it occurs – SaaS, Endpoints, and Enterprise cloud, as well as the different AI interfaces: AI agents, apps, and browsers.
From Data Flow to Control
Understanding the risks is only one part of the problem. The next step is understanding how data actually flows and where control needs to be applied.
At a basic level, enterprise data starts in two places:
Data stores (Google Drive, SharePoint, S3, etc.)
Endpoints (laptops, browsers, local apps)
From there, it flows into different AI surfaces:
SaaS AI agents
AI chatbots
AI browsers
Endpoint-based agents
In many environments today, these flows are completely unmediated. Data moves directly from enterprise systems into AI tools – both managed and unmanaged.
At this stage, every interaction becomes a potential data leak into external SaaS or identities. There are no inspection points, no enforcement, and no clear understanding of what is leaving the organization.
Adding Controls
To cover this entire flow, controls need to be applied at multiple points.
At the SaaS layer, SaaS DLP governs how data moves between enterprise data stores and cloud applications.
At the endpoint layer, Endpoint DLP governs how data is accessed and used on user devices.
These controls establish visibility and enforcement across traditional data paths.
Controlling AI Interactions
AI introduces a new interaction layer that sits between data and external systems.
To fully cover this layer, additional controls are required:
Inspecting prompts and responses
Monitoring agent behavior
Controlling plugin and API access
The LLM firewall governs how data flows through AI systems themselves, rather than just the systems around them.
When combined, these controls cover:
Data access at the source
Data usage on endpoints
Data movement across SaaS
Data interactions within AI systems
This creates full coverage across the AI data flow.
How to Use This Framework
This framework is meant to be practical, and can be used to:
Map your exposure – Identify which AI tools, agents, and surfaces interact with your data
Identify gaps – Understand which scenarios you cannot detect or control today
Prioritize controls – Focus on the risks that matter most in your environment
Evaluate vendors – Compare solutions based on real scenarios, not generic capabilities
At its core, it aims to shift the conversation from: “Do we have DLP?” to: “Which AI-driven data loss scenarios can we actually prevent?”
As you go through the framework, a few key questions emerge:
Do we know which AI tools access enterprise data?
Can we inspect AI prompts and responses?
Can we detect AI agents accessing internal systems?
Do we control where AI plugins send data?
Can we monitor AI-driven API calls?
If these questions are difficult to answer, there are likely gaps in visibility and control.
Validating the Scenarios
While the framework helps map and reason about AI data loss risks, dlptest.io also allows you to test those scenarios in practice with modern, relevant use cases, as well as a rich library of structured and unstructured data test scenarios.
Try It Yourself
We built this framework to make the problem visible and actionable.
Employees are already using AI tools. Agents are already interacting with systems. Data is already flowing through prompts, APIs, and plugins. The question is no longer whether this is happening, but whether you understand it and can control it.
We hope this framework allows security teams to map their own environments, walk through the scenarios, and evaluate where controls are missing. Try it at dlptest.io/ai-threat-model
Modern organizations rely heavily on SaaS platforms and AI-powered tools to improve productivity and automate workflows. As these technologies become embedded in everyday operations, they also introduce new pathways for sensitive information to move across applications, users, and environments.
To help organizations protect their most sensitive data in this evolving landscape, we are proud to announce ORION’s collaboration with Grip Security that combines identity-driven SaaS visibility with behavior-driven data protection.
By bringing together Grip’s deep visibility into SaaS and AI ecosystems with ORION’s automated, AI-powered Data Loss Prevention (DLP), organizations can gain both the context needed to understand how data is accessed and the protection needed to stop risky behavior in real time.
Securing Data Across SaaS and AI
Sensitive information continuously moves across a growing ecosystem of SaaS platforms, AI tools, browser extensions, and automated integrations. With the rise of AI, it no longer resides only in controlled databases or internal applications.
Employees connect new applications in seconds, AI assistants summarize documents and generate insights from company data, and SaaS workflows automatically move files between systems.
While the productivity benefits are obvious, sensitive data now has new ways to travel outside the visibility of traditional security controls. Security teams must now answer questions that legacy tools were never designed to handle:
Who is accessing sensitive data?
Which SaaS or AI applications are involved?
Is the environment trusted?
Does the behavior match normal business activity?
Traditional DLP solutions often rely on predefined rules to decide what to block, allow, or escalate. These policy-driven approaches were designed for a world in which sensitive data primarily moved through predictable channels, such as email attachments or file uploads.
AI has fundamentally changed how data flows through organizations. Employees paste proprietary code into chatbots, upload documents into AI-powered SaaS tools, and interact with copilots embedded in everyday platforms like Microsoft 365 or Google Workspace. Sensitive data is no longer just transferred as files – it is shared through prompts, conversations, and automated workflows that traditional DLP rules were never designed to understand.
Without visibility into the identity, application, and behavioral context surrounding that data, security teams often face overwhelming false positives while still missing real incidents. Static DLP policies simply cannot distinguish legitimate work from risky data exposure in AI-driven environments.
To effectively protect sensitive information in the modern SaaS and AI ecosystem, organizations need visibility not only into the data itself, but also into the environments and identities interacting with it.
In modern SaaS environments, employees frequently connect third-party tools through OAuth integrations, browser extensions, AI assistants, and automated workflows. Many of these applications operate outside traditional IT visibility, creating a growing ecosystem of shadow SaaS and AI services that can access corporate data.
Without clear insight into which applications are trusted, which identities interact with them, and how those connections are used, security teams struggle to determine whether data access is legitimate or risky.
Introducing the ORION <> Grip Collaboration
To address these challenges, ORION and Grip Security are working together to deliver deeper context and stronger protection for modern data environments.
Grip provides organizations with visibility into the rapidly expanding ecosystem of SaaS and AI applications. By mapping identities, applications, OAuth integrations, and activity across the environment, Grip helps security teams understand which tools interact with corporate data, whether those environments are trusted, and how they are used.
ORION builds on this foundation by protecting sensitive data as it moves across the organization. As a fully automated, AI-driven Data Loss Prevention (DLP) platform, ORION monitors data movement across endpoints, SaaS applications, web interactions, email, and cloud environments. By analyzing rich behavioral and contextual signals, ORION detects data loss indicators and stops risky actions in real time.
Together, the two platforms provide a more complete approach to data protection in the age of SaaS and AI. Grip delivers the identity and application context needed to understand where data is being accessed and which environments are involved, while ORION provides the behavior-driven protection needed to prevent sensitive data from leaving the organization.
“DLP becomes exponentially more powerful when you understand environments around the data.”
“ORION brings groundbreaking DLP capabilities to identify and classify sensitive data. By combining that with Grip’s visibility into trusted and untrusted SaaS and AI environments, we give security teams the full picture: who is accessing data, through which applications, and whether that activity is expected. That context is what turns data protection from alerts into real risk reduction.”
Lior Yaari, CEO and Co-Founder of Grip Security
Instead of choosing between visibility and enforcement, organizations gain both: clear insight into how SaaS and AI tools interact with corporate data and the ability to stop risky behavior before it becomes a data loss incident.
What This Means for Security Teams
Together, Grip and ORION help organizations secure sensitive data across the modern SaaS and AI ecosystem without hindering AI adoption.
By combining Grip’s identity-first visibility into SaaS and AI environments with ORION’s behavior-driven data protection, security teams gain both the context needed to understand risk and the ability to stop it in real time.
This allows organizations to:
Identify shadow SaaS and AI applications interacting with corporate data
Understand who is accessing sensitive information and through which applications
Distinguish trusted environments from potentially risky ones
Detect unusual behavior involving sensitive data across SaaS, endpoints, and web interactions
Prevent data exfiltration into untrusted AI or SaaS platforms before it happens
Instead of relying on static policies or limited visibility, security teams can adopt a more adaptive data protection model that understands both the data’s context and the behavior around its use.
As SaaS adoption continues to accelerate and AI becomes embedded into everyday workflows, protecting sensitive data requires more than monitoring files and enforcing policies. It requires understanding how people, applications, and data interact across the entire environment.
Ready to see Grip and ORION in action?
Contact us to learn how the combined solution can help secure your SaaS and AI ecosystems and prevent real-time data loss.
As cybersecurity professionals working in the DLP space, we tend to gravitate toward the newest threats. We expect ourselves to be able to cover each new threat, and our customers expect it as well. Shadow AI, chatbots, copilots, and external AI platforms are among the most popular topics we hear about from customers.
But in focusing on the future, we risk missing an uncomfortable truth: some of the most fundamental, elementary threats of DLP were never truly solved.
DOGE employee steals Social Security data via USB Drive
A recent whistleblower complaint reported that a government employee allegedly copied large amounts of Social Security data before leaving their position. The case is still under investigation, but the alleged method of exfiltration is copying the database onto a USB drive.
No sophisticated AI prompt injection, no complex cloud misconfiguration – two databases, called “Numident” and the “Master Death File,” that, according to The Washington Post, could include records for “more than 500 million living and dead Americans, including Social Security numbers, places and dates of birth, citizenship, race and ethnicity, and parents’ names.”
For anyone working in data security, this scenario is nothing new. Despite years of investment in data loss prevention tools and insider risk programs, basic exfiltration methods remain highly effective.
Nothing New Under the Sun
This isn’t an isolated case. In fact, many high-profile data incidents over the past few years have involved insiders abusing legitimate access rather than sophisticated external attackers.
In 2025, Coinbase customer support agents working with access to internal systems were bribed by attackers to provide customer data, including personal information and partial Social Security numbers, affecting a portion of the company’s users.
There are dozens of other examples out there. The pattern repeats across industries: when someone already has access to sensitive information, exfiltration doesn’t have to be sophisticated to be extremely damaging.
We talk about AI data exfiltration – The news talks about USB drives
None of this should be interpreted as downplaying the risks of AI-driven data exfiltration. If anything, the opposite may be true.
AI may ultimately represent one of the largest data-loss risks organizations have ever faced. The problem is that we currently have a visibility gap.
Security discussions tend to focus on incidents we can actually observe – yet a large portion of AI-related data exposure may still be happening outside the scope of what organizations can currently detect.
This is just one example that surfaced publicly. It’s unlikely to be the only one.
Just as with shadow IT a decade ago, the incidents we talk about most are the incidents we can see. AI-assisted data exposure, on the other hand, often occurs in ways that leave little trace within traditional security controls. The risk, in other words, may be real and growing, but much of it may still be invisible.
Remembering the Basics
The rise of AI absolutely introduces new data loss risks, and organizations should be addressing them.
But the lesson from this case is clear: DLP was never solved properly, and the fundamentals of data protection still matter today as much as they did before AI changed the threat landscape. The question is, what are security teams doing about it?
Traditional DLP approaches often focus on channels – blocking USB drives, monitoring email, scanning web uploads, or restricting access to specific applications. While these controls are important, they also illustrate a deeper challenge: every time a new technology appears, security teams must race to build yet another control for yet another channel.
But the core problem hasn’t changed – data loss rarely happens because a specific technology exists. It happens because someone with access to sensitive data decides – intentionally or accidentally – to move it somewhere it shouldn’t go.
That’s why many organizations are beginning to shift their thinking toward understanding context and intent, rather than focusing exclusively on the mechanism of transfer.
The threat landscape will continue to evolve. New technologies will appear, new workflows will emerge, and new channels for data movement will inevitably follow, but if the past decade has taught us anything, it’s that solving DLP requires understanding why data is being moved in the first place – and whether that action makes sense in its context.
The threat landscape may evolve, but the basic problem of people walking away with sensitive data hasn’t disappeared. As security professionals, we should certainly prepare for the next generation of threats, but we shouldn’t assume the previous ones are behind us.
