Claude Code launched Computer Use today. In one prompt, Claude can write code, compile it, launch the app, click through the UI, find bugs, fix them, and verify the fix.
Everyone is celebrating the productivity unlock. Nobody is talking about the new attack surface.
What Changed
Before today, Claude Code could read and write files. That's it. A prompt injection from a malicious dependency could write bad code to disk. Annoying, but contained. The blast radius was your filesystem.
After today, Claude Code can interact with any app you whitelist. Open a browser. Click through a GUI. Type into forms. The blast radius is now anything on your screen.
The Same Day, BeyondTrust Drops This
Hours before Anthropic's announcement, BeyondTrust Phantom Labs published a critical vulnerability in OpenAI Codex. The attack: command injection via GitHub branch names in task creation requests. The result: exfiltration of a victim's GitHub tokens to an attacker's C2 server, granting full read/write access to their entire codebase.
The attack vector was a branch name. Not a malicious file. Not a suspicious dependency. A branch name.
This is the pattern: AI coding tools inherit trust from user context (GitHub tokens, env variables, API keys) but don't treat that context as a security boundary. The tool is an agent with your credentials.
Why Computer Use Changes the Threat Model
Anthropic added app-level permissioning, which is the right first step. You whitelist specific apps and choose between look-only and full control. But let's think about what happens when things go wrong.
The old attack chain:
- Malicious dependency or compromised MCP plugin
- Prompt injection lands in a file Claude reads
- Claude writes malicious code to disk
- Developer (hopefully) reviews before shipping
The new attack chain:
- Same malicious dependency or MCP plugin
- Same prompt injection
- Claude now has access to whitelisted apps
- "Open browser, navigate to [exfil endpoint], paste clipboard" becomes a real attack path
- No file on disk to review. The action happened in the UI.
The attack doesn't need full desktop access. It just needs one whitelisted app.
The Confirmation Loop Problem
Everyone is excited about the "closed loop": write code, test it visually, fix bugs. But think about what this loop actually verifies.
Claude can see: "the button renders correctly." Claude can see: "the page loads without errors."
Claude cannot see: "this form sends credentials over HTTP." Claude cannot see: "this API endpoint has no auth check." Claude cannot see: "the database query is injectable."
Security vulnerabilities are invisible in the UI. A page can look perfect in every screenshot while leaking data through every endpoint.
Worse: the same model that writes the insecure code is now verifying it. That's not a closed loop. It's a confirmation loop. You need an adversarial check, not a self-review.
"Claude tested it and it works" is about to become the new "it compiles, ship it."
The LiteLLM Supply Chain Attack Is Still Fresh
One week ago, the LiteLLM supply chain attack hit 47K downloads in 46 minutes. The same attacker (TeamPCP) had already compromised Trivy and Telnyx. Malware hidden in a WAV file using steganography. MsBuild compiling inline C# at runtime. XOR-encoded payloads with no signatures to match.
These are packages that vibe coders pip install without lockfiles or hash pinning. 88% of LiteLLM's pip installs had no version pinning.
Now imagine that same compromised package running on a machine where Claude has Computer Use enabled. The injection doesn't just write to files anymore. It can interact with your apps.
What Should You Actually Do?
Whitelist the minimum. Don't add apps you don't need Claude to test. Every whitelisted app is attack surface.
Use look-only mode when you don't need click-and-type. If Claude only needs to verify visual layout, it doesn't need to click.
Don't trust the closed loop for security. Claude verifying its own output catches UI bugs, not security holes. Run a separate security check with a different tool or different model.
Pin your dependencies. Use lockfiles. Use hash verification. The supply chain is the entry point for most of these attacks.
Check what Claude is reading. If a malicious file lands in your project (through a compromised dependency, a PR, or an MCP plugin), Claude will read it. With Computer Use, it can now act on it.
This Isn't Anti-Progress
Computer Use in Claude Code is genuinely useful. Being able to visually verify what you build eliminates an entire class of "works in terminal, broken in browser" bugs.
But capability and attack surface are the same thing. Every new thing an AI agent can do is also a new thing an attacker can make it do, if they can inject the right prompt.
The security conversation needs to keep pace with the capability conversation. Right now, it's not even close.
I track vibe coding security tools, vulnerabilities, and the evolving threat landscape. Free security scanner at notelon.ai.
Top comments (0)