The Lethal Trifecta Is Already on Your Laptops — Michael Patterson, Coder

summarized

TLDR

Running AI agents on laptops creates three overlapping security threats — private data access, internet communication, and lack of oversight — that Coder calls the lethal trifecta. The talk argues that the only safe way to deploy agents at scale is to move them off laptops into isolated cloud environments with model proxies and agent firewalls. For enterprises, this means treating agent security as a standard infrastructure problem rather than a new AI-specific one.

Key points

The lethal trifecta consists of three threat layers: agent on laptop, access to private data, and ability to communicate with the internet.

Coder proposes three architectural solutions: cloud development environments, model proxies, and agent firewalls.

Shadow AI and ninja AI are terms for unauthorized agent usage at scale within organizations.

CISOs are concerned about guardrails and accountability for agent actions, not just enabling AI.

The talk emphasizes that agent security follows standard security practices, not new AI-specific rules.

Tools mentioned

Techniques

  • cloud development environments
  • model proxy
  • agent firewall
  • least privilege access
  • prompt injection prevention
  • context poisoning prevention
Transcript (captions)

0:12 How's everybody doing? Coolio. 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

0:24 Engineers Conference. Um, my name's Michael Patterson. I'm a staff solutions engineer here at Coda. Today, I want to talk to you

0:33 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? All of us or half of us. So, about

0:46 50/50. 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 Coda and addressing it.

0:59 So, I'm going to start off by removing these Grenada notes from the presenter view. Sorry. Want to start off just uh on a quick recap of agentic AI in 2025.

1:16 2025 was undoubtedly the year of the AI agent. Everybody had a new agentic tool, Microsoft, Salesforce, AWS, uh, Claude Code basically changed the

1:30 game when it when it came out last March. Everybody was using this stuff. And I have a a quick story. So, Vibe coding was was a really big thing. Um,

1:43 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.

1:58 And then, I think less than 24 hours later an agent or 2 days later, he posts on Twitter again and says, "Agentic AI just destroyed my product, deleted my

2:10 production database. And how can anyone ever use Agentic AI?" Um the thing is a

2:20 AI agents are very powerful, but they create problems. Um everyone here familiar with Open Claw? Right? So, what's the deal with Open

2:32 Claw, right? It's a really, really cool tool. You can put your own AI on a computer, and it can essentially be your personal assistant, do all of this really, really awesome stuff for you.

2:44 But you've probably seen everyone is saying, "If you're going to use Open Claw, you need to buy a Mac Mini and put it on a different computer than your personal computer, right?" Because it's

2:56 got all these security vulnerabilities. The last thing you want is Open Claw to go download all of your sensitive files, put it up on the internet, download viruses on the internet, put that on

3:07 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

3:17 heads around and how to securely develop with with AI agents. So, today I'm going to spend a little bit of time talking about the lethal trifecta, if you haven't heard of it,

3:27 and how Coder is addressing uh the principles of Agentic security, and how folks are coming to us so that they can address these problems and scale out AI at their company.

3:39 So, a little bit about Coder. Coder was founded in 2017. Um it was founded by three teenagers who were making Minecraft mods, and they They tired of

3:50 having to configure VMs constantly to run Minecraft so that they could develop mods on it. Somehow they stumbled on an $80 million company. Um we're very proud of them. What Coded

4:02 does is it delivers consistent, reliable, and secure remote development environments. Those environments can be stood up pretty much anywhere you want. They're configured with Terraform. We're

4:14 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

4:29 developer environments or agentic environments. We're trusted by some of the biggest companies here in the United States and across Europe. Uh here's some of the names on our

4:41 board. We're in I believe six of the top 10 big banks, lots of hedge funds, lots of three-letter government agencies. Essentially, if a SaaS model doesn't work for you, if

4:53 you've got on-prem infrastructure, if you cannot have code sitting on a developer's laptop or in some kind of uh uh perimeter that you cannot control, Coded is usually a good solution uh just

5:08 like these companies need it. So, what is the lethal trifecta? The lethal trifecta was a term coined by Simon Ellison and it's a essentially three layers, three threat

5:22 layers to the attack surface. One is if you have your agent on a laptop, that could be clawed code, open claw, codex, right? Well, that laptop has access to private data. That can be personal

5:39 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.

5:52 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

6:03 internet. And not only can it put that data on the internet, it can also download things off the internet. So, this is a problem because you don't have oversight into what exactly that agent

6:16 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

6:31 all three is basically not acceptable. It's not if, it's when you're going to have some kind of security incident by having an agent on that laptop. And so, here I've got a a couple of

6:43 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

6:54 an agent would trust. So, it might be looking at error messages, it might be looking at support tickets, it might be looking at CICD logs. And it's very easy for a malicious actor to put something

7:05 in any 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

7:16 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

7:29 in there, the agent is going to go ahead and run with it and do whatever it wants. And then, there's privilege escalation, right? So, everyone's familiar with the privilege

7:38 the the least privilege 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

7:48 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

8:00 requests, or post things that it shouldn't be able to do. So, how do we address that? Um there are three pillars of the lethal trifecta.

8:11 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,

8:23 you don't want it on your laptop, you want it in an environment that is secure, preferably a virtual environment, right? That's going to block private file access, is going to

8:33 prevent destructive actions 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

8:46 box, a VM, it's going to now be uh isolated architecturally from your network. It's only going to be able to go to domains that you want it to go to. It's going to be on your VPN, your VPC,

8:58 it's going to go through a firewall, and then anything that that agent is doing on that box, that traffic is going to be governed. You're going to be able to see every little thing that it does, and if

