Data loss prevention (DLP) is still largely frozen in place. But what worked well in 2016 doesn’t work so well today. Back then, data loss occurred in recognizable ways. Someone sent an email, hackers gained access, or a file left the network. DLP tools focused on detecting those kinds of events. Today, data loss increasingly involves the prompt.
Why traditional DLP falls short
Jerod Brennen, CISSP, Co-Founder and CEO of Aetos One, has spent 25 years in cybersecurity. He describes how DLP challenges have changed. “DLP watches files leave. The prompt box lets data walk out the front door without a file in sight.”
His description of the underlying problem is equally useful: “Prompt-level exposure is a data governance problem wearing a new outfit. If a client has never classified customer records, credentials, source code, or contracts, no DLP product will know what to catch in a prompt either.”
Omair Manzoor, Founder and CEO of ioSENTRIX, a CREST-accredited offensive security firm, sees this firsthand in penetration testing engagements. “When an employee types ‘summarise this customer contract’ and pastes the full text into ChatGPT, no file has left the network. No attachment was sent. No upload occurred,” he said. “The data left through a text input field in a browser session, and legacy DLP has no mechanism to inspect, classify, or block it because it was never designed to analyse what someone types into a web form.”
How sensitive data leaves one prompt at a time
The fragmented nature of this exposure makes it even harder to catch. “An employee might not paste an entire database,” Manzoor said. “They’ll type ‘here are the last 20 support tickets, find the pattern’ and manually enter customer names, account numbers, and complaint details.”
That information can leave an organization one prompt at a time without triggering traditional pattern-matching rules. A single prompt may not contain enough structured data to raise an alarm. However, multiple interactions can reveal a broader picture of a client’s customers, operations, and vulnerabilities.
In ioSENTRIX’s assessments, developers commonly paste source code containing hardcoded credentials and API keys into AI coding assistants. Support staff may paste customer emails with personal data, account numbers, or payment details into ChatGPT to draft responses. Meanwhile, finance teams may upload transaction spreadsheets, and HR staff may paste performance reviews or compensation data. “None of this triggers legacy DLP,” Manzoor said, “because the data doesn’t match traditional exfiltration signatures. There’s no file transfer, no abnormal data volume, no connection to a known-bad destination.”
AI creates new data boundaries
Emily Hartstone, founder of Hartstone Institute and Runtime Authority Control, says the prompt box represents only the first of three data boundaries MSPs should consider. Most organizations focus on only one. “An employee may type a completely harmless prompt like ‘summarize the recent issues with this customer,’” she said. “If the assistant is connected to an inbox, CRM, shared drive and support system, the sensitive information may never have been typed into the prompt at all. The AI retrieved it because the connection already existed.”
That distinction matters for how MSPs build protection. Blocking sensitive information in prompts addresses only one direction of data flow. Connected AI systems may still retrieve the same information through existing permissions. “Organizations also need to know what each connected AI system can access, which credentials or permissions it holds, who granted them, how long they remain valid, and what happens when they are no longer needed,” Hartstone said.
What happens after AI accesses the data?
The third boundary involves what AI can do with information after retrieving it. “If an assistant retrieves confidential customer information, can it only summarize it for an employee who was already authorized to see it? Can it put it into an outbound email? Can it send it to another system? Can it trigger another workflow?”
Each action requires different permissions, yet most governance models don’t distinguish between them.
How MSPs can strengthen AI data protection
So, what can MSPs actually do about this now? Manzoor outlines a four-layer approach.
The first layer focuses on visibility. MSPs can use a cloud access security broker or DNS-level filtering to categorize and log connections to known AI platforms. “You can’t build policy around what you can’t see,” he said.
Browser-level inspection forms the second layer. “The next generation of DLP needs to operate inside the browser session, analysing what’s being typed or pasted into web forms before it’s submitted,” Manzoor said. “It’s the difference between watching the exits and watching the conversation.”
Approved tooling with guardrails makes up the third layer. Organizations can use enterprise AI tools with input filtering, interaction logging, and data retention controls.
Finally, the fourth layer focuses on testing, an area many MSPs haven’t addressed yet. “Include AI data leakage scenarios in your security assessments,” Manzoor said. “Can you extract sensitive data from the client’s environment through AI prompt interactions? If you don’t test for it, you don’t know whether your controls work.”
Brennen adds that the underlying governance layer matters as much as technical controls. For Copilot specifically, he says sensitivity labels on files are essential.
He offers a practical challenge for clients who assume their current DLP covers AI: “Show me what your DLP logged the last time someone pasted a customer list into a chat window.” The answer, he said, almost always ends the debate.
Closing the AI data security gap
Hartstone offers a practical framework for MSPs. Start by inventorying every AI tool and integration in use. Then, define what information should never enter an unapproved AI workflow and enforce those restrictions technically where possible.
Another step is reviewing connected AI systems separately from chat tools and distinguishing read authority from action authority. Organizations should also retain enough evidence to reconstruct consequential activity afterward. “The interface changed faster than the security model did,” Hartstone said. “Typing information into a prompt feels psychologically much more like asking someone a question than exporting corporate data to another system. That is exactly why a policy telling employees ‘do not paste sensitive information into AI’ is not enough by itself.”
For MSPs looking to close that gap, Barracuda AI Data Security inspects prompts and file uploads in real time. It can block, warn, or redact sensitive content before it leaves the environment. The solution also provides audit-ready evidence to show clients, insurers, and regulators that controls are working.
Photo: tete_escape / Shutterstock
