Enterprise Copilot Exfiltration: The Quiet Data-Loss Channel of 2026

The story of 2026 in enterprise security is not another zero-day. It is the fact that almost every knowledge worker in the Fortune 2000 now has an in-suite copilot — Microsoft, Google, Salesforce, ServiceNow, Notion, Atlassian — with read access to the same corpus the employee has, and a natural-language interface that flattens years of access-control nuance into a single prompt.

The result is a data-loss channel that is fully authenticated, fully logged, and almost entirely invisible to classic DLP.

Why classic DLP misses it

Traditional DLP watches egress: SMTP attachments, browser uploads, USB writes, unusual download volumes from SharePoint. An authenticated copilot query does none of that. It reads server-side, summarises server-side, and returns the answer inline in a chat pane the DLP agent does not inspect.

The employee did not download the M&A folder. They asked, "summarise the pending deals I have access to and rank them by close date". The copilot did the download inside the tenant.

The four patterns we're seeing

1. Scope-collapse queries

The employee has technical access to thousands of documents they have never opened. The copilot opens all of them at once and produces a synthesised answer. A single prompt now surfaces information that would previously have required weeks of manual browsing.

2. Cross-app joins the identity model never anticipated

The copilot joins mail, CRM, ticketing and file storage in one answer. Each source system was governed independently. The join was never risk-assessed because it never existed as a product before.

3. Indirect prompt injection through inbound content

A shared document, a calendar invite, or an inbound email carries instructions the copilot follows on the user's behalf — forward this thread, share that folder externally, add this address to a distribution list. The user never sees the instruction; the audit log shows the user did it.

4. Prompt-history as a secondary corpus

Employees paste sensitive material into the copilot to "summarise" or "rewrite" it. That prompt history is retained, indexed, and — on several suites — searchable by admins, discoverable in eDiscovery, and occasionally used to fine-tune tenant-scoped models. The corpus grows without anyone owning it.

What actually works

• Copilot-aware access review. Re-run least-privilege reviews assuming the user will ask a natural-language question that fans out across everything they can technically read. Most 2019-era access grants do not survive this test.
• Content provenance on inbound documents. Treat every externally-authored document as untrusted input to the copilot, not just to the human. Strip or flag instruction-like content before it reaches the model.
• Prompt-and-response logging with retention tied to data class. If the copilot can read regulated data, the prompt and the response are regulated data. Log them, retain them, and include them in DSAR and eDiscovery scope from day one.
• Egress detection on synthesised answers. Modern DLP vendors are shipping detectors that inspect copilot responses in the chat pane. Turn them on; they catch the scope-collapse pattern that server-side scanners miss.
• Tenant-scoped red team. Once per quarter, have an internal team ask the ten most dangerous questions your copilot can technically answer. The results become the next quarter's access-review backlog.

The uncomfortable part

Every control above assumes the organisation actually knows which copilots are enabled in which tenants. In practice, most do not. The first artefact of a serious 2026 copilot-security programme is a tenant-by-tenant inventory of which AI features are on, which data classes they can reach, and which admin flipped the switch.

If you cannot produce that inventory in an afternoon, the exfiltration channel is already open — you just have not been asked about it yet.