Desktop AI Changed the Security Boundary

For most of the history of consumer AI, the security model was relatively easy to understand. You opened a website, typed or pasted something into a box, uploaded whatever files you wanted the service to see, and received a response. There were legitimate privacy questions inside that model, but the boundary itself was relatively obvious: if I did not provide a client repository to the browser application, the application was not wandering through my workstation looking for it.

Desktop AI agents change that relationship considerably. Applications such as Cursor, Claude’s desktop tooling, and OpenAI’s Codex are increasingly designed to work inside the developer’s environment rather than wait for carefully selected snippets to arrive through a prompt. They can inspect repositories, search files, execute commands, understand project structure, interact with browsers, and, depending on the product and permissions granted, operate through other applications and developer tools.

That capability is enormously useful. It is also a materially different security model.

This is not really about AI training

A surprising amount of the privacy conversation around AI collapses into one question: is my data being used to train the model? That is an important question, but it is nowhere near sufficient for evaluating a desktop agent.

Cursor’s Privacy Mode, for example, prevents customer data from being used for training by Cursor and its model providers, subject to documented exceptions such as abuse investigations.⁷ Cursor also states that prompts and code context are sent through its infrastructure and to model providers when AI features require them, because processing the code is how those features work in the first place.^7,9

OpenAI similarly provides data controls around Codex, with business products excluded from model training by default and separate settings governing whether full Codex environments may be used for training.³ Anthropic applies its own commercial data commitments while documenting that Claude can access local files, browser content, applications, and other resources when the user grants those capabilities.^4,5,6

Those are meaningful protections, but “not used for training” does not mean “never accessed,” “never transmitted,” “never processed,” or “never temporarily stored.” Those are separate questions, and an organization evaluating an AI development tool should be asking all of them.

The real change is ambient context

A traditional web application generally knows what I deliberately give it. A local development agent can know what exists around the thing I gave it, and that surrounding context is often where the most sensitive information lives.

A repository does not contain only source code. It contains dependency choices, naming conventions, infrastructure patterns, database schemas, internal API references, comments, TODOs, branch history, deployment configuration, customer identifiers, architectural compromises, logs, and sometimes credentials somebody absolutely swore they were going to remove six months ago.

The workstation surrounding that repository can be even more consequential. It may contain Git credentials, SSH configuration, cloud CLI sessions, database clients, environment variables, shell history, VPN access, mounted drives, internal documentation, browser sessions, package-manager credentials, and neighboring repositories belonging to completely different clients.

An agent does not need to be malicious for any of that to matter; it only needs sufficient access.

We have started giving AI real operating-system authority

OpenAI’s own documentation is unusually direct about this. In describing the Windows sandbox built for Codex, OpenAI says that Codex runs on developer laptops through the CLI, IDE extension, and desktop application, and that it “runs with the permissions of a real user by default.”² The company explains that the coding agent may run commands, read or edit files, create Git branches, and interact with development tooling, which is precisely why OpenAI built operating-system-level sandboxing to restrict what the agent can modify and where it can communicate.^1,2

Anthropic describes essentially the same security problem from another direction. Claude Cowork can read local files, browse the web, run code, use applications, and, when computer use is enabled, directly click, type, navigate applications, and inspect the screen.^4,5 Anthropic explicitly recommends limiting access to the folders Claude actually needs and suggests using a dedicated working directory rather than granting broad access to sensitive files.⁴

Cursor necessarily faces the same architectural problem because the value of an AI-native IDE comes from understanding a codebase rather than treating every prompt as an isolated snippet. Cursor documents that it reads a project’s codebase to power its features and provides .cursorignore as a way to block certain files and directories from AI features.¹⁰

The interesting part is the limitation Cursor documents immediately afterward: terminal and MCP server tools used by Agent are not constrained by .cursorignore in the same way.¹⁰ Cursor also warns that complete protection of ignored files is not guaranteed because of LLM unpredictability.¹⁰

We have therefore moved from a model that looks like this:

Here is some code. Help me with it.

to a model that increasingly looks like this:

Here is an agent operating inside the environment where my code lives.

Those are fundamentally different trust models.

Close

Capability is not evidence of collection

This distinction matters because security discussions become useless when legitimate risks are inflated into accusations that cannot be substantiated.