9:09 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 effectively kill that VM,

9:21 kill that agent. And then, you want to lock down uh the content and the contact and the access. So, you want to lock down the permissions, you want to restrict what access it has to, you want

9:32 tightly scoped credentials credentials. The thing about agentic security is it's really no different from sound security practices for anyone, right? And we think that because AI is so powerful, we

9:44 can just give it whatever it needs and it's not going to make the same kind of mistakes, not going to it's not exploitable by other vulnerabilities that a human would be. So, we want to

9:54 make sure to separate that machine, secure that environment, intercept any kind of uh communication that that agent might do to the uh to the wider internet.

10:07 So, I'm going to kind of 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

10:20 don't want to 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

10:31 AI at your company. So, some challenges to expect, right? Before adoption, um you pretty much need security

10:40 approval from CISOs. You need buy-in from DevOps because they're the ones that have to roll this out to teams. You're going to need real-world examples of, "Hey, this is why I need it. This is

10:52 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,

11:04 most people are going to use their personal cloud subscriptions, their personal uh ChatGPT subscriptions, put that on the laptop because they do get tangible benefits from using AI. They're

11:15 just not being authorized by the company. They're going to get that stuff done anyway. We call that shadow AI. Just like shadow IT, when you're bringing your own VMs, you're bringing

11:23 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 once you

11:35 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

11:47 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

12:00 organization that no one knows until it's too late that a whole lot of stuff has gotten broken. So, um if you were going to adopt AI at your company, you need to make sure that

12:13 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 want to be adaptable. You need to be

12:23 rethinking your architecture. You need to be rethinking how you're going to protect your organization from incidents like agents dropping databases, uh deleting personal information, uploading

12:34 customer information, essentially uh extracting your company's IP onto the public internet. So, once you start wanting to bring AI, you're going to definitely need to be

12:49 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

13:02 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 can on

13:15 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

13:28 because if anything goes wrong, it's not anyone's fault but the chief security team's problem, right?" And they don't want the finger being pointed at them because someone used Agentic AI and they

13:42 didn't know what they were doing or they didn't have the proper guardrails for Agentic usage at the company. Uh platform admins, DevOps, infrastructure, security engineering,

13:53 they're worried about observability. 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

14:06 can I then set up some kind of alerting for that without also getting alert fatigue? So, another thing that's happening is maybe we do get some kind of observability around AI, but now

14:17 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

14:27 really, really critical things that actually need to be addressed. And then another thing is if I am going to roll out AI, how do I actually set this up in a repeatable, consistent, reliable,

14:40 secure way for everyone at the company? Lastly, developers are going to have concerns as well. There is still a holy war happening where some of the most technical people are not quite converted

14:52 that AI can do code better than them, right? They're worried about more technical debt, more code bloat, more security vulnerabilities, and spending most of their time fixing AI slop versus

15:05 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 agent isn't

15:15 doing stuff that would actually get me in trouble, right? Because at the end of the day, someone is going to be accountable when an agent actually does something that we

15:24 didn't expect it to do. So, I'm going to talk a little bit about how 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

15:45 laptop. You want to go to a URL. You want to RDP. You want to SSH into something that is not your laptop, but something that is in a secure environment that has been blessed by the

15:55 security team, by the platform team, and let agents write code, execute code on cloud infrastructure that um is isolated, that has right-scoped permissions, and cannot communicate to

16:10 anything unless you allow it to communicate to that um to that public internet. So, this is kind of what it would look like, right? Instead of putting things

16:21 on your local machine, you go to an isolated cloud environment. Right now, it can only do You can only work on the code that's in there. It can only touch credentials

16:30 that are in there. It can only touch data that you purposely put into that development environment. Right? Um CDEs accelerate AI productivity because

16:43 the thing is if you grab a a project and you put it on your laptop, what do you have to do to get that project running? You got to download dependencies. You got to update

16:54 your your path. If your computer's running Python version 3, but this project needs Python version 2, you're going to get conflicts. You have to create virtual environments. You have to

17:07 do a lot of extra stuff that while it may not break your laptop, you really don't want to go through the trouble of doing that. It would be better if you had a consistent cloud

17:17 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

17:27 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 developing. Well, that same thing is true for

17:38 agents, right? If you put an agent on a fresh box and say, "Download this GitHub repo and run the project." What is it going to do? It's going to read the contents. It's going to say, "Oh, I need

17:47 to start downloading stuff." You never know where it's going to download things from, and if it grabs things from some kind of registry, that registry could be contaminated. You really want things to

17:58 already be ready so that the agent could just start developing. Um the next thing is a model proxy. And this is really just something in between that uh agent or that model on your

18:12 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

18:25 normally in 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 through your gateway, right? And it can sanitize, it can strip injections. If

18:48 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.

19:01 Lastly, you want an agent firewall. So, when that agent starts executing at the process level, you want to make sure that uh it can't run commands that you haven't already blessed, right? So, on

19:15 that remote environment that goes to the proxy, if it runs if that agent for whatever reasons runs gh repo delete or drop this table, you want some kind of agentic firewall

19:29 that's looking at the process logs and saying, "Do not run this." That that command is denied. And so, these are the three ways architecturally you can protect your organization from an

19:42 agent going crazy. So, don't have time to run a demo right now, but if you're interested, please come over to our Curder booth.

19:53 We're opposite 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 be aware of

20:02 that lethal trifecta. Make sure that you've got some way of seeing everything that that agent is does. It's okay to go slow so that you can think about your architecture, know

20:14 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.

20:24 Thank you for your time.

Frontier News · by Hyperjump Technology