Your Computer Use Agent Is a Security Disaster Waiting to Happen (Here's How to Fix It)

The Attack That Should Have Scared Everyone (But Didn't)

The ZombAIs attack is the clearest proof that computer use agents are a fundamentally different threat surface than anything IT security has dealt with before. Here's what happened: a researcher embedded a malicious prompt inside a normal-looking webpage. When Claude's computer use agent browsed to that page as part of an innocent task, it read the hidden instruction, connected to a remote command-and-control server, and started executing attacker commands. The agent never 'knew' it was compromised. It thought it was helping. This is called an indirect prompt injection attack, and it's not theoretical anymore. A 2025 academic paper titled 'A Systematization of Security Vulnerabilities in Computer Use Agents' confirmed these attacks evade conventional safeguards consistently. The problem is structural. A computer-using AI is designed to read its environment and act on what it sees. That's its whole job. An attacker who can put text anywhere the agent might look, inside a PDF, a webpage, an email, a calendar invite, can hijack the agent's next action. Traditional firewalls don't stop this. Antivirus doesn't stop this. Most enterprise security stacks weren't built for an agent that reads the screen and decides what to do next.

The 5 Security Mistakes Teams Make When Deploying a Computer Use Agent

• ●Running the agent with full user permissions: If your agent can access everything you can access, a compromised agent can exfiltrate everything. Least privilege isn't optional, it's the first line of defense. Scope your agent's credentials to exactly what it needs for the task and nothing more.
• ●No sandboxing or VM isolation: Gartner projects 40% of enterprise apps will include task-specific AI agents by end of 2026, but most are running them directly on production machines. An isolated cloud VM or container means a compromised agent can't touch your actual systems.
• ●Logging nothing: You can't audit what you can't see. Every action a computer use agent takes, every click, every keystroke, every file access, should be logged with a timestamp and tied to the originating task. If something goes wrong, you need a forensic trail.
• ●Trusting all input sources equally: Your agent should treat content from the web, emails, and documents as untrusted data, not as instructions. This distinction is the core defense against prompt injection. Most teams never configure it.
• ●Giving agents persistent credentials: Hardcoding API keys, login tokens, or passwords into an agent's context is a catastrophic mistake. Use short-lived, just-in-time credentials that expire after each task session. IBM's research found this single failure was a factor in the majority of AI-related breaches studied.

Sandboxing Is Non-Negotiable, and Here's Why Most Teams Skip It

The honest answer to why teams skip sandboxing is speed. Someone demos a computer use agent, it works great on a laptop, and the team ships it to production before anyone asks 'but what if it goes sideways?' Sandboxing feels like friction. It's not. Running your AI computer use agent inside an isolated VM or cloud container is the single highest-leverage security decision you can make. Here's the threat model: if a prompt injection attack hijacks your agent mid-task, the worst it can do inside a sandboxed environment is trash that one isolated session. Outside a sandbox, it has access to your file system, your saved browser credentials, your internal network, and every SaaS tool you're logged into. Anthropic's own engineering team published a deep-dive in October 2025 on how they sandboxed Claude Code, explicitly noting that without both network isolation and process isolation together, 'a compromised agent could easily escape the sandbox.' If the people who built the model are sandboxing their own agent, you probably should be too. The security community has also flagged that context manipulation attacks, where an adversary poisons the agent's memory or session history over multiple interactions, are now a documented threat vector per a June 2025 arXiv paper. A fresh sandboxed environment per task session eliminates this entire attack class.

What a Secure Computer Use Deployment Actually Looks Like

Let's get concrete. A properly secured computer-using AI deployment has five layers. First, isolated execution: the agent runs in a cloud VM or container that's spun up fresh for each task and destroyed after. No persistent state between sessions unless you explicitly and securely manage it. Second, least-privilege credentials: the agent gets only the permissions required for the specific task. Automating a report in Google Sheets? It gets read-write on that sheet, not your entire Drive. Third, input validation and source tagging: your orchestration layer should tag where each piece of content came from and treat web-sourced or email-sourced content as untrusted. Prompts that arrive through untrusted channels should never be able to override system-level instructions. Fourth, full action logging: every mouse click, every typed character, every URL visited, every file touched gets logged and stored. This isn't just for security audits, it's for debugging when the agent does something unexpected. Fifth, human-in-the-loop checkpoints for high-stakes actions: deleting files, sending emails externally, making purchases, transferring data outside the organization. These should require explicit human confirmation. The agent asks, you approve, then it acts. This architecture isn't complicated. It's just discipline. And most teams skipping it will find out why it matters the hard way.

Why Coasty Was Built With This in Mind

I'll be direct: most computer use agents on the market were built to be impressive in demos, not secure in production. Coasty is different, and the architecture reflects it. Coasty runs agents inside cloud VMs by default, which means your actual machine and your actual data stay completely separate from whatever the agent is doing. That's sandboxing built into the product, not bolted on as an afterthought. The agent swarm architecture, where Coasty can run multiple agents in parallel, also means each task gets its own isolated execution environment. There's no shared state bleeding between jobs. Coasty also supports BYOK (bring your own keys), so your credentials never touch Coasty's infrastructure if you don't want them to. You control the keys, you control the access scope. And on raw capability, Coasty sits at 82% on OSWorld, the definitive benchmark for real-world computer use tasks. Claude Sonnet 4.5, for comparison, scores 61.4% on the same benchmark. Capability and security aren't a tradeoff here. The most capable computer use agent is also the one that was designed to operate safely in real enterprise environments. That's not a coincidence.