Claims that desktop AI applications are silently collecting clipboard history, keystroke timing, open-window titles, or .env contents are certainly technically imaginable for sufficiently privileged local software. However, vendor documentation does not establish that Claude, Cursor, or Codex broadly collect those categories in the manner sometimes claimed.^3,7,8,9

That is an important line to maintain. The fact that an application could access information does not establish that the vendor is secretly collecting it, and an observation surface is not the same thing as documented telemetry.

I do not need to allege malicious collection to have a security concern. If software has the technical ability to access information that it does not need for the task I assigned it, then I have created an unnecessary trust dependency, and that is already enough to justify a better boundary.

For a personal hobby repository, perhaps I accept that dependency. For somebody else’s intellectual property, I use a very different standard.

The Semantic Dance: Capability vs. Exploitation

When corporate communications gate these concerns behind legal language, they rely heavily on shifting blame to the operating system’s architecture. They argue that because an IDE technically inherits user permissions to run compilers or parse files, any ambient vulnerability is an OS trait rather than an active application collection strategy.²

While it is strictly true that an observation surface does not inherently equate to exploitation, the risk vectors are real. A desktop application running natively on your machine possesses the authorization profile required to view environmental configurations, clipboard payloads, and peripheral layout hooks. The security challenge is not just what the company promises to collect today via telemetry policies, but what the local client architecture exposes to interceptive flaws, local prompt injections, or future unannounced feature expansions.

What independent security research has actually found

Vendor documentation is useful for understanding the security model a company intends to provide, but it is not the same thing as observing the software at the boundary where those promises meet a real workstation. Independent researchers have now done enough of that work that the discussion does not need to remain hypothetical. None of the findings below prove that Anthropic, Cursor, OpenAI, or another vendor is deliberately conducting broad surveillance of its users, but they do demonstrate something more relevant to the argument here: once an agent has meaningful local authority, failures in configuration, trust, sandboxing, or context handling can turn that authority into access the user did not knowingly intend to grant.

Check Point: Claude Code crossed the trust boundary before the user did

In February 2026, Check Point Research disclosed a set of vulnerabilities in Claude Code involving project configuration, Hooks, MCP servers, and environment variables. The researchers demonstrated paths to arbitrary command execution and API credential theft through malicious project files, including an attack in which a repository-controlled ANTHROPIC_BASE_URL redirected Claude Code’s API traffic to an attacker-controlled endpoint.¹¹

The part I find more interesting than the headline vulnerability is what Check Point observed while instrumenting the client with mitmproxy. According to the researchers, Claude Code initiated several requests before they had interacted with the workspace trust dialog, and those initialization requests appeared to include repository file names and recent commit messages; every request they observed also contained the authorization header carrying the Anthropic API key.¹¹ In the vulnerable configuration they demonstrated, an attacker could therefore prepare a repository so that simply launching Claude Code in that directory redirected those requests and the API credential before the user had decided to trust the workspace.

That distinction matters enormously to the premise of this article. A trust dialog is a user-interface representation of a security boundary, but Check Point demonstrated a case where meaningful network activity had already occurred on the other side of that conceptual boundary. Anthropic fixed the disclosed vulnerabilities after coordinated disclosure, which is exactly what a responsible vendor should do, but remediation does not erase the architectural lesson: the software had enough authority and enough project-controlled configuration to create an exfiltration path before the user believed authorization had been granted.¹¹

This is also why I am reluctant to treat “the user must approve access” as a complete answer to the desktop-agent problem. Approval is only a useful control if the implementation makes it impossible for consequential activity to precede, bypass, or outlive that approval.

Cursor: the sandbox has already been escaped

Cursor’s public GitHub security advisories provide an unusually concrete record of what can go wrong when an AI agent, a local terminal, a workspace, and the operating system meet. In June 2026, Cursor disclosed two critical desktop sandbox escapes affecting versions before 3.0. One involved symlinks and failed path canonicalization; Cursor’s advisory states that a malicious agent could write arbitrary files outside the workspace under the user’s privileges and use that ability to reach non-sandboxed remote code execution, with no user interaction beyond a benign prompt.¹³

