The Lethal Trifecta Is Already on Your Laptops — Michael Patterson, Coder
Read the talk
The Lethal Trifecta Is Already on Your Laptops
Michael Patterson explains how private data, untrusted content and internet access combine inside coding agents—and how remote environments, model proxies and command controls can limit what a compromised agent can do.
From a talk by Michael Patterson
At a glance
Ideas worth remembering
The lethal trifecta connects private-data access, untrusted content and external communication. Prompt injection becomes consequential when malicious guidance can direct tools with real permissions.
A prepared remote environment limits which resources the agent can reach and reduces dependency-installation decisions before development begins.
Model proxies govern requests to providers; agent firewalls govern execution. Logging supports oversight, while prevention requires controls that act before data leaves or a command runs.
An enterprise rollout needs approved workflows, repeatable environments and useful alerts. Blocking adoption without addressing demand can push agent use onto personal subscriptions outside organizational visibility.
Take time to understand the infrastructure and make agent activity visible before scaling its access and autonomy.
The same access that makes an agent useful makes mistakes expensive
A coding agent can make changes quickly enough to transform a development workflow. It can also make a destructive change just as quickly. Michael Patterson, Staff Solutions Engineer at Coder, opens with a cautionary anecdote: a developer celebrated the productivity of agentic coding, then reported that an agent had deleted his production database. The anecdote establishes the stakes rather than a verified incident analysis; it does not explain the permissions, commands or safeguards involved.
OpenClaw makes the access problem particularly easy to picture. A personal assistant running on a computer can use the files and network connections available there. Patterson invokes the advice to put it on a separate Mac Mini: the attraction is physical separation from the machine containing personal files. His nightmare scenario combines disclosure and destruction—sensitive files uploaded to the internet, unwanted software downloaded, and local files deleted. These are possible consequences he uses to motivate isolation, rather than events demonstrated in the recording.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Remote development gives the security discussion an architectural starting point
Coder approaches this problem through remote development environments. Its origin story begins with three teenagers making Minecraft mods and repeatedly configuring virtual machines. The product turns that repeated setup into environments configured with Terraform, which can run in different clouds or on premises. Patterson describes Coder as open source, model agnostic and cloud agnostic.
That deployment flexibility matters when an organization cannot use a SaaS development service or allow source code to sit on developers’ laptops. The environment can live inside infrastructure the organization controls. This is the foundation for the later agent proposal: move execution into a deliberately configured workspace, then decide what code, data, credentials and network access belong there.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
How untrusted text becomes an action against private data
Simon Willison’s “lethal trifecta” names the combination of access to private data, exposure to untrusted content and the ability to communicate externally. A laptop agent can encounter all three in an ordinary development session: it reads local files or credentials, consumes material from elsewhere, and makes internet requests. The risk comes from connecting those capabilities through an agent that decides what to do next.
The ingredients have distinct roles:
- Private data supplies the target. Personal files, credentials, company intellectual property and databases may be accessible to the agent.
- Untrusted content supplies the redirection. An error message, support ticket, CI/CD log or document can contain malicious guidance.
- External communication supplies an exit. The agent can send data outward as well as download material into its environment.
Prompt injection exploits the transition from reading information to following instructions. A log is useful evidence about a failed build; malicious guidance inside that log should not acquire the authority to direct the agent. In Patterson’s scenario, the agent accepts the embedded guidance as a source of truth and takes an action the user never requested. Context poisoning reaches the same decision process through altered documentation or data that the agent retrieves.
Broad permissions make that redirection consequential. An agent given extensive access “because it needs access to do the work” may already have enough authority to drop a table, upload data or make an unwanted request. Patterson describes this as privilege escalation; the mechanism developed here is malicious content causing the agent to misuse available privileges. He does not describe an exploit that obtains additional operating-system permissions. His stronger warning that an incident is inevitable is a risk judgment, rather than a measured probability established by the talk.
Where does the dangerous connection occur? The diagram follows untrusted content into the agent’s decision process, then shows how private-data access and external communication can turn a bad decision into disclosure. Reading a malicious message is only the entry point; the available tools and permissions determine what can happen afterward.
Malicious guidance appears in a log, ticket or document.
The agent connects incoming content to tools that can read private data and communicate externally. The arrows show a possible attack path, not a demonstrated incident.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Control the environment, its connections and its credentials
The first response is to reduce what a redirected agent can reach. A separate virtual environment keeps the developer’s private laptop files out of the agent’s workspace and moves destructive execution onto another machine. Separation provides that protection only to the extent that private files and powerful credentials are kept out of the remote environment.
Network controls then govern where the agent can go. Patterson describes an environment within an organization’s VPN or VPC, with traffic passing through a firewall and access limited to allowed domains. Monitoring should expose unexpected communication and give administrators a way to stop the agent or terminate its VM. Moving the agent off the laptop creates a place to apply these controls; the controls still have to be configured.
Tightly scoped credentials complete the approach. The agent should receive the permissions needed for its task rather than everything a developer can access. These are familiar security practices: isolate execution, limit access and govern communication. The mistake is assuming that a capable model deserves broader trust simply because it can do more work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A rollout must answer security, operations and developer concerns
Enterprise adoption introduces a second problem: a policy can prohibit agents without eliminating the demand for them. An approved rollout needs security approval, DevOps participation and concrete examples of useful workflows. When that route is unavailable, developers may use personal Claude or ChatGPT subscriptions on their laptops because the tools help them finish work. Patterson calls this “shadow AI”: unauthorized use that the organization cannot see or govern.
Multiple unobserved agents compound the problem. Patterson uses “ninja AI” for shadow AI at scale: many agents performing work across an organization before anyone understands the consequences. The practical concern is the multiplication of execution and access. Database deletion, personal-data loss and customer-information uploads require an architectural response, even when the initial adoption effort starts with developers seeking productivity gains.
Different teams need different answers before that rollout can work:
- Security leaders need enforceable limits. The CISO may welcome faster development while still needing a credible answer to how agents will follow security practices and who will handle incidents.
- Platform and operations teams need visibility and repeatability. They need to observe model-provider calls and deploy a consistent environment across teams. Alerts also need to remain useful: a flood of notifications can obscure the events that require action.
- Developers need confidence in the resulting work. Concerns include technical debt, code bloat, vulnerabilities and time spent repairing “AI slop.” Unattended PR generation also raises a personal question: who is accountable when an agent does something unexpected?
Visibility and enforcement therefore serve different needs. Logs help teams understand what happened; limits reduce which actions are possible. Alert fatigue explains why collecting more activity cannot, by itself, resolve the rollout problem. A repeatable environment gives operations a consistent starting point, while permissions and execution controls address the consequences of a bad agent decision.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Guardrail 1: Start the agent in a prepared remote workspace
A cloud development environment supplies the remote execution layer. A developer connects through a URL, RDP or SSH while the agent writes and executes code on infrastructure approved by security and platform teams. The intended environment has scoped write permissions and communicates externally only where allowed. Its contents define what the agent can touch: the code, credentials and data deliberately placed inside it.
Preparation also changes how a project gets started. On a laptop, running a newly downloaded project may require installing dependencies, changing the path and resolving runtime conflicts. Patterson’s example is a machine with Python 3 facing a project that requires Python 2. Virtual environments and configuration work can resolve the mismatch, but they consume effort and alter the developer’s setup. A preconfigured remote workspace moves that preparation ahead of the development session.
The same sequence matters for an agent. Put it on a fresh machine and ask it to download a GitHub repository or run a project, and it first reads the project, discovers missing dependencies and starts downloading them. That adds decisions about sources and packages before productive work begins; a registry could contain contaminated material. Preparing the environment beforehand reduces this open-ended setup work and lets the agent start developing sooner. The security benefit comes from controlling preparation and access, rather than from the word “cloud.”
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Guardrails 2 and 3: Check model traffic and deny unwanted execution
A model proxy inserts a gateway between the agent and the LLM provider. Instead of sending a model request directly to the internet, the agent sends it through an organization-controlled server that can inspect, sanitize and log the traffic. This gives platform teams a place to observe model calls and apply rules before their contents reach the provider.
Consider Patterson’s credit-card example. Someone accidentally includes credit-card data in a prompt. With a direct connection, that data travels in the request to the model provider. With the proposed proxy, the request first reaches the gateway; the gateway identifies and strips the sensitive data, then forwards the sanitized request. The visible change is in what leaves the organization: the provider receives the request without that data. Patterson also proposes stripping injections, but gives no detection method or accuracy results; this is a filtering capability to configure and evaluate, not a guarantee that arbitrary malicious guidance will be removed.
The agent firewall addresses a different moment: execution. When the agent attempts a command, a control should deny anything that has not been allowed. Patterson’s examples are gh repo delete and dropping a database table. His intended outcome is that the destructive action does not run. Inspecting process logs may supply visibility, but achieving that outcome requires the check to prevent execution rather than merely report it afterward; the recording does not specify the interception implementation.
Where does each guardrail act? The diagram separates model-request traffic from command execution inside the remote environment. The proxy changes what can reach the provider, while the command control changes what can run locally. A sanitized prompt does not by itself prevent repository deletion, and a denied shell command does not by itself remove sensitive data from a model request.
The ending returns to operational judgment: make agent activity visible, understand what the infrastructure needs and allow time to design the architecture. “It’s okay to go slow” is the useful counterweight to rapid agent adoption. A prepared workspace limits accessible resources, a proxy governs model traffic, and an execution control limits commands. Together, they place decisions about access and action in infrastructure that the organization can manage.
Access is limited to the code, credentials and data supplied to the environment.
The credit-card example follows the model-request branch. Destructive commands follow a separate execution branch within the controlled remote environment.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Read the complete timestamped transcript
- 0:12
How's everybody doing?
- 0:16
Coolio.
- 0:18
Well, it's nice to be presenting to you all. I hope we're all having a good time here at the, the AI Dev Conference-- the AI Engineers Conference. Um, my name's Michael Patterson. I'm a staff solutions engineer here at Coder. Today, I wanna talk to you about the lethal trifecta. So we're a bit of a small crowd. Uh, can I get a raise of hands, has anyone heard of the lethal trifecta?
- 0:43
All of us or half of us, so about fifty/fifty. Fantastic. So what I'm going to do is explain a little bit about what the lethal trifecta is and what we've learned here at Coder in addressing it.
- 0:59
So I wanna start off by removing these Granola notes from the presenter view, sorry.
- 1:10
Wanna start off just, uh, on a quick recap of agentic AI in twenty twenty-five. Twenty twenty-five was undoubtedly the year of the AI agent. Everybody had a new agentic tool, Microsoft, Salesforce, AWS. Uh, Claude Code basically changed the game when it, when it came out last March. Everybody was using this stuff.
- 1:36
And I have a, a quick story. So vibe coding was, was a really big thing. Um, Jason, uh, had this Twitter post about how agentic coding changed his life. He's pushing out all of this code, making all of these new changes to his product. This was the future for him. And then I think less than twenty-four hours later, an ag-- or two days later, he posts on Twitter again and
- 2:06
says, "Agentic AI just destroyed my product, deleted my production database," and, "How can anyone ever use agentic AI?" Um, the thing is ag-- uh, AI agents are very powerful, but they create problems. Um, everyone here familiar with OpenClaw? Right. So what, what's the deal with OpenClaw, right? It's a really, really cool tool. You can put your own AI
- 2:37
on a computer, and it can essentially be your personal assistant, do all of this really, really awesome stuff for you. But you've probably seen everyone is saying, "If you're gonna use OpenClaw, you need to buy a Mac Mini and put it on a different computer than your personal computer," right? Because it's got all these security vulnerabilities. The last thing you want is OpenClaw to go download all of your sensitive files, put it up on the internet, download viruses on the internet,
- 3:07
put that on your laptop, and then delete all your personal files so that you don't have them, but the rest of the world does. So there are quite a few issues with agents that we are still wrapping our heads around and how to securely develop with, with AI agents. So today I'm gonna spend a little bit of time talking about the lethal trifecta, if you haven't heard of it, and how Coder is addressing, uh, the principles of agentic sec-security, and how folks are coming to us so that they can address these problems and scale
- 3:36
out AI at their company. So a little bit about Coder. Coder was founded in twenty seventeen. Um, it was founded by three teenagers who were making Minecraft mods, and they got tired of having to configure VMs constantly to run Minecraft so that they could develop mods on it. Somehow, they stumbled on an eighty million dollar company. Um, we're very proud of them. What Coder does is it delivers consistent, reliable, and secure
- 4:07
remote development environments. Those environments can be stood up pretty much anywhere you want. They're configured with Terraform. We're open source. We're model agnostic. We're cloud agnostic. Uh, you can host this on premise, and we find that, um, this is a really, really good solution if you need a self-hosted model for developer environments or agentic environments. We're trusted by some of the biggest companies here in the
- 4:36
United States and across Europe. Uh, here are some of the names on our board. We're in, I believe, six of the top ten big banks, lots of hedge funds, lots of three-letter government agencies. Essentially, if a SaaS model doesn't work for you, if you've got on-prem infrastructure, if you cannot have code sitting on a developer's laptop or in some kind of a, a perimeter that you cannot control, Coder is
- 5:06
usually a good solution, uh, just like these companies needed. So what is the lethal trifecta? The lethal trifecta was a term coined by Simon Willison, and it's es-essentially three layers, three threat layers to the attack surface. One is if you have your agent on a laptop, that could be Claude Code, OpenClaw, Codex, right? Well, that laptop has
- 5:36
access to private data that can be personal information as files on your computer, credentials, company IP, databases. So now your laptop has access to it. Your agent now has access to this private data. Now that it has access to this private data, it can also ex-- uh, communicate to the internet, right? So it has access to private data, and it can put that data on the internet. And not only can it put that data on the internet, it can
- 6:06
also download things off the internet. So this is a problem because you don't have oversight into what exactly that agent might do when you prompt it. So one of these three isn't really a big problem, but two out of three is completely unacceptable in any kind of secure enterprise environment. Having all three, it's basically not acceptable. It's not if, it's when you're gonna
- 6:36
have some kind of security incident by having an agent on that laptop. And so here I've got a, a couple of attack scenarios. I'm sure everyone here has heard of prompt injection, which is essentially, um, you have some kind of malicious guidance in the information source that an agent would trust. So it might be looking at error messages, it might be looking at support tickets, it might be looking at CI/CD logs, and it's very easy for a malicious actor to put something in any
- 7:06
of those messages, and the agent just accepts that as a source of truth and can do something that you didn't expect it to do. Context poisoning is in that same realm, where you're essentially putting bad information into documentation, into data, anywhere where you're going to-- your agent is going to grab information, and then if there's any malicious data in there, the agent's going to go ahead and run with it and do whatever it wants. And then there's privilege escalation, right? So everyone's
- 7:36
familiar with the privilege, uh... the, the least privileged access principle, right? And generally, we're giving agents access to pretty much everything because it needs access to do the work, right? And so any one of these prompt injections or context poisoning can unwittingly escalate the privilege of that agent so it can do things that it shouldn't do, drop a table, upload, make requests, or post things that it shouldn't be able to do. So how do we
- 8:06
address that? Um, there are three pillars of the lethal trifecta. There are three pillars of the... of agentic security. We call it the trifecta of agent security. The first thing is you want to control data access. If you're going to use an agent, you don't want it on your laptop. You want it in an environment that is secure, preferably a virtual environment, right, that's gonna block private file access. It's gonna prevent destructive actions
- 8:36
on your machine because it's on some other machine. Then you restrict that external communication. So if you're going to put that agent on some kind of box, a VM, it's going to now be, uh, isolated architecturally from your network. It's only gonna be able to go to domains that you want it to go to. It's gonna be on your VPN. Your VPC is gonna go through a firewall, and then anything that that agent is doing on that box, that traffic is going to be governed.
- 9:06
You're gonna be able to see every little thing that it does, and if it ever breaches that perimeter, you should have some way of alerting your admins, alerting yourself that your agent is going somewhere it shouldn't, so that you can e-effectively kill that VM, kill that agent. And then you wanna lock down, uh, the content and the contact and the access. So you wanna lock down the permissions. You wanna restrict what access it has to. You want tightly scoped credentials, credentials. The thing about agentic
- 9:35
security is it's really no different from sound security practices for anyone, right? And we think that because AI is so powerful, we can just give it whatever it needs, and it's not gonna make the same kind of mistakes, not going to-- It's not exploitable by other, uh, vulnerabilities that a human would be. So we wanna make sure, uh, to separate that machine, secure that environment, intercept any kind of, uh, communication that that agent might do to the, uh, to the wider
- 10:05
internet. So I'm gonna kinda quickly go over what it looks like, uh, deploying agents at scale at really, really large companies. What are the blockers to adoption? Why companies don't wanna do this. Uh, what are the challenges if you do, uh, decide to roll out agentic AI at a company, and the questions you can expect if you're trying to lead an initiative to get, uh, AI at your company. So some
- 10:35
challenges to expect, right? Before adoption, um, you pretty much need security approval from CISOs. You need buy-in from DevOps because they're the ones that have to roll this out to teams. You're gonna need real-world examples of, "Hey, this is why I need it. This is the workflow I want to do." And the trick here is, if you're not getting these approvals, if you're at a company right now, and they are not letting you use agents, m-most people are gonna
- 11:05
use their personal Claude subscriptions, their personal, uh, ChatGPT subscriptions, put that on their laptop because they do get tangible benefits from using AI. They're just not being authorized by the company. They're gonna get that stuff done anyway. We call that shadow AI, just like shadow IT, when you're bringing your own VMs, you're bringing your own, uh, technology into your company to get the work done. Shadow AI is just unauthorized usage of AI on your laptops. Um, it's a real problem because
- 11:35
once you get AI on your laptop, you're using your personal subscription, the enterprise doesn't know what's happening, and usually, uh, agentic AI can do a lot of damage really fast. We're starting to see a new term in the industry called ninja AI, which is shadow AI at scale, where you're not just having one agent breaking stuff. You've got multitudes of agents doing lots of things at an organization that no one knows until it's too late, that a whole lot of stuff has gotten broken.
- 12:06
So, um, if you are going to adopt AI at your company, you need to make sure that there are good outcomes, right? Usually, companies come to us, they start with the developers because they're getting the most use out of using AI, but you wanna be adaptable. You need to be rethinking your architecture. You need to be rethinking how you're gonna protect your organization from incidents like agents dropping databases, uh, deleting personal information, uploading customer information-
- 12:36
Essentially, uh, extracting your company's IP onto the public internet.
- 12:44
So once you start wanting to bring AI, you're going to definitely need to be talking to the security people. What are they-- what is the CISO, uh, concerned about? How do I stop agents from violating best practices? How do I put boundaries around these agents, right? I, I, I personally talk to, to CISOs probably once or twice a week, and they're saying, "Hey, we understand the value of AI, we want to bring AI, we want people to go as fast as they
- 13:14
can on the, the development AI superhighway, but I need guardrails for them," right? And I can't just have my platform team or this business team come to me and say, "Hey, we need AI. I need you to bless it," because if anything goes wrong, it's not anyone's fault but the chief, uh, security team's problem, right? And they don't want the finger being pointed at them because someone used agentic AI, and they didn't know what they were doing,
- 13:44
or they didn't have the proper guardrails for, uh, agentic usage at the company. Uh, platform admins, DevOps, infrastructure, security engineering, they're worried about observability. H-what are these agents doing? How do I know it's doing? How do I get every call that they make to an LLM provider in some kind of observability tool? And how can I then set up some kind of alerting for that without also getting alert fatigue? So another thing that's happening is
- 14:14
maybe we do get some kind of observability around AI, but now there's alerts going all over the place. Once you get alert fatigue, you stop really looking at what's actually happening. Everything AI is doing just becomes noise, and you're missing the really, really critical things that actually need to be addressed. And then another thing is, if I am gonna roll out AI, how do I actually set this up in a repeatable, consistent, reliable, secure way for everyone at the company? Lastly,
- 14:44
developers are gonna have concerns as well. There is still a holy war happening where some of the most technical people are not quite converted that AI can do code better than them, right? They're worried about more technical debt, more code bloat, more security vul-vulnerabilities, and spending most of their time fixing AI slop versus just doing it themselves. And then if they are going to put Claude on YOLO mode and have it crank out a bunch of PRs, how do I make sure that that
- 15:14
agent isn't doing stuff that would actually get me in trouble, right? Because at the end of the day, someone is gonna be accountable when an agent actually does something that we didn't expect it to do. So I'm gonna talk a little bit about how, uh, you can address all of these guardrails that everyone is concerned for.
- 15:35
Uh, the first thing is cloud development environments, and this is something that Coder does, right? You want a remote execution layer. You want a remote environment. You don't want it on your laptop. You wanna go to a URL, you want a RDP, you want a SSH into something that is not your laptop, but something that is in a secure environment that has been blessed by the security team, by the platform team, and let agents write code, execute code on cloud infrastructure that, um, is isolated,
- 16:06
that has write-scoped permissions and cannot communicate to anything unless you allow it to, uh, communicate to that, um, to that public internet. So this is kind of what it would look like, right? Instead of putting things on your local machine, you go to a isolated cloud environment, right? Now it can only do the-- it can only work on the code that's in there. It can only touch credentials that are in there. It can only touch data that you purposely put into that, uh, development
- 16:36
environment, right? Um, CDEs accelerate AI productivity because the thing is, if you grab a, uh, a project and you put it on your laptop, what do you have to do to get that project running? You gotta download dependencies. You gotta update your, uh, your path. If your computer's running Python version three, but this project needs Python version two, you're gonna get conflicts. You have to
- 17:05
create virtual environments. You have to do a lot of extra stuff that while it may not break your laptop, you really don't wanna go through the trouble of doing that. It would be better if you had a consistent cloud environment that was already configured to run that application, right? And so everything that Coder does, uh, that helps developers, they don't have to worry about mucking around the shell, mucking around their precious laptop. They can just go to this lightweight or heavy VM and everything's already ready to go, and they can just start
- 17:35
developing. Well, that same thing is true for agents, right? If you put a agent on a fresh box and say, "Download this GitHub repo or run the project," what is it gonna do? It's gonna read the contents. It's gonna say, "Oh, I need to start downloading stuff." You never know where it's gonna download things from, and if it grabs things from some kind of registry, that registry could be contaminated. You really want things to already be ready so that the agent can just start developing. Um, the next thing is a model
- 18:05
proxy, and this is really just something in between that, uh, agent or that model on your machine. Before it hits the LLM provider, it needs to go through a box where we're sniffing all of that traffic, and we're able to log every little thing that it's doing, right? So here you can see normally in a, in a, in a normal scenario, the agent would be sitting somewhere, and it can just go straight to the internet, straight to the model provider and get what it needs. But the
- 18:35
solution is really simple, right? Before the agent hits the model provider, it goes to your proxy server, it goes to your gateway, right? And it can sanitize, it can strip injections. If you have like-- If you accidentally put Credit card data into a prompt, you don't want that going to the LLM provider, uh, model proxy can strip that, and it logs everything that's happening. Lastly, you want an agent firewall. So when that agent
- 19:05
starts executing at the process level, you wanna make sure that, uh, it can't run commands that you haven't already blessed, right? So on that remote environment that goes to the proxy, if it runs, if that agent for whatever reasons runs, um, gh repo delete or drop this table, you want some kinda agentic firewall that's looking at the process logs and saying, "Do not run this." That, um, that command
- 19:35
is denied. And so these are the three ways architecturally you can protect, uh, your organization from, uh, an agent going crazy. So don't have time to run a demo right now, uh, but, uh, if you're interested, please come over to our Coder booth. Uh, we're opposite, uh, and to the... We're opposite of this stage and over to the left. Um, and just some key takeaways, right? Agents are powerful, but beware of that lethal trifecta. Make sure that you've
- 20:05
got some way of seeing everything that that agent is do- does. It's okay to go slow so that you can think about your architecture, know what your infrastructure actually needs. My name is Michael Patterson, Staff Solutions Engineer. Would love to talk to you guys about how you can securely develop with agents. Thank you for your time.