For nearly a decade, enterprise security architecture followed a simple rule: wherever work went, controls went with it. When applications moved to the cloud and SaaS, security vendors built Cloud Access Security Brokers, Data Security Posture Management platforms and network Data Loss Prevention tools to watch the channels those workloads travelled through. Browsers produced traffic that proxies could inspect. SaaS platforms exposed APIs. Cloud providers opened their environments. Security teams could plant a flag at each crossing point and call it coverage.
That model is now under pressure from a different kind of shift. AI has no interest in being tidy. Workers at every level of the enterprise are performing sensitive tasks through desktop AI applications, coding assistants, autonomous agents, terminals and MCP connections. These tools sit directly on the device and touch source code, financial models, customer records and internal documents before any browser, SaaS API or network appliance gets a look-in.
The Cloud-Era Stack Was Built to Watch Channels
The cloud-era security stack was designed to monitor channels. It assumed that data movement would pass through predictable inspection points: a web proxy, an API gateway, a CASB, a DLP sensor on the network. Those controls remain useful, but AI activity often has no channel to watch until the interesting part is already over. That is not a hypothetical gap. It is a structural one.
Consider a developer who connects an internal MCP server to an external MCP service while wiring up an agent workflow. Information can move between the two as a normal part of the agent doing its job. There is no browser session, no file upload dialog, nothing resembling the click-trail that legacy tooling was built to correlate. Network monitoring sees a connection. It does not see the process behind it, the file it opened, or the reason it reached out. The device sees all three, and it sees them while there is still time to do something about it.
The problem is not that cloud controls are useless. The problem is that they answer a different question. They can tell an organisation that traffic left a network boundary. They cannot tell whether that traffic was a harmless prompt or a customer database, because the context that would distinguish the two has already been stripped away by encryption, application design, or simple distance from the device. By the time a packet reaches a network sensor, the who, what, why and from-which-file have often vanished.
Useful AI Needs to Know Things
Useful AI, it turns out, needs to know things. A coding agent that does not understand that a developer’s repository is not a toy may try to read an entire codebase, credentials and all, unless the right permissions and controls are in place. A finance-team assistant is only as good as the models and forecasts it is allowed to see. Every step that makes an AI tool genuinely useful is a step that pulls sensitive data closer to the device. Every step in that story takes data further from the control points built for the cloud era.
Agent memory compounds the problem. Information ingested at one step can quietly steer an action several steps later. Data access and data egress stop being the same event that security can treat as a single, correlatable moment. The agent may read a document today and use that knowledge tomorrow, in a different process, against a different destination. Traditional controls that look for a file leaving a network boundary are not built to follow that thread.
This is why the debate about shadow AI misses the point. The risk is not only unsanctioned tools. It is that sanctioned AI tools are designed to consume context. A coding assistant needs repository access. A finance assistant needs forecast data. A customer support agent needs account history. Each permission is reasonable in isolation. Together they create a mesh of data flows that no single gateway can understand. The endpoint is where those permissions become actions.
Desktop AI Applications Add Architectural Insult
Desktop AI applications add insult to architectural injury. Some use certificate pinning, which means they reject the substitute certificate a TLS-inspecting proxy hands them. The traffic sails past, encrypted and unbothered. The organisation is left watching bytes leave a laptop with no idea whether they are a harmless prompt or a customer database. By the time anything reaches the network, the context that mattered—which file, which process, which application, which intent—has evaporated.
The certificate-pinning problem is a symptom of a larger trend: AI applications are increasingly built as self-contained clients that do not want to be inspected. They may use their own update channels, their own encrypted storage, their own credential stores. They are not browsers, and they are not SaaS apps. They are endpoints in their own right. Security teams that try to force them into a proxy-centric model will find themselves blind to exactly the workflows that carry the most sensitive data.
This is where separate, siloed tools quietly fail at the one job that matters: telling risky apart from routine. A data security product might know the organisation holds sensitive credentials. An endpoint product might know an AI application is running. A network product might see an outbound connection. None of them, on its own, knows enough to make the call. Source code moving between two sanctioned developer tools is Tuesday. The same source code landing in a personal AI account is a resignation letter waiting to happen. Only context, not a keyword match on ‘source code,’ can tell the two apart.
Why Blunt Blocking Does Not Scale
Blunt blocking does not scale either. Rules that fire on content alone cannot distinguish a sanctioned workflow from a leak. Rules that fire on destination alone miss the fact that even an approved AI service can receive data it has no business seeing. Crank up the false positives and administrators loosen the policy. Security shifts from prevention to forensic archaeology. Everyone gets a very detailed incident report about the data that has already left the building.
Agents make that lag genuinely dangerous. Software can execute more actions in the time it takes a SIEM to correlate an alert than a human could manage in a working week. The speed of agentic AI turns a familiar detection-and-response problem into a timing problem. A control that understands an action only after the data has moved is not security. It is an expensive obituary.
The Endpoint Is Where Context Still Lives
The uncomfortable, sensible conclusion in the new universe of AI is that the endpoint is where the context still lives. It can see sensitive data before it becomes encrypted traffic. It can see the process reaching for it. It can see what that process intends to do next—all while the information is still sitting on a machine the organisation actually controls, rather than halfway across the internet.
That does not mean the endpoint is a magic bullet. It means the endpoint is the last place where identity, process, file, application and intent can be observed together. Cloud and network controls can see that something happened. The endpoint can see what is happening and, in some cases, stop it before it finishes. In an agentic world, that difference is the difference between a policy and a post-mortem.
This does not mean every AI action should be blocked. It means every AI action should be understood. The endpoint can supply the context that network and cloud tools lack: which user, which device, which application, which file, which permission, which destination, and which behavioural baseline. With that context, security teams can allow the routine and interrupt the risky. Without it, they are left with binary choices—block everything or allow everything—and neither is acceptable in a competitive enterprise.
Questions CISOs Should Be Asking
CISOs mapping this out should be asking a tougher and blunter question than ‘where is our data?’ They should ask which AI applications can touch local files. Which agents can reach the repository? What has been wired up over MCP? At what point does visibility actually disappear? More often than not, that exercise surfaces a timing problem dressed up as a visibility problem.
Many organisations already have pieces of the answer. Endpoint agents know which processes are running. Data security tools know where sensitive information lives. Identity systems know who is allowed to access what. But if those signals remain in separate consoles, the enterprise still cannot answer the only question that matters at the moment of action: is this specific AI process, touching this specific file, sending it to this specific destination, doing something the business has sanctioned or something it will regret?
The answers will not come from a single dashboard. They will come from integrating endpoint telemetry with data classification, identity, and AI governance. The goal is not more alerts. The goal is fewer, better decisions at the moment of action. That requires a shift in architecture, not just a new rule set. It requires treating the device as a first-class control point for AI-era security.
From Channel Coverage to Intent Coverage
The shift from channel coverage to intent coverage is not a small product tweak. It changes the centre of gravity for enterprise security. For a decade, the industry chased the workload into the cloud. It now needs to walk itself back to where the workload actually is. That place, awkwardly, is the laptop sitting three feet from wherever you are reading this.
In the era of agentic AI, zero trust starts at zero distance. The endpoint is not a legacy relic. It is the new control plane for data, identity and intent. Security teams that recognise this early will have a chance to protect AI-driven work without blocking it. Those that do not may find themselves with excellent forensic records of data that has already left the building, moved by an agent that never needed a browser to do it.
Source: Computerweekly News