AI Coding Assistants Have a Browser Security Problem

We've spent years protecting browsers, managing developer workstations, and trying to keep credentials out of places they do not belong. AI coding assistants bring those same concerns together in applications that can read project files, browse content, and run commands, which makes their actual access worth examining before we approve them for wider use.

Forever Security's EMBRACE research, published on October 29, 2026, is a useful example of why that review matters. The researchers examined embedded browsers in Cursor, GitHub Copilot, Codex, VS Code, and Claude Desktop, and reported different failures involving command execution, misleading browser addresses, and access to local files.

For me, the important question is what an approved development tool can reach, and whether the controls we rely on cover each of its components. A browser preview may look like a convenient editor feature, but it still processes content that someone else controls.

What the researchers demonstrated

The five products did not share a single vulnerability, and the findings should not be treated as evidence that every installation can be compromised simply by being online. The affected feature, user interaction, application permissions, and surrounding configuration all matter.

In the Cursor demonstration, hidden page-supplied information reached the agent as instructions. Execution involved a user keystroke, and the agent retried an operation after its initial sandbox restriction. The researchers describe success as dependent on model behaviour.

The file-access findings are different. VS Code and Claude Desktop applied a project restriction to the page but did not enforce it consistently in a background web worker. Codex allowed the out-of-scope read directly from the page. Those demonstrations required opening a malicious local file in the affected preview; they did not establish a bypass of the operating system's underlying file permissions.

That distinction changes what I would investigate. Reviewing prompts and terminal approvals addresses only part of the problem when another component can read files without asking the agent to execute a command.

Supporting reference: Forever Security: EMBRACE technical overview ↗

Keep the remediation claims tied to their date

Forever Security's October 29 disclosure dates the Cursor fix to October 1 and the Copilot fix to October 13, in build 1.1.29. It describes the Codex and VS Code issues as unresolved at publication. For Claude Desktop, it records an accepted report through Noma Security without identifying a fixed build.

Those are the researchers' reported outcomes, not a current affected-version matrix independently confirmed by each vendor. I have not established a newer vendor-confirmed resolution for the remaining findings. Before making a deployment decision, obtain the current guidance for the exact product, platform, version, and preview feature in use.

I would record that evidence in the application's approval review rather than leave the team working from a headline. Where the remediation position cannot be established, decide whether the affected feature should remain available while the question is resolved. The fact that the application itself is approved does not settle that narrower decision.

Supporting reference: Forever Security: EMBRACE research, October 29, 2026 ↗

Workspace Trust and a sandbox do different jobs

Microsoft recommends opening unfamiliar VS Code projects in Restricted Mode, which disables agents in that workspace. Its security guidance also describes sandboxing for agent-executed shell commands and child processes, with network access configured separately. Those are useful controls, but their documented scope matters when assessing a browser component.

Trusting a repository is a decision to enable functionality for that project. It does not demonstrate that every page or dependency inside it is safe. Similarly, a command being blocked in a terminal sandbox does not tell us whether an embedded browser can read a file through a different path.

I would ask the application owner to explain which restrictions apply to the agent, the preview, extensions, and any connected tools, then verify the paths that matter to the business. If the answer is simply that the product is sandboxed, we have not yet established enough to approve its handling of sensitive material.

Approvals also need a sensible scope. A developer should be able to review an unusual operation without having to grant permanent permission for unrelated actions, and a prompt presented by a familiar application should still be assessed on what it actually authorizes.

Supporting reference: Microsoft: Secure AI-assisted development in VS Code ↗

Start with the workstation and the access it carries

The first practical task is to find the applications, versions, and people involved. Defender Vulnerability Management's software inventory is one starting point, although the default CPE filter can hide software without a CPE. Microsoft also notes that software without a CPE does not receive the same vulnerability-management information. An absent vulnerability entry is therefore not evidence that the application is safe.

I would combine that inventory with a short discussion with the development team: which embedded previews are used, which repositories are opened, and what credentials or authenticated sessions are available in that environment? A test workstation with synthetic data and an engineer's everyday machine with production access should not receive the same risk assessment.

Keep production credentials out of higher-risk development sessions where possible, and use scoped identities and short-lived credentials when the workflow supports them. If unfamiliar projects need to be examined in a VM or remote environment, review its mounts, shared folders, network access, and available secrets before treating it as isolated.

Intune Endpoint Privilege Management can help supported Windows users work without standing administrator rights while elevating approved tasks. That reduces one kind of exposure; it does not protect a private key or configuration file that the ordinary user can already read. Local privilege and access to sensitive identities need separate attention.

Supporting reference: Microsoft: Defender Vulnerability Management software inventory ↗

What Defender and Purview can contribute

Defender for Endpoint telemetry can help establish what happened around the application. DeviceProcessEvents describes process creation, while DeviceNetworkEvents records network connections and related activity. I would look for unexpected child processes and destinations, but I would not assume every internal file read produces a useful event or that every suspicious connection produces an alert.

Purview Endpoint DLP supports controls for specified sensitive-file activities, including restricted applications and supported browser scenarios. That makes it worth testing whether an application's access to protected files can be restricted. It does not establish that a custom embedded browser receives the same enforcement as a supported browser upload, or that every configuration file and developer token is classified as sensitive.

For each scenario, establish whether the file is protected by the intended policy, the user and device are in scope, and the relevant application or activity is supported. Then check the result in the actual application. A blocked upload in Edge is useful evidence for that browser path, but it is not a test of an embedded preview reading a local file and sending its contents through another mechanism.

I would also separate prevention from visibility in the findings. A connection appearing in hunting data, a DLP audit record being created, and a transfer being blocked are three different results, each with a different operational value.

Supporting reference: Microsoft: Endpoint data loss prevention capabilities ↗

A validation exercise that gives the team something useful

I would test the controls on a nonproduction device with harmless files and synthetic credentials, working with the people responsible for endpoint and network security. That gives the team a way to examine the application without exposing production repositories or real secrets.

Choose a representative application and version, document its configuration, and define the behaviour you intend to allow or prevent. That might include opening an unfamiliar repository, viewing local HTML, or attempting access to a designated test file outside the project. Where a transfer test is appropriate, use a controlled destination and synthetic content, then compare the application's behaviour with the endpoint and DLP evidence.

The review should record the requested action, whether it succeeded, which control made the decision, and what an analyst could see afterwards. Repeat the relevant checks after a fix or a material configuration change. If the only evidence is that the application opened successfully, the security question remains unanswered.

I would not use EMBRACE as a reason to ban every AI development tool. I would use it to revisit the access we have given those tools and the assumptions behind their approval. The useful outcome is a clear account of what the application can reach, what prevents it from going further, and who owns any gaps we decide to accept.