A second critical advisory published the same day concerned an agent-controlled working directory. Cursor’s sandbox granted write access to a command’s working directory, but the agent could manipulate that parameter so the sandbox included paths outside the intended workspace. Cursor again described the impact as arbitrary writes outside the workspace under the user’s privileges, with a path to non-sandboxed remote code execution and no interaction beyond an apparently benign prompt.¹⁴

Those are not theoretical criticisms of an AI company’s privacy policy; they are documented failures of the technical boundary that was supposed to keep an agent inside its workspace. They were found, disclosed, and patched, but they establish why I am unwilling to equate “sandboxed” with “incapable of reaching anything outside the sandbox.” A sandbox is software, software has defects, and an agent specifically designed to manipulate files, paths, tools, and commands gives defects in that layer unusually consequential leverage.

Cursor has also documented a different class of failure involving prompt injection and command authorization. A March 2026 advisory describes a chain in which malicious instructions on a website could influence Cursor Agent and bypass its command whitelist, resulting in arbitrary command execution even when Auto-Run was configured to use an allowlist.¹² The important point is not that every Cursor session is vulnerable to arbitrary websites; the advisory describes specific affected versions and conditions, which Cursor patched. The point is that the intended control was explicit command authorization, while the practical failure mode allowed untrusted content interpreted by the model to participate in defeating that authorization.

That is a qualitatively different problem from a conventional desktop application accidentally reading the wrong file. The component making the security decision is operating on natural-language context that may contain instructions originating from sources the user does not perceive as executable. Once that component also possesses terminal authority, a prompt-injection problem can become an operating-system problem.

Close

Trail of Bits: the model’s context is itself part of the attack surface

Trail of Bits’ MCP research gets closer to what I think is the central architectural problem. In its April 2025 work on what it calls “line jumping,” Trail of Bits showed that a malicious MCP server could place prompt-injection instructions inside its tool descriptions, which MCP clients load into the model’s context when discovering the tools the server provides.¹⁵ The malicious tool did not first need to be invoked; the instructions could influence the model simply because the client had connected to the server and populated the context.

That undermines an intuitive human assumption about agent security: that a tool cannot hurt me until I approve its use. Trail of Bits demonstrated that the description of the tool can itself become hostile input, allowing an MCP server to influence how the model uses entirely different tools or commands. Their testing included Claude Desktop, and their examples included potential code exfiltration, manipulation of generated code, and suppression of security information.¹⁵

A follow-up Trail of Bits experiment made the human-oversight problem even less comfortable. Testing Claude Code 0.2.76, the researchers found that ANSI terminal escape sequences embedded in MCP tool descriptions and outputs could hide malicious instructions from the developer while leaving those instructions visible to the model.¹⁶ In other words, the person and the agent could receive materially different versions of what appeared to be the same terminal interaction: the human could see innocuous output while the model continued processing concealed instructions.

That matters because “human in the loop” is frequently offered as the fallback security mechanism for agentic systems. If the model can see instructions the human cannot see, or if malicious context can arrive before a tool invocation requiring approval, then the human is not necessarily reviewing the same decision surface the agent is operating on. A confirmation dialog may still be useful, but it is no longer sufficient evidence that informed consent occurred.

Trail of Bits also found a more conventional but equally relevant problem in the MCP ecosystem: credential material stored locally in ways that made it unnecessarily easy to read. In April 2025, the firm reported that Claude Desktop’s MCP configuration on macOS was created with permissions that allowed other local users or processes to read plaintext API keys stored there, and that Cursor and Windsurf conversation logs they tested were similarly stored with world-readable permissions.¹⁷ Their broader investigation found multiple MCP tools relying on long-lived API keys in plaintext configuration rather than operating-system credential stores or narrowly scoped OAuth tokens.

This last category is useful because it brings the argument back to something very ordinary. The danger is not always an exotic model exploit. Sometimes the agentic ecosystem simply creates more credentials, more configuration, more logs, more integrations, and more predictable places where sensitive information accumulates on the workstation; once those resources exist, any process sharing the user’s access domain may have a much larger collection of valuable targets than it did before.

This is the distinction I care about

None of these disclosures proves the inflammatory version of the story: that every desktop AI vendor is intentionally vacuuming up clipboard contents, keystrokes, .env files, open-window titles, or every repository it can see. I still would not make that claim without evidence.

What these disclosures do establish is that the distance between “the application technically has access” and “information or authority escaped the boundary the user thought existed” is not academic. Researchers have demonstrated credential exfiltration through project configuration, commands executing outside intended authorization paths, writes escaping workspace sandboxes, hidden prompt instructions influencing an agent, and locally stored secrets or conversations receiving weaker protections than a security-conscious developer might reasonably expect.^{11,12,13,14,15,16,17}

That is the part that changes my threat model. I do not need to believe a vendor intends to misuse the authority I give its software; I need to accept that the authority exists, that agentic systems deliberately combine untrusted context with powerful local tools, and that independent researchers have already shown multiple ways the intended boundaries around those tools can fail. Once the source code or credentials involved belong to somebody else, “the vendor says it is safe” and “the vendor patched the last vulnerability” are useful facts, but they are not substitutes for controlling access on my side of the relationship.

The client-code problem

This becomes considerably more important for consultants, agencies, contractors, fractional technical leaders, and development firms because the code sitting on our workstations frequently does not belong to us.

A client repository may physically reside on hardware I control while the intellectual property inside it belongs entirely to the customer. In that situation, “am I comfortable giving this application access?” is not necessarily the right question.

The better question is:

Am I actually authorized to give this application access?

There is a chain of custody involved. A client gives my company access to proprietary source code so that we can perform contracted work; my company gives an employee access because that employee needs the repository; the employee then installs an AI coding agent and exposes the project because the agent can improve productivity.

At each step, another system or principal may gain the ability to process information. Maybe the contract permits it, maybe the vendor’s enterprise agreement adequately protects it, or maybe the environment has been isolated sufficiently that the exposure is negligible, but none of those things should be assumed merely because the AI tool happens to be convenient.

This is where the discussion stops being abstract privacy anxiety and becomes ordinary information governance. The property is not mine to casually give away.

Privacy settings are policy; boundaries are architecture

I like privacy modes, and I enable them.⁷ I also care about data-processing agreements, zero-retention commitments, enterprise controls, encryption, audit logs, and contractual restrictions on model training.^7,8,9

Those controls govern what happens after software has been allowed to interact with information. A filesystem boundary solves a different problem because it determines whether the software can reach the information in the first place.^1,2,4

If an AI agent cannot access a client’s repository, then I do not need to rely exclusively on a privacy policy to prevent that repository from being processed. If it cannot read my SSH directory, I do not have to reason through how SSH credentials might be handled, and if it cannot reach another customer’s project, I do not have to trust that an accidental context expansion will never cross that line.

This is not a new security concept. We have spent decades building systems around least privilege precisely because trusted software can still make mistakes, integrations can be compromised, users can misconfigure applications, and downstream components can behave in ways the person at the keyboard never intended.

AI should not receive an exemption from that principle simply because giving it more authority makes the experience more convenient.

Ignore files are useful, but they are not the boundary I want

Mechanisms such as .cursorignore, .gitignore, application blocklists, workspace exclusions, and similar controls are useful.¹⁰ They help communicate intent to the application and reduce the amount of unnecessary context the agent can encounter.

I would not, however, make an application-level ignore file the primary security control protecting sensitive client material. Cursor’s own documentation is a useful illustration of why: its ignore mechanism applies to several AI features, but terminal and MCP tooling can operate outside that particular protection.¹⁰

There is a meaningful difference between telling an application, “please do not read this directory,” and configuring the operating system so that the application cannot read the directory.² The first is policy; the second is a security boundary.

For sensitive work, I want filesystem ACLs, sandboxing, separate identities, isolated working directories, controlled network access, or some combination of them underneath the AI application.^1,2,4 The application can still have its own privacy settings and exclusion rules, but those become additional layers rather than the thing standing between a client repository and an unintended access path.

There is also a supply-chain problem

Modern AI agents increasingly execute commands rather than merely suggesting them.^1,2,4 Once an agent can invoke package managers, shells, build tools, MCP servers, browsers, connectors, and development environments, the security model extends well beyond the company that trained the model.

A malicious package can affect the environment. A compromised MCP server can affect the agent.^4,10 Prompt injection hidden inside a repository, webpage, issue tracker, email, or documentation system can influence an agent that has access to other systems.^4,5

