Traditional DLP Wasn’t Built for AI. Here’s the Layer That Was

At a Glance

• What this covers:  Why traditional DLP cannot inspect an AI prompt, what it was built for instead, and what a runtime governance layer like Inhibitor by Systango does at the layer where DLP stops.
• Key finding:  Most enterprise security stacks include DLP. Almost none of them can read what an employee types into ChatGPT. That is not a configuration gap – it is an architectural one. DLP governs the channel. It was never designed to govern the prompt.
• Business impact:  An organisation can pass a DLP audit and still have employees sending confidential client data, financial terms, and personal information to public AI models every day – invisibly, unlogged, and outside every control the security team thinks is in place.
• What you’ll learn:  What traditional DLP was built to do, exactly where it stops when AI tools are involved, and what a runtime governance layer like Inhibitor by Systango adds at the layer DLP cannot reach

If your DLP covers AI prompts, how would you know?

Traditional DLP (Data Loss Prevention) tools were built to stop sensitive data from leaving an organisation through known channels: email attachments, file transfers, USB drives, web uploads. They were not built to read the unstructured content of a free-text prompt typed into a chat interface – and most of them cannot.

Inhibitor by Systango is the runtime governance layer built specifically for this surface – sitting between an organisation’s users, systems, and the LLMs they call, intercepting every AI interaction before it reaches a model. We will come back to what it does. First, the gap it fills.

In our previous piece on AI governance enforcement, we covered why a written policy cannot stop data leakage at the point of AI use. This blog addresses the follow-up question most security teams ask: “Don’t we already have DLP for this?” The short answer is no.

What traditional DLP was built to do

DLP software was built for a specific problem: preventing sensitive data from leaving an organisation through the channels that existed when the category was invented – email, file shares, network traffic, removable media, web uploads to known destinations. Within those channels, DLP works. It can scan an email attachment for credit card numbers. It can block a file upload to a personal cloud account. It can flag a document copied to a USB drive.

The Gartner definition of DLP has remained broadly consistent for over a decade: products that classify and protect confidential information, and prevent authorised users from accidentally sharing data that could put the organisation at risk. That definition assumes data moves through a predictable, structured channel. It was written before “sharing data” could mean typing a paragraph into a chat window.

Why DLP misses the AI surface entirely

When an employee opens ChatGPT and types a paragraph containing a client’s name, financial terms, and personal data, none of the conditions DLP was built to detect are present. It is not a file transfer. The traffic looks like standard HTTPS. No pattern matched. The content was typed, not attached.

In 2023, Samsung employees were found to have sent proprietary source code and meeting notes to ChatGPT on at least three occasions before the company became aware. Samsung had security controls in place. None of them caught it – because DLP was never positioned to inspect prompt content at inference time.

The AI surface spans more than the browser. Internal applications calling LLM APIs, direct API integrations built by engineering teams, and AI agents running automated workflows all send data to models – and DLP covers almost none of it.

What the gap looks like in practice

A UK legal team member, under time pressure, copies several paragraphs from a confidential file – client names, case references, financial terms – into an AI tool to get a faster first draft.

With DLP only: the interaction is invisible. The traffic looks like standard HTTPS. No file was transferred. No pattern matched. The content has left the organisation and nobody knows it happened. If a regulator later asks the firm to demonstrate its data protection controls, the honest answer is that nobody knows what was sent.

With Inhibitor in place: the prompt is intercepted before it reaches the model. Client names and case references are recognised and redacted automatically, or the request is paused. Either way, a log is created: what was attempted, what was in it, and what action was taken.

A control layer between people, systems, and AI

Inhibitor, the runtime governance layer Systango built, sits between an organisation’s users and systems and the LLMs they call. At the moment a prompt is sent – from a browser, an internal application, or an API – Inhibitor intercepts it before it reaches the model, classifies what it contains, applies policy in real time, and logs every interaction and decision in a tamper-evident record.

Unlike DLP, which operates at the channel layer, Inhibitor operates at the prompt layer – reading unstructured free text, recognising PII, financial data, and confidential business content, and acting before transmission rather than flagging after the fact. It covers browser tools, internal applications, APIs, and agentic workflows – the full AI surface DLP was never designed to reach.

Real-world Use Case

A regulated investment platform in India building AI systems across mutual fund advisory workflows had no visibility into what its AI models were receiving at the prompt level. Its stack – endpoint protection, network monitoring, access controls – had no control operating at inference time. The platform was subject to SEBI and AMFI regulations, the DPDP Act, PMLA requirements, and CERT-In obligations – all placing data handling requirements on what AI models reached. None of it was being enforced at the prompt level.

After implementing a runtime governance layer, every AI interaction across the platform’s workflows was intercepted, classified, and logged. The compliance team had a complete audit record for the first time. Full case study available here.

Source: Systango internal deployment data. 

View Inhibitor – or get in touch to understand how this works for your organisation.

What security leaders should ask before assuming DLP covers AI

• Can our DLP tool read the content of a free-text prompt sent to an AI tool – not just flag the destination domain?
• Do we have visibility into AI calls made by internal applications and APIs, not just browser-based tools?
• If an automated system sent customer records to an AI model last night, would we know?
•  Can we produce a log of what was sent to an AI model last week, by whom, and what it contained?
• Are the AI agents or workflows in our environment operating inside any defined governance boundary?

If more than one answer is “no” or “not sure,” the gap is not a DLP configuration problem. DLP was not built for this surface. What is missing is a control that operates at the point where AI interactions actually happen.

If more than one answer is “no” or “not sure,” the gap is not a DLP configuration problem. DLP was not built for this surface. What is missing is a control that operates at the point where AI interactions actually happen.