The Lethal Trifecta Is Already on Your Laptops — Michael Patterson, Coder
Michael Patterson of Coder explains Simon Willison's lethal trifecta: private data access, exposure to untrusted content, and external communication, and why coding agents running on developer laptops hit all three. He covers prompt injection, the organizational blockers to enterprise agent rollout such as shadow AI and alert fatigue, and three architectural guardrails: cloud development environments, a model proxy, and an agent firewall.
Why laptop agents are a security problem
Michael Patterson, staff solutions engineer at Coder, opens by describing 2025 as the year of the AI agent, with tools like Claude Code changing how developers work. He tells the story of a developer who first praised agentic coding on social media, then, within days, reported that an agent had deleted his production database. For Patterson, the lesson is that agents are very powerful but create real operational and security problems. He uses OpenClaw as an example. It can act as a personal assistant on your machine, but people advise running it on a separate computer, such as a Mac Mini, because it can read sensitive files, pull down content from the internet, and delete local data.
The lethal trifecta
The talk centers on the lethal trifecta, a term coined by Simon Willison. It describes three conditions that together create serious risk: access to private data, exposure to untrusted content, and the ability to communicate externally. Patterson argues that a coding agent running on a developer’s laptop, such as Claude Code, Codex, or OpenClaw, satisfies all three by default. It can read credentials, databases, company IP, and personal files. It can pull in content from the internet that you never vetted. It can also send data out. He puts it bluntly: having two of the three is already unacceptable in a secure enterprise, and having all three is not a question of if a security incident happens, but when.
Prompt injection and privilege escalation
Patterson explains how prompt injection turns trusted inputs into attack vectors. Malicious instructions can be hidden in error messages, support tickets, or CI/CD logs, and an agent will treat them as a source of truth and act on them. Context poisoning is a related problem. Bad information placed in documentation or data sources gets picked up by the agent and executed. He also points to privilege escalation. Because agents usually need broad access to be useful, a single injection or poisoned context can push them into actions they should never take, such as dropping a table, uploading files, or making unauthorized requests.
Three pillars of agent security
Patterson frames the response as three pillars. The first is controlling data access. The agent should run in an isolated, preferably virtual, environment that blocks access to private files and prevents destructive actions on a personal machine. The second is restricting external communication. The agent should sit on an isolated network, such as a VPN, VPC, or firewall-controlled segment, with access only to allowlisted domains. All of its traffic should be observable, with alerting that lets administrators kill the agent or VM when it leaves its expected perimeter. The third is locking down permissions and credentials, using tightly scoped access. His broader point is that agent security is not fundamentally different from ordinary security practice. The mistake is assuming that because AI is powerful, it will not make the mistakes a human might make or be open to the same kinds of exploitation.
What blocks enterprise rollout
Patterson describes the organizational obstacles to deploying agents at scale. Adoption usually needs security approval from CISOs, buy-in from DevOps, and concrete examples of workflows that justify the risk. Where companies do not authorize agents, developers often use personal cloud or ChatGPT subscriptions on their laptops. He calls this shadow AI, the AI equivalent of shadow IT, and warns that when many such agents run across an organization without oversight, the result is what he calls ninja AI, or shadow AI at scale, where damage may only be discovered after it is too late.
He says CISOs want to enable AI but need guardrails, since they do not want to be blamed when something goes wrong. Platform and infrastructure teams want observability: they need to know what agents are doing, capture every LLM call, and set up alerts without creating alert fatigue. When alerts pile up, important signals get lost in the noise. Rollout also has to be repeatable and consistent across the company. Finally, skeptical senior engineers worry about technical debt, code bloat, security vulnerabilities, and spending their time cleaning up ‘AI slop.’ They also ask who is accountable when a YOLO-mode agent creates pull requests that cause problems.
Guardrail one: cloud development environments
The first architectural guardrail is moving agents off the laptop and into cloud development environments (CDEs), which Patterson presents as Coder’s core product. Developers and agents work in a remote environment accessed through a browser, RDP, or SSH. That environment is blessed by security and platform teams, has scoped permissions, touches only the code and data deliberately placed in it, and cannot reach the internet unless explicitly allowed. He draws a parallel with developer experience. Setting up a project locally means dealing with dependency conflicts, mismatched Python versions, and virtual environments, while a preconfigured cloud environment is ready to go. The same logic applies to agents. An agent dropped onto a fresh machine will start downloading dependencies from registries that may be contaminated, whereas a prepared environment lets it start working immediately. He notes that Coder is open source, model agnostic, cloud agnostic, deployable on premises, and configured with Terraform.
Guardrail two: the model proxy
The second guardrail is a model proxy placed between the agent and the LLM provider. Every request passes through a gateway that logs all traffic and can sanitize it. It can strip injected instructions and remove sensitive data before it leaves the company, such as credit card numbers accidentally pasted into a prompt. Patterson stresses that this gives teams a complete record of what is being sent to model providers.
Guardrail three: the agent firewall
The third guardrail operates at the process level. An agent firewall watches the commands an agent tries to execute and denies anything not explicitly approved. His example is an agent running a command such as deleting a GitHub repository or dropping a database table. The firewall inspects process activity and blocks it, so that a compromised or confused agent cannot carry out destructive actions.
Takeaways
Patterson closes with three points. Agents are powerful, so teams need to stay aware of the lethal trifecta. They need visibility into everything agents do. And it is acceptable to go slowly enough to design the architecture properly and understand what the infrastructure really requires. He notes that a live demo did not fit into the time slot and invites attendees to Coder’s booth to discuss securely developing with agents.