The incident isn’t the story. The architecture that made it possible is.
Varonis Threat Labs disclosed CVE-2026-42824 last week – a vulnerability chain in Microsoft 365 Copilot Enterprise they named SearchLeak. The mechanics: a crafted link, one victim click, and the target’s own AI assistant harvested emails, MFA codes, calendar events, and private files and transmitted them to attacker-controlled infrastructure. Microsoft patched it on June 4. The server-side fix required no user action.
The patch doesn’t answer the question SearchLeak raised. It closes one door in a building with the walls missing.
The Incident That Security Leaders Didn’t Know to Plan For
Here is what the SearchLeak chain looked like from the inside: a parameter-to-prompt injection embedded attacker instructions in a Copilot Search URL. An HTML rendering race condition allowed those instructions to execute before session security checks resolved. A CSP bypass using Bing SSRF – routing data out through a trusted Microsoft domain – let harvested content reach external attacker infrastructure without triggering browser security controls.
Three weaknesses. None individually critical. Combined, they turned the victim’s AI assistant into a fetch-and-forward agent operating under legitimate credentials, through trusted infrastructure, accessing authorized data.
Detection systems built around anomaly signals saw nothing. The access was authorized. The source was legitimate. The destination was a Microsoft domain in transit. Every heuristic said “this is normal AI-assisted work.”
The attack was undetectable because it was indistinguishable from what the tool is supposed to do.
This is a different problem than credential theft, malware, or network intrusion. Security programs have spent decades building controls around those threat models. SearchLeak operates in a space those controls weren’t designed to cover – and it does so using the organization’s own trusted infrastructure.
Why Enterprise AI Tools Are Now the Attack Surface That Matters
The reason AI assistants are valuable is the reason they’re dangerous. They have access to everything. That’s the product.
Microsoft 365 Copilot reads email to draft replies. It searches file repositories to surface relevant documents. It synthesizes calendar data to prepare meeting summaries. It accesses organizational knowledge to answer questions. The breadth of access is what users pay for. It is also what an attacker with the ability to inject instructions into a Copilot session can exploit.
SearchLeak used a URL parameter injection – a relatively unsophisticated entry point. The same principle applies to other injection vectors: documents the AI will summarize, shared files containing embedded adversarial content, data sources the AI ingests through connected integrations. Any input channel through which attacker-controlled content can reach the AI’s instruction context is a potential injection surface.
The implicit trust model that underlies most enterprise AI deployments makes this entire category of risk possible. The AI inherits the user’s permissions. If the user can access an email, the AI can access that email, summarize it, search it, and – if someone has found a way to inject instructions – exfiltrate it. The user’s authentication is the AI’s authentication. There’s no independent access governance layer between what the user is authorized to access and what the AI can be instructed to do with that access.
This was a deliberate architectural choice. It made deployment easier. It made the tools more capable. It also created the attack surface SearchLeak just demonstrated at enterprise scale.
Why Current Approaches Don’t Solve This
The standard response to a CVE disclosure is to patch the vulnerability, update detection signatures, and add Copilot to the scope of the next penetration test.
This response is insufficient for SearchLeak’s implications. The vulnerability is patched. The architectural condition that made it exploitable isn’t. And the researchers, adversaries, and nation-state actors who now understand that enterprise AI tools can be weaponized through instruction injection are actively looking for the next chain.
Traditional SIEM and behavioral analytics look for anomalies. AI-mediated exfiltration doesn’t produce anomalies. It produces activity that looks exactly like the AI doing what users expect it to do – retrieving and presenting information. The exfiltration signal is buried in traffic that looks entirely normal.
DLP and CASB tools detect large data transfers and unexpected destinations. SearchLeak moved modest amounts of targeted data through Microsoft’s own infrastructure. It didn’t trigger transfer-volume thresholds. It didn’t route to unknown external domains. It stayed within the envelope of what normal AI tool behavior looks like.
Zero trust network controls verify user identity and device posture. The user’s identity was valid. The device was clean. The session was authenticated. Zero trust, as traditionally implemented at the network layer, saw nothing wrong either.
The Architectural Response
There is one control that would have made this attack stop at the policy layer rather than the detection layer: access governance applied to the AI agent as a principal in its own right.
If the AI’s access to sensitive content is governed by explicit policy – what categories of data it can retrieve, under what operational context, for what permissible purposes – then instruction injection into the AI’s query context doesn’t automatically yield the injected query’s results. The policy engine evaluates the access request against the data’s attributes and the request’s context. An AI query for MFA codes, arriving via a search parameter rather than an authenticated user action, is a different kind of access event than a user retrieving their own authentication codes. A data policy engine that treats AI agent queries as a governed access class can distinguish between them.
This is attribute-based access control applied to AI agents – treating the AI as a principal with its own access policy rather than an extension of the user’s session. It requires classifying sensitive data with the metadata that policy evaluation needs, building policy rules that apply to AI-initiated access events, and generating audit records for AI data access with the same fidelity as human access events.
It also requires acknowledging that the implicit trust model – AI as user proxy – is no longer adequate for the threat environment SearchLeak just demonstrated.
What Comes Next
SearchLeak won’t be the last disclosure in this category. Security researchers understand prompt injection. They understand SSRF. They understand how enterprise AI tools access organizational data. They are now actively looking at every major enterprise AI platform through the lens that Varonis applied to Copilot.
The organizations that get ahead of this are the ones that treat AI data governance not as a future roadmap item, but as a present operational requirement. The tools exist. The architecture is understood. The gap is organizational will – the willingness to apply the same rigor to AI agent access that has always been applied to human access.
The question was never whether AI would become an attack surface. The question was how long it would take the rest of the security industry to design controls that fit.
About the Author
Tim Freestone is Chief Strategy Officer at Kiteworks, where he focuses on the intersection of AI governance, data security, and regulatory compliance. He writes regularly on AI agent risk and data-layer architecture.
