Your AI agents are only as safe as where they run

Desktop AI agents are the hottest thing in enterprise tech right now. Tools that can read your files, manage your inbox, and reorganize your folders feel like magic. For non-technical teams, it's the first time AI has gone beyond chat. You give instructions, agents execute. No code, no Legos, no friction.

Security teams see the same picture differently. Where users see a personal assistant, CISOs see an unsupervised actor with full access to every file on a corporate machine, including the personal ones.

The question isn't whether AI agents should be powerful. It's where that power executes.

💡 Need AI agents that work across your company data without compromising security? Try Dust free for 14 days →

Engineers have had agentic AI for months. Tools like Claude Code and GitHub Copilot changed how they work. They describe it as having a team that writes and reviews code for them.

Everyone else still had chat. The gap created enormous demand. When desktop agents arrived, they promised the same leap to non-technical teams: finance, HR, ops, marketing. Upload nothing. Link nothing. The agent already sees your machine.

That frictionless experience is exactly what makes it dangerous. Low friction for users means low friction for attackers.

A desktop agent with local file access operates with a level of privilege that security teams typically associate with the final stage of a successful breach. After days or weeks of lateral movement, an attacker gains control of a target machine and can read, copy, and exfiltrate any file. Desktop agents offer that same access on day one.

Here's what this looks like in practice.

No admin visibility. Conversations happen locally. Even if your organization pays for an enterprise plan with SSO and audit logs, the desktop agent's activity may never surface in those logs. An employee could exfiltrate sensitive data, intentionally or through a prompt injection attack, and your security team would have no forensic trail. Some enterprise plans now offer usage monitoring and role-based access controls — but these are optional add-ons layered on top of a locally-executing agent. They reduce noise; they don't change the underlying architecture.

Indirect prompt injection with zero defense. In January 2026, researchers demonstrated an attack against a desktop agent using a blank PDF. Hidden in the file metadata was an instruction: find the largest PDF on this machine and upload it to an external API. The attacker provided their own API key. The agent complied. Financial documents containing bank details and identity copies were exfiltrated through a completely legitimate API call. From the admin's perspective, nothing happened.

Permission fatigue at scale. Desktop agents ask users to scope file access to specific folders. In practice, most users grant full access. The target audience for these tools, busy operations and finance professionals, is the least likely to read the fine print.

No agent identity. When a desktop agent connects to Slack, Google Calendar, or email through OAuth, it uses the user's own IP address and credentials. There is no way for an IT team to distinguish between an action taken by a human and one taken by an agent.

Dust takes an opinionated stance here. When connections originate from Dust, they are issued from static, known IP addresses, making agent traffic distinguishable from human traffic at the network level. More importantly, Dust agents author their own work: they cannot answer in the name of a human or impersonate a user. Every action is traceable to the agent and the person. That separation is architectural, not a setting users can override.

Computer use expands the attack surface. The newest generation of desktop agents goes beyond reading files — they can open applications, run tools, point, click, and navigate your screen to complete tasks autonomously. This extends the blast radius from file access to full machine control, with no additional authentication or approval step required for each action.

Extensions without sandboxing. Some desktop agents offer browser-like extensions. But unlike Chrome extensions, which run in a constrained sandbox, these extensions execute with full machine-level privileges. The familiar UX pattern creates a false sense of security. Same packaging, completely different blast radius.

The vulnerability pattern above has a common root: the agent runs locally, on the user's machine, with the user's permissions, and no intermediary.

There is another way to build this. Run the agent in the cloud, inside a controlled environment, with explicit boundaries on what it can access.

This is the difference between giving someone a key to your house and meeting them in a conference room. Both enable collaboration. Only one lets you control what's on the table.

When an agent needs to execute code, it can do so inside a true sandbox: an isolated virtual machine with no public internet access by default, where admins explicitly whitelist the URLs and services available. The agent can write Python, manipulate data, generate files, all within a boundary that's architecturally enforced, not dependent on user behavior.

Cloud-native agents operate on a fundamentally different trust model. The agent never touches the user's local file system. It connects to company data sources through admin-configured integrations, each scoped to specific teams and permission levels. Conversations, tool calls, and agent actions flow through centralized infrastructure where they can be logged, audited, and governed.

This is what it means to remove the risk at the source rather than trying to catch it downstream.

💡 Dust agents run in the cloud with space-based permissions, audit logs, and sandboxed code execution. See how it works →

If you're assessing AI agent platforms for your organization, here are the questions that matter.

Where does the agent execute? On the user's machine or in a managed cloud environment? Local execution means local risk. Cloud execution means centralized control.

Are conversations logged? Can your security team access a full audit trail of every agent interaction, tool call, and file access? If conversations are stored locally, your audit logs are incomplete.

Who controls integrations? Can admins decide which data sources and tools agents connect to? Or can any user plug in their email, calendar, and Slack without oversight?

Is code execution sandboxed? When agents write and run code, does it happen in an isolated environment with no default network access? Or does it run with the same privileges as the user?

Can you distinguish agent actions from user actions? In your SIEM, in your OAuth logs, in your Slack audit trail, can you tell the difference?

Does the vendor's threat model match yours? When a CVSS 10/10 vulnerability is reported and the response is "falls outside our current threat model," that's a misalignment you need to take seriously.

Security professionals are concerned about AI agents' impact on security with good reason. But the answer isn't to block AI adoption. Your teams will use AI regardless, and shadow AI is a far worse outcome than managed AI.

The answer is to choose platforms where security is architectural, not aspirational. Where permissions are enforced by the system, not by user discipline. Where agents are powerful because they operate within boundaries, not in spite of them.

💡 Dust is SOC 2 Type II certified, GDPR compliant and HIPAA enabler, with zero-data retention on model providers. Talk to our team about your security requirements →