Right now, on a lot of developer laptops, an AI coding agent is holding the keys to that developer’s entire working life, reading text written by strangers, and sitting on an open internet connection. Security researchers have a name for that combination.
Three ingredients, one exploit
In June 2025, Simon Willison named it the lethal trifecta. An AI agent becomes exploitable when it has all three of these at once:
- Access to private data: anything an attacker shouldn’t see.
- Exposure to untrusted content: any text or image an attacker could have written, such as a web page, an email, a README, a GitHub issue, a skill file the agent loads or the output of a connector it calls.
- A way to communicate externally: any route for data to leave, from an HTTP request to a git push.
The cause is simple to state and hard to fix. Language models follow instructions, and they can’t reliably tell your instructions apart from instructions hidden in the content they read. Give an agent a poisoned document, something worth stealing and a way out, and an attacker can steer it to send your data wherever they like.
The research has caught up with the theory. A paper accepted at USENIX Security 2026 found that a single poisoned email was enough to get a frontier model, working inside a multi-agent workflow, to exfiltrate SSH keys more than 80% of the time.
Better filters won’t close it
The instinctive response is to add a guardrail that spots malicious prompts. Willison’s answer is that a filter catching 95% of attacks still loses, because attackers keep trying until they find the 5%. In his words, “in web application security 95% is very much a failing grade.” Sysdig’s guide to the problem reaches the same place: “adaptive attacks bypass essentially every published defense.”
So the fix Willison recommends is structural: make sure no agent ever holds all three ingredients together. Meta’s security team turned that into a working rule in October 2025, the Agents Rule of Two. Within a session, an agent should have no more than two of the three. If a task truly needs all three, the agent shouldn’t run unsupervised.
Now look at the laptop
Run the three-question test against an agent working on a typical developer machine.
Private data. SSH keys. Cloud CLI credentials. Signed-in browser sessions. .env files. Every repository the developer has ever cloned. At an agency, that last one means several clients’ code sitting side by side, so one compromised session can reach well past the project it was working on.
Untrusted content. READMEs, issues, pull request comments, dependency source code, error output, and any web page the agent fetches to look something up. Add the skill files that teach the agent new procedures and the connectors that give it new tools. Both are instructions from strangers, and both have already been used as attack vectors.
In February 2026, Koi Security found 341 malicious skills on ClawHub, the skill marketplace for the OpenClaw agent. The skill text looked clean. It told the agent to install a prerequisite, and the prerequisite was a credential stealer. Snyk’s ToxicSkills audit of nearly 4,000 skills found security issues in more than a third of them, including prompt injection written into the skill’s own instructions. Connectors carry the risk on both sides. In May 2025, Invariant Labs showed that one public GitHub issue could steer an agent using the GitHub MCP server into leaking private repositories. In September 2025, a fake Postmark MCP server on npm shipped fifteen clean releases, then added one line that blind-copied every outgoing email to the attacker, at around 1,500 downloads a week.
External communication. An open network connection, git push, curl, and any tool the agent can call.
All three legs are present, each at the largest size it can be. The machine also stays on. Anything an injected instruction plants there is still there tomorrow.
None of this takes a careless developer. It’s the default setup for local AI tooling, and it’s one reason we argued in Why You Need an Agentic Platform, Not More AI Tools that AI work shouldn’t live on individual machines. A recent AI Engineer talk from Coder makes the same first move for security reasons: before anything else, take the agent off the laptop.
What changes when the agent moves off it
In Launch Studio, every agent gets its own isolated microVM sandbox. Here is what that does to each leg.
Private data shrinks to one job
The sandbox holds the work in front of it and nothing from anyone’s laptop: no SSH keys, no browser sessions, no local credentials. When an agent works with GitHub, it acts with the requesting user’s own delegated permissions, never more than that user has. Our database, storage and deployment credentials are not in agent sandboxes at all.
Model access is narrowed the same way. All of an agent’s model traffic goes through our own AI gateway, and each run gets its own short-lived key with a spending cap and limits on which models it can use. Our master gateway key never enters a sandbox.
Every sandbox has an expiry date
Each sandbox has a hard maximum lifetime that organization admins set, anywhere from 10 to 60 minutes. When the time is up, the sandbox is gone, along with anything an injected instruction left behind. A compromised laptop stays compromised. A compromised sandbox expires.
A person can stop it at any time
Users start agent work, and they can stop any run whenever they choose. Stopping a run shuts down its sandbox and revokes its platform credentials.
Some features never get the third leg
Our site scans and analysis features read the least trustworthy content we handle: other people’s web pages. So we gave them no tools. They analyze pages and write reports, and that is all they can do. With nothing to act with, an injected instruction has nothing to make them do. This is Willison’s fix exactly as he describes it.
Instructions and tests, as one more layer
Our agents are instructed to treat external content as data, and our evaluation suite includes injection-resistance tests. Given the 95% problem, we count that as a layer on top of the architecture and never as a substitute for it.
What this solves, and what it doesn’t
A coding agent needs some of each ingredient to do its job. It reads code, and some of that code came from strangers. It has to deliver its work somewhere. For the analysis features we could remove a leg outright. For coding agents, moving them into a sandbox makes every leg much smaller.
That changes the size of the risk. On a laptop, an injected agent can reach everything the developer can reach, for as long as the machine is on. In a sandbox, it reaches one user’s permissions for one job, for an hour at most, with a capped key and a stop button. Willison would call that limiting the damage rather than curing the problem, and he’d be right. It’s still a very different place to start from.
A checklist for this quarter
- List every agent that touches your code or content, where it runs, and which skills and connectors it loads. Laptops count.
- Mark the three legs for each one: what private data it can reach, what untrusted content it reads, and how it could send data out.
- Take the tools away from anything that only needs to read and report.
- Move coding agents off laptops and into disposable sandboxes that hold only the credentials the job needs.
- Put a time limit and a stop button on every agent run.
- Treat filters as a layer. They help, and they don’t close the gap on their own.
If you’re working out how to give AI agents real work without handing them a whole laptop, we’d like to compare notes. Get in touch and tell us what your agents can reach today.
