Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Mergers and acquisitions (M&A) concentrate risk into a narrow window. The moment a deal is announced, employees with access to proprietary research, source code, and unreleased product plans face pressure and opportunity at the same time. Some update their resumes. A smaller number decide to take something with them: a research file, a pricing model, or a customer list before the transition is final. For compliance and security teams, the challenge goes beyond stopping data exfiltration.

Security teams that roll out Microsoft Purview DLP inside their Microsoft ecosystem often assume coverage extends further than it does. Policies apply cleanly to Word, Excel, and Outlook. Then a sensitive.dwg is inspected only by extension because Purview doesn't scan CAD content, a developer on a Linux workstation falls outside endpoint coverage entirely, or raw source code moves to a USB drive without matching the source-code classifier, which runs on the endpoint only for Office and PDF files.

Building guardrails for AI agents sounds like a policy problem but it is actually a data problem. You cannot enforce boundaries on behavior you cannot see. And you cannot govern identity for actors you have not discovered. That dependency chain is what most enterprise security programs miss in 2026, and it is where exposure quietly accumulates. A human employee who mishandles sensitive data creates a containable event. An AI agent with the same permissions creates a different problem.

An analyst pulls up the DLP console expecting to see alerts on the source code, customer records, and financial data employees paste into ChatGPT, Copilot, and a dozen other AI tools every day. Instead, the console is quiet, because the policies enacted by the legacy DLP system were built to catch file transfers and email attachments. But, none of the above traffic looks like a file transfer.

Enterprise AI adoption has outpaced enterprise AI governance. Seventy-eight percent of organizations now use AI in at least one business function, up from 55% the year before, and most of that adoption happened before governance teams finished drafting their first policy. The result is a familiar pattern: leadership approves a rollout, security builds guardrails around the tools it knows about, and sensitive data keeps moving through channels nobody mapped.

AI agents now retrieve data, generate recommendations, and trigger actions across enterprise systems with little human review in between. That speed is the point, and it is also the problem. A single manipulated prompt or a poisoned data source can push an AI system toward a decision no one signed off on, and most security teams have never tested for it. Building a red team exercise for AI workflows is how you find that gap before an attacker does.

Security teams are approving large language model (LLM) deployments faster than they can build the controls necessary to govern them and protect vital, sensitive data. Employees paste customer records into ChatGPT, engineering teams connect internal APIs to coding assistants, and business units stand up retrieval systems against production data, often without formal review.

Security leaders evaluating cloud access security broker (CASB) and data loss prevention (DLP) tools often discover the two categories overlap just enough to create budget friction and just little enough to leave real gaps. A CASB can flag risky file-sharing behavior in Salesforce without ever inspecting the content inside the file. A traditional DLP tool can classify that same file as containing source code without knowing whether the sharing link is public.

Most security programs have a working model for responding to shadow AI: identify the unsanctioned tools employees are using, sanction or block them, and update the acceptable use policy. That model worked, however imperfectly, when the threat was limited to web-based GenAI applications. It does not work when the threat is an autonomous agent, running locally on an endpoint, that reads the file system, calls external APIs, and transmits internal data.

Most data security programs are built around regulated data: social security numbers, payment card information, protected health information. The compliance frameworks demand it, the tooling is built for it, and breach notification laws make the stakes impossible to ignore. But intellectual property (IP) rarely triggers a regulatory deadline, which means it rarely gets the same level of protection, even though its loss can be far more damaging to a businesses bottom line, reputation, and productivity.