The Endpoint: Where Data, AI, and Human Risk Now Converge

For at least the last decade, security architecture was built around channels security teams could control. Data moved into cloud platforms, where APIs gave tools direct reach. Work moved into SaaS, SaaS ran in the browser, and browser traffic passed through proxies and gateways where policy could be enforced.

AI broke that model. 

It has distributed our work across channels and created fragmented environments that siloed tools can no longer keep up with. Cloud and network controls lose visibility and context as more activity happens locally. And AI is increasing the volume and speed of that activity past what alerting and manual review can absorb. Together they force a shift from detection to prevention, and prevention needs context, control, and speed in the one place all three can exist: the endpoint.

How AI has shifted work (and risk) to the endpoint

With AI, work is spreading out of controlled channels and onto the device itself, across desktop apps, agents, CLI sessions, MCP connections, and local files. Sensitive data is moving with it, and the endpoint is becoming the place where data, users, and AI converge. There are three important shifts happening on the device.

More sensitive data is moving locally

To use AI for real work, employees bring real company data into the workflow: source code, financial models, customer records, production data. The interaction itself now happens on the device, including the prompt, the transformation, the file access, and the agent action. Agents extend the risk further, because data shared with them persists in working context and can move again in a later step, through a different tool and a different destination than the original prompt.

Agents and the CLI produce no session to inspect 

An agent reading a folder, a coding assistant in the terminal, or an MCP connection reaching an internal system produces no browser session, URL, or call to a sanctioned SaaS app. That activity is visible only on the device: the process that ran, the files it touched, the commands it executed. MCP sharpens this. An internal MCP server connected to a company repository can be linked to an external or personal service, creating a path for data to move out and for the external side to reach back in.

Desktop AI applications can block proxy inspection

Desktop AI apps, operating-system copilots, and IDE assistants often use certificate pinning: the application trusts only its own certificate and rejects the substitute a TLS-inspecting proxy presents. If the app is unmanaged, the proxy can't inspect the traffic. No policy change fixes this. It's a limitation of the control point itself.

Why traditional data security tools are failing

Traditional tools were designed around specific layers of the environment. CASB monitors traffic to sanctioned cloud apps. DSPM classifies data at rest in cloud storage. Network DLP inspects traffic crossing the wire. That model worked when the important action passed through one of those control points. As work moves onto the device, each tool sees only part of what happened.

An employee pulls data from a production system, modifies it locally, zips it, and sends it through another application. One tool sees the source, another the destination, another the network traffic. None has the full sequence, and the sequence is usually what determines whether an action is risky.

Consider two uploads to the same unmanaged AI tool. In one, an employee uploads a personal document. In the other, the employee opens a sensitive internal file, screenshots it to strip its original identity, renames it, and uploads the new version. From the network, those events look nearly identical. On the device, they are completely different, because everything that distinguishes them happened before the upload.

Sensitivity alone is no longer enough. Knowing what the data is matters, but so does knowing where it came from, what happened to it, who or what is acting on it, and where it's going. A tool watching one event at one chokepoint has no access to that.

AI makes detection and manual review impossible

Visibility is only half the problem. AI is also increasing the volume of activity teams have to evaluate. Prompts, pastes, file reads, agent actions, MCP calls, uploads, and commands now happen continuously across normal work. Most are legitimate, and a small share represent real risk.

Insider risk and DLP programs were already built around large alert volumes and manual investigation. AI breaks that model, because events grow far faster than the analysts reviewing them. If every action becomes an alert, the queue is unmanageable. If enforcement relies on broad rules without context, false positives interrupt real work until blocking gets turned off. Either way, the program gets better at documenting risk than preventing it.

Prevention is the only answer that scales. The decision has to happen at the moment of action, not in a queue afterward.

What this means for data protection

Preventing data loss is harder than detecting it, because the decision has to be right before the action completes. That requires two things at once:

• Context: understanding the data, its source, the user or agent involved, what happened to it, and where it's going.
• Control: the ability to stop the action at the point where it happens in real time. Before the data leaves.

As more work and AI activity move onto the device, the endpoint becomes the one place all three come together. It has the local context to see the full sequence and the control point to act before that sequence becomes an incident.

That is the design premise behind Bold: AI running locally on the endpoint to classify data by meaning, understand user and agent activity, and prevent risky actions in real time using the context available on the device.

Learn more about Bold to see what real-time, on-device data protection looks like against your own environment.