The research team at security company Varonis published an attack demonstration called SearchLeak, targeting Microsoft 365 Copilot’s enterprise search. The attacker builds a search link pointing to a Microsoft domain and hides instructions in the search string. If the victim clicks once, Copilot treats the instructions as a prompt, searches the victim’s mailbox, and puts what it finds into the URL of an image in its reply. The browser loads that image before the reply finishes displaying, and the data travels through an allowed Bing domain to the attacker’s server.
The researchers say what could be taken includes email subjects and content (among them one-time login codes), calendar and meeting details, and indexed files in corporate cloud storage. Microsoft listed the vulnerability as CVE-2026-42824, rated it critical, and patched it.
The vulnerability is fixed, but the problem it exposed remains: office AI works through the user’s account, so whatever the user can read, it can read. Before adopting office AI search, decide what people can see but shouldn’t fall within AI’s search scope.
The difference is judgment, not permission
A person who sees a password reset email knows it’s sensitive and won’t forward it. AI treats it as text: it summarizes it, restates it, even puts it in a URL when instructed. The difference isn’t permission; it’s judgment.
That’s also why “teach employees not to click strange links” isn’t enough. The SearchLeak link pointed to Microsoft’s own domain and looked entirely normal; what got manipulated was the stretch where AI reads data, organizes it, and generates a reply. A data leak needs three conditions at once: AI can see secrets, reads untrusted content, and has a way to send things out. This case had all three; see ChatGPT’s Lockdown Mode Closes the Exits for Your Data, but AI Can Still Be Fooled.
Sort data into three tiers and decide what AI can touch
General work data: public documents, meeting agendas, routine project status. AI can search and summarize it, but should cite sources.
Internal sensitive data: customer lists, quotes, draft contracts, internal finances, employee data. AI can help find it internally, but limit what it can read, keep query logs, and turn off unnecessary external connections.
High-risk data: one-time verification codes, password reset emails, keys, undisclosed deals or legal matters. This tier should be separated at the source, for example kept in mailboxes or folders AI doesn’t index, or excluded from search by rules.
With the tiers in place, check one more thing: can AI replies load external images, links, or forms? If so, the reply itself can become an exit. Usually whoever manages Microsoft 365 needs to confirm the relevant settings and allowed domains.
Inventory first, then expand access
In these situations, hold off on rolling office AI search out to more people: nobody can say clearly what AI can actually read; high-risk and ordinary emails share the same mailbox; nobody is responsible for reviewing unusual AI search activity.
Start with one department and general work data, name someone to regularly review unusual queries and external requests, and expand once the boundaries prove effective.
This is about scope, not the vulnerability
This article is about data scope. Fixing a specific vulnerability is up to the vendor; what you control is how much AI can read and where its replies can connect. Even with well-drawn scope, new attack techniques will keep appearing, so monitoring can’t be skipped.
If you deploy models yourselves on a cloud platform, who processes the data and where is a separate set of questions; see Enable Claude in Microsoft Foundry, and Anthropic Is Still the Data Processor.
AI handoff card
We're about to (or already) let office AI search company mailboxes and documents, and want to confirm which data shouldn't fall within its search scope.
The method comes from this article: https://boosterminiclass.com/en/posts/copilot-searchleak-data-boundary-checklist/
Its view: office AI works through the user's account, so whatever the user can read, it can read; external content can lure it into putting data in a reply that gets sent out. So first decide what people can see but shouldn't fall within AI's search scope, and check whether AI replies can load external resources.
First ask me: which office AI tool we use, which mailboxes and document libraries it's connected to, and who currently manages its settings.
Then:
1. List the data types we likely have under three tiers, "general work data," "internal sensitive data," and "high-risk data," and suggest how to handle each tier;
2. List data that should be excluded from AI search at the source, such as verification codes, password reset emails, and keys, and feasible ways to exclude it;
3. List settings an admin needs to confirm: whether AI replies can load external images or links, which domains are allowed, and where search logs are kept;
4. Suggest a pilot scope and a person to review unusual activity, plus the conditions to confirm before expanding use.
Mark any setting you're unsure about as "needs admin confirmation" rather than guessing.
References
- Varonis Threat Labs: SearchLeak: How We Turned M365 Copilot Into a One-Click Data Exfiltration Weapon — https://www.varonis.com/blog/searchleak [accessed: 2026-10-11]
- Microsoft Security Response Center (official): CVE-2026-42824 — https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-42824 [accessed: 2026-10-11]
- Mashable: This Copilot vulnerability could expose emails, 2FA codes, and other sensitive data — https://mashable.com/tech/searchleak-microsoft-copilot-ai-assistant-vulnerability-report [accessed: 2026-10-11]