Anthropic explicitly warns about this class of problem in its Cowork safety documentation, including the possibility of prompt injection and the movement of information between applications when computer use is enabled.^4,5 OpenAI’s own internal Codex deployment similarly relies on sandboxing, network restrictions, approval policies, credential controls, rules, and telemetry rather than simply trusting the model to behave correctly.¹

That is the correct direction because “I trust Anthropic,” “I trust OpenAI,” or “I trust Cursor” is not a complete security model. There are too many components in the chain, and even trustworthy vendors build systems on top of operating systems, extensions, packages, developer tools, APIs, MCP servers, browsers, and third-party infrastructure.

The environment itself needs boundaries.

Close

How I think about desktop AI now

My own rule has become fairly simple: an AI agent should receive the minimum filesystem, process, network, and application authority necessary to perform the work I deliberately assigned to it.^1,2,4

That means treating an AI coding tool more like another developer account than another text editor. In practical terms, I want:

• explicit project-level filesystem permissions rather than implicit access inherited from my primary user account;^2,4
• read-only access by default, with write access deliberately granted where necessary;²
• client repositories isolated from one another;
• secrets and credential stores kept outside agent-readable project paths;^4,10
• terminal execution constrained to the same security boundary as filesystem access;¹⁰
• network access treated as a permission rather than an assumption;^1,2
• visibility into which files, tools, commands, and services an agent actually touched;^1,4
• application privacy and training controls enabled in addition to technical restrictions rather than substituted for them;^7,9
• sensitive work performed under business or enterprise agreements when contractual data protections are required;^3,9
• and enough separation that compromising one project does not automatically expose every other project available to the person sitting at the computer.

None of this requires believing that AI companies are malicious. It requires acknowledging that the applications they are building are becoming extremely capable.

The better the agent gets, the more important the boundary becomes

The irony is that this problem grows precisely because the software gets better. An AI system that can only autocomplete a function is not especially interesting from a permissions standpoint, while an agent that can understand an entire repository, launch the application, inspect its output, query a database, search documentation, observe a browser session, identify a defect, and modify six files to repair it is extraordinarily useful.^2,4,5

It is also extraordinarily privileged, and I think much of the current discussion around AI security is still behind this transition. We spend enormous amounts of time arguing about whether a model remembers a conversation while quietly installing agents capable of operating inside environments where companies keep some of their most valuable intellectual property.

The answer is not to stop using them; I certainly do not intend to. The answer is to stop treating them like chatbots, because they are becoming local operators, and local operators need boundaries.

That distinction is also a large part of what pushed me toward building Scylla Workbench. I wanted explicit control over what an AI agent could reach rather than treating my logged-in desktop identity as an acceptable security perimeter, and when the property belongs to a client, I want custody and access to be things I can enforce technically rather than promises I hope every layer of the stack continues to honor.

Sources

1. OpenAI, Running Codex safely at OpenAI, May 8, 2026.
2. OpenAI, Building a safe, effective sandbox to enable Codex on Windows.
3. OpenAI Help Center, How your data is used to improve model performance.
4. Anthropic Help Center, Use Claude Cowork safely.
5. Anthropic Help Center, Let Claude use your computer in Cowork.
6. Anthropic Help Center, Claude Cowork architecture overview.
7. Cursor, Data Use & Privacy Overview, updated September 3, 2026.
8. Cursor, Security, updated August 25, 2026.
9. Cursor Docs, Privacy and data.
10. Cursor Docs, Ignore File.
11. Check Point Research, Caught in the Hook: RCE and API Token Exfiltration Through Claude Code Project Files | CVE-2025-59536 | CVE-2026-21852, February 25, 2026.
12. Cursor / GitHub Security Advisory, Arbitrary Code Execution via Prompt Injection and Whitelist Bypass (CVE-2026-31854), March 9, 2026.
13. Cursor / GitHub Security Advisory, Cursor Desktop sandbox escape via symlink and failed path canonicalization (CVE-2026-50549), June 5, 2026.
14. Cursor / GitHub Security Advisory, Cursor Desktop sandbox escape via agent-controlled working directory (CVE-2026-50548), June 5, 2026.
15. Trail of Bits, Jumping the line: How MCP servers can attack you before you ever use them, April 21, 2025.
16. Trail of Bits, Deceiving users with ANSI terminal codes in MCP, April 29, 2025.
17. Trail of Bits, Insecure credential storage plagues MCP, April 30, 2025.