Analysis / Enterprise security · Blair Little · 10 min read

Enterprise AI needs DLP that follows the work

Companies need enforceable control over what employees send to AI, what assistants retrieve and where the results go. Making approved AI safer is a better ambition than leaving people to find their own way around a ban.

By Blair Little · Research checked 4 November 2026 · Publication candidate, not published

The company blocks an AI assistant. The deadline does not move.

An employee still needs to untangle a spreadsheet, explain some code or turn thirty pages into something another human might actually read. The work may simply move to a personal phone or an unmanaged shadow IT account, a few taps away from the corporate keyboard.

That is an illustrative scenario, not a measured finding about a particular workforce. But it exposes the weakness in treating an AI ban as the end of a security strategy. Blocking the approved route does not necessarily remove the demand. It can move the work somewhere the security team has less visibility and fewer controls.

The answer should be better enterprise AI protection, not a competition to see who can make the least useful corporate chatbot.

As an enterprise cloud and security engineer, I want employees to use capable tools inside enforceable information boundaries. The question is whether an organisation's existing data policies actually govern the work, rather than merely generate a report about it afterwards.

Enterprise AI should help us enforce our data rules, not make us choose between useful tools and control.

Illustrative design goal: company policy governs submitted information before AI processing, with further checks on onward transfers. This is a proposed architecture, not a claim of universal product coverage.
Illustrative design goal: company policy governs submitted information before AI processing, with further checks on onward transfers. This is a proposed architecture, not a claim of universal product coverage.

Enterprise security is not the same as complete DLP

Single sign-on, encryption, retention settings and commitments not to train on business content are valuable. So are application restrictions and audit trails. They answer important questions about identity, handling and accountability. OpenAI's enterprise documentation and Google's Workspace privacy commitments describe genuine safeguards. OpenAI controls, Google Workspace privacy

Data Loss Prevention asks another question: should this information be allowed into this action, for this person, at this destination?

A user can have legitimate access to a document and still be prohibited from sending its contents to an external service. A summary can remain sensitive after the original document's label has disappeared. A coding assistant can be approved while a particular transfer of source code is not.

The standard should therefore be consistent preventive enforcement across the organisation's chosen workflows: prompts, supported files, retrieval, generated content and tool actions. Coverage needs to be explicit, including what is excluded and what happens during an outage.

The evidence does not justify saying enterprise AI has no DLP. It does justify saying that a DLP integration, an enterprise subscription or a reassuring security page is not proof of that complete coverage.

A dashboard cannot unsend a document

Microsoft's published Purview capability matrices make the distinction unusually clear.

For its ChatGPT Enterprise and Claude Enterprise interaction integrations, Microsoft lists auditing, classification and several compliance functions as supported. It lists DLP and sensitivity labels as unsupported through those integrations. ChatGPT matrix, Claude matrix

Those tables do not say that organisations cannot protect ChatGPT or Claude by other means. They describe specific integration paths. But they do show why “integrates with Purview” is an incomplete answer to “will it block this disclosure?”

Discovering sensitive information in an activity record is useful. Preventing an unauthorised transfer is a different job.

Auditing records activity; preventive enforcement can stop a covered action. Both are useful, but one does not establish the other.
Auditing records activity; preventive enforcement can stop a covered action. Both are useful, but one does not establish the other.

Security teams should be able to ask for evidence of the rule evaluated, the verdict returned and the action actually prevented. A detection without an enforcement result can tell a very different story.

What the platforms actually protect

There is meaningful progress. There are also boundaries that procurement teams need to understand before signing the reassuringly expensive paperwork.

Approval of an enterprise web chat should not be treated as proof that the same DLP policies govern API consumption by custom agents. OpenAI’s documented Codex/AIRS integration excludes API-key sessions, and Claude’s enterprise inference hooks exclude Platform API access. The actual API path needs its own assessment. OpenAI API boundary, Claude API boundary

OpenAI: workspace controls can restrict apps, actions and supported content. Its documented Prisma AIRS integration adds preventive inspection for newly submitted Codex prompt text in covered workspace sessions. Files, images, assistant responses, tool calls and tool results are excluded from that integration, as are API-key sessions. That is a useful control with a defined surface, not universal ChatGPT and agent DLP. Codex/AIRS scope

Anthropic: Claude Enterprise inference hooks let an organisation's security service allow or deny governed requests before inference, with optional pre-execution tool-call validation. This is real preventive functionality. However, the request has already reached Anthropic; raw image content and Platform API access are excluded, redaction is unsupported, and some request paths are not governed. It is a substantial capability, not a reason to stop checking coverage. Inference hooks

Google: Workspace DLP can restrict Gemini's use of Drive content in named experiences and editions. That particular rule excludes Gemini Enterprise and Gemini in Chrome. Crucially, this does not mean Gemini Enterprise has no separate protection. Workspace DLP scope

Google separately documents Gemini Enterprise Sensitive Data Protection for supported sources, custom MCP content and file uploads, including certain classification labels. This capability excludes the Business edition and has content, source and size limits; audio and video uploads are not scanned. Those distinctions matter when someone says simply “Gemini has DLP.” Which Gemini, which edition and which workflow? Gemini Enterprise protection

Microsoft: Copilot has preventive Purview controls for supported sensitive prompts and labelled content. Sensitive-prompt blocking remains in preview with tenant rollout conditions. The described Copilot DLP location does not scan the contents of files uploaded directly into prompts. Copilot DLP documentation

Organisations may need complementary endpoint and browser controls to cover those interactions. Purview Endpoint DLP can restrict sensitive clipboard operations and prevent protected files being accessed through specified unapproved browsers. That is an additional enforcement layer with its own device, application and policy requirements, rather than proof that the cloud control covers the transfer. Endpoint DLP controls

These examples establish a fragmented coverage problem. They do not establish that every deployment is unsafe or that no combination of controls can meet a particular organisation's needs.

Follow the whole workflow

Plugins are one example of why this gets difficult. They are not the whole story.

Imagine an approved assistant uses a retrieval-augmented generation (RAG) pipeline to fetch a confidential SharePoint document. In this example, the connector uses delegated Microsoft Graph access through Entra ID: its access is limited by both the granted permissions and what the signed-in user may read. That correctly authorises retrieval; it does not automatically enforce destination policy on the generated summary. Delegated access explained

Now imagine a filter checks the result only after an independent connector has retrieved the document. It may stop the AI host receiving the content. It cannot undo the connector's earlier access.

Illustrative policy placement: checking before retrieval can prevent disclosure to a connector; checking afterwards protects a later recipient.
Illustrative policy placement: checking before retrieval can prevent disclosure to a connector; checking afterwards protects a later recipient.

That is architectural reasoning, not an allegation of misuse. The same reasoning applies when a user pastes information, uploads a file, uses an IDE assistant or runs an agent through an API. The boundary being protected must match the point where the check happens.

External endpoint, browser, network and gateway controls can be part of a sound design. Their existence does not establish coverage of every desktop client, mobile session or service-to-service request. Equally, a missing capability in one compliance connector does not invalidate those other protections. Microsoft's own enterprise guidance points to separate browser and network routes. Purview guidance

The useful question is not “does somebody somewhere sell AI DLP?” It is “does our policy govern this exact path?”

Make the approved route worth using

Blanket restrictions can be necessary for particular data or unacceptable services. They are much less convincing as the entire long-term plan for AI adoption.

If employees cannot get useful work done through the approved tools, unofficial workarounds become tempting. Personal accounts, unmanaged devices and manual copying can move activity away from the controls the organisation paid for. This is a risk mechanism, not a claim that every ban causes a measurable increase in incidents.

The aim should be to make the governed route capable, understandable and easier to use responsibly.

Tell people which tools are approved, which information they may use and what to do when a legitimate task is blocked. Where possible, let them remove a sensitive field, choose an approved destination or request a bounded exception. A helpful explanation beats an unexplained error and a policy document last opened during induction.

Do not make the approved way the hardest way.

Better DLP will not cure every security problem. It can, however, make more AI workflows acceptable without asking staff to become experts in six vendors' permission models.

What I would ask an enterprise AI provider to demonstrate

Start with everyday work, not a theatrical attack involving seventeen agents and a villainous toaster.

Those are proposed acceptance tests, not tests performed for this article.

The design should reuse established organisational classifications and policies where supported. Administrators need enforceable limits that users cannot simply approve away. Users need clear feedback and safe alternatives. Both need documentation that admits where coverage ends.

Some mechanisms already provide parts of this design. The demand is to make those parts work consistently across the workflows enterprises actually deploy, rather than presenting a collection of separate safeguards as a finished answer.

Conclusion

AI platforms have made enormous progress in capability. Enterprise information governance needs the same urgency.

The gap is not an absence of security features. It is the distance between having features and proving that the organisation's data rules are enforced throughout its chosen AI workflows.

Better DLP is an adoption tool as well as a security control. It gives security teams a stronger basis to approve useful AI and employees a better option than finding an unofficial route around a ban.

I would love to take this beyond the page and put my enterprise security experience to work helping design and test these protections. If an AI platform team could use another pair of hands, my inbox is open.

Give businesses a safe way to say yes. Then make that yes mean something.

Methodology: Based on public documentation checked on 4 November 2026. No accounts were connected and no runtime DLP tests were performed. Product coverage varies by edition, configuration and workflow; the assessments here describe documented capabilities, not security certification.