# Security Firewall for Agents — Ryan Dahl, Deno AI Engineer · 2026-08-17 Ryan Dahl, CEO of Deno, argues agents must be treated as untrusted software and introduces Claw Patrol, an MIT-licensed proxy that parses every byte leaving an agent below the HTTP layer. At Deno Deploy, agents with write access to Postgres, Kubernetes, ClickHouse, and AWS can be prompt-injected through the support system, so Opus refusing to delete the users table is not enough. Claw Patrol blocks destructive actions even when an agent spawns psql through an EKS endpoint, using HCL rules checked into Git, holds credentials so agents never see them, and can route actions to an LLM judge or Slack approval. A demo shows Codex in yolo mode trying to delete the users table and being blocked. It also includes a unit test system with fixture requests to ensure rules work. ## Questions this episode answers ### What is Claw Patrol and how does it work as a security proxy for agents? Ryan Dahl presents Claw Patrol, an open-source, MIT-licensed proxy that sits in front of agents and operates below the HTTP layer, parsing every byte flowing out of the agent. It holds credentials, supports protocols like Postgres and ClickHouse, uses HCL rules checked into git, and can send actions to an LLM judge or a human for approval. [10:17](https://aiengineer.podhood.com/94f98755-5ea3-4fc3-8e13-cdc809e13a87?t=617000) ### How does Claw Patrol stop Codex from deleting the users table in the demo? Ryan Dahl runs Codex in yolo mode and tells it to delete the users table from Postgres. Codex spawns a psql subprocess, and that connection goes through Claw Patrol, which parses each Postgres protocol byte, applies the rules, and rejects the destructive action. [12:17](https://aiengineer.podhood.com/94f98755-5ea3-4fc3-8e13-cdc809e13a87?t=737000) ### Why is it not enough that Opus refuses dangerous actions? Ryan Dahl notes that Opus is remarkably well aligned and refuses to delete the users table, but security cannot be wishful thinking that the model stays obedient. The SRE agents are wired into the support system, so they can be prompt-injected from the outside, and therefore the agent must be treated as untrusted software with the guard outside it. [2:47](https://aiengineer.podhood.com/94f98755-5ea3-4fc3-8e13-cdc809e13a87?t=167000) ### How do you test Claw Patrol rules? Ryan Dahl explains that the rule file has a test system: you provide fixture requests, then write unit tests to verify each fixture is always blocked by your rules. The Claw Patrol software itself also has a large suite of testing. [17:29](https://aiengineer.podhood.com/94f98755-5ea3-4fc3-8e13-cdc809e13a87?t=1049000) ## Key moments - **[0:00] Intro** - [1:08] Deno runs incident response agents with read/write access to production Postgres, Kubernetes, ClickHouse, AWS, GitHub, and Slack, says Ryan Dahl - **[1:28] Agents in production** - **[2:47] Alignment isn't enough** - [2:47] "Opus is remarkably well aligned... But this is not sufficient." — Ryan Dahl - [4:02] Prompt injection through the support system means agents must be treated as untrusted software; the guard cannot live inside the agent, says Ryan Dahl - **[4:05] Untrusted bytes** - [5:15] Spawning psql as a subprocess to tunnel through an EKS endpoint to Postgres bypasses HTTP-level agent monitoring, says Ryan Dahl - **[5:24] Hard limits** - [6:36] Read-only credentials and ACLs are not enough for agent safety because composed access across systems like Postgres and EKS creates holes, says Ryan Dahl - [8:41] HTTP jail and crab trap only guard HTTP requests, and Agent Vault only handles credential injection — neither sees a psql subprocess, says Ryan Dahl - **[8:48] Existing tools** - **[10:09] Claw Patrol** - [10:17] Claw Patrol is Deno's MIT-licensed proxy that sits in front of agents, parses every byte below the HTTP layer, and holds credentials so the agent never sees them - **[11:03] Rules and demo** - [12:17] Demo: Codex in yolo mode cheerfully obeys 'delete the users table' via psql, but Claw Patrol kills the action at the Postgres wire protocol - **[13:15] Dashboard approvals** - [13:58] Claw Patrol's rules can route an agent action to an LLM judge, a human in Slack, or both for approval before it executes, says Ryan Dahl - **[14:42] Credential injection** - [15:30] Claw Patrol runs over Tailscale or WireGuard, with Tailscale identity controlling dashboard access, keeping agent traffic off the public internet - **[16:33] Thesis** - **[17:18] Q&A** - [17:18] Q: How is Claw Patrol's rule system tested? A: The HCL rule file has unit-testable fixture requests, plus a large test suite for Claw Patrol itself, says Ryan Dahl - [18:11] Q: Does smarter AI make agent security easier or harder? A: Ryan Dahl says we will never fully trust AI; backstop security mechanisms are always needed ## Speakers - **Ryan Dahl** (guest) ## Topics Guardrails, Agent Identity & Access Management ## Mentioned AWS (company), GitHub (company), Claw Patrol (product), ClickHouse (product), Codex (product), Deno Deploy (product), HCL (product), Kubernetes (product), MCP (product), OpenClaw (product), Opus (product), Postgres (product), Slack (product), Tailscale (product), WireGuard (product) ## Transcript ### Intro **Ryan Dahl** [0:14] How's it going? Um, my name is Ryan. I'm going to— I'm the CEO at Deno, and yeah, you've been developing software for, for quite a while. At this point, you might know one of my projects, Node.js. I want to talk about a service that we're running at Deno called Deno Deploy. This is a system for hosting websites, and it has incidences. It's— it has downtime occasionally. And we've got a pager duty that fires. I'm sure you're all very familiar with the very scary alarm sound that wakes you up in the middle of the night. And recently, we've been playing around with using agents to automatically service these incidences. In particular, OpenClaw, but other, other agents as well. And we've found a pattern that is working pretty well for us that I want to share with you. We actually give OpenClaw access to all sorts of systems: Postgres, Kubernetes, ClickHouse, AWS, GitHub, Slack, all sorts of things. ### Agents in production **Ryan Dahl** [1:30] And we do actually give them rewrite access to these systems. This is very powerful because the agents can actually get all of the context. They can see traces in ClickHouse, they can look in the production Postgres database at what the user— what projects the user owns. They can look through Slack for communications, GitHub logs, etc. This actually works quite well. The agents are actually able to solve quite a lot of incidences where we previously would have a human SRE in the loop. But it is very dangerous, of course, because these agents could do nefarious things. They could start a psql subprocess and issue a delete users table. They could call kubectl delete namespace prod. You know, they could decide somehow that solving the incident means, you know, removing all of the users. And of course, we don't want that. ### Alignment isn't enough **Ryan Dahl** [2:47] We use Opus, and Opus is remarkably well aligned. You can really not— you can try very hard to get it to delete the users table, and it will refuse over and over again. But this is not sufficient,right? Security can't just be wishful thinking that Opus will always obey your, your wishes. These SRE agents that we have are connected to the support system and thus can be prompt injected from the outside. And that means that they can be manipulated somehow. Like, who knows, who knows what sort of string of characters could send Opus into some bad state that allows it to think that it's taking theright action by doing something very undesirable. So, you know, we take the stance that the agents themselves have to be untrusted software. You can't rely on the agent itself to guard what it's doing. You can't put the guard inside the agent. We run agents, and I assume many of you do the same, on standalone VMs. So we're not very concerned about agents touching files on the file system. You know, they're, they're, they're properly isolated at the system level. ### Untrusted bytes **Ryan Dahl** [4:23] But so, you know, effectively every nefarious action that an agent could take, every good action that it takes, comes in the form of some network communication, some, some bytes over the wire. And how these bytes are formed can happen in various ways. You can, of course, call through MCP, but also subprocesses. And if you think of Postgres, for example, this is a non-HTTP protocol that OpenClaw can just spawn as a subprocess and start connecting to services. So we take the stance that we really want to understand what the bytes are coming out of that agent in great detail. This can get very tricky in real-world systems. So, for example, we have a production Postgres database in AWS that is inside a VPC that we can only reach, really, through an EKS endpoint. And what we'd really like to do is ensure that our agent, which we want to give access to everything, essentially, can't somehow tunnel through this EKS server, spawn psql, and drop the users table,right? ### Hard limits **Ryan Dahl** [5:50] We're concerned about pretty crazy situations like this that get very complicated. And I think many of you work in companies where you have real-world systems where things are very complex network topologies. So, yeah, just to highlight this: this is an outbound path the agent's host can't reach on a protocol that isn't HTTP, that's gated by a rule that understands SQL. These are what human SREs would do. And how can we, you know, empower these agents to have kind of the same access that a human might? So you might ask, you might say, well, you know, there's ACLs, there's permissions, you can issue read-only Postgres credentials. And yeah, that's true, up to a point. You can do careful credential provisioning, and you should. But this really requires working across many different systems, provisioning credentials in incredibly careful ways. And as I just demonstrated, the composition of access can lead to holes when you can access one system and then another system. MCP, you know, you can structure all of this as very careful MCP tools that have the proper permissions. But, you know, then you can't spawn subprocesses,right? You can't, you know, as soon as the OpenClaw spawns the psql, you're kind of out, broken through the security boundary. There are quite a few projects in this space, namely projects that kind of sit in front of an agent and look at what it's sending and try to control based on the bytes that are flowing through this. LLM gateways, I think we're all familiar with. OpenRouter, LightLLM, for example, these often have a guardrails feature that can guard against prompt injection, you know, scan for various expressions, etc., that are going back and forth between the LLM provider. But of course, that's just the LLM. You know, we're talking to databases and stuff. You have systems like HTTP jail and crab trap that are HTTP proxies that really sit at the HTTP layer. And HTTP jail, for example, can will allow you to write rules that say, well, you can make GET requests but not POST requests, or you can access this HTTP subpath. Crab trap is a project from Brex that has an LLM as a judge that operates on the HTTP requests flowing back and forth. ### Existing tools **Ryan Dahl** [9:04] You have proxies that inject credentials into as they're passing out of the agent, Agent Vault being a popular one, where the agent itself never actually sees the credentials of the system that it's talking to, but passes some placeholder out and the proxy itself injects those credentials. This is an important part of the problem, but not a complete solution. And you have things like process sandboxes, like NVIDIA's OpenShell, that, you know, really are kind of OS system-level guards against, say, accessing different file system paths, accessing different syscalls, that sort of thing. But as I said before, we're not really concerned about that because we provision a standalone VM for our agents. So the software that we've written to address this problem is called Claw Patrol. It's an open-source MIT-licensed project. And this is a proxy that sits in front of your agents. ### Claw Patrol **Ryan Dahl** [10:17] It operates not at the HTTP level, but at a lower level. It understands each and every byte flowing through, flowing out of your agent. It holds credentials like Agent Vault and can inject those credentials so that your whatever agent software you're using doesn't actually, doesn't ever actually see secret values. And in particular, it has a very advanced rule system that allows you to say in precise details how and what requests get transferred out of the agent and talk to the outside world. These rules are kind of the key piece of the system. And we write them in a configuration file using a language called HCL. ### Rules and demo **Ryan Dahl** [11:14] Anybody familiar with HCL? This is like the Terraform, the Terraform configuration language. It actually works really well here. So we have a file that we check into Git, and we manage very carefully that essentially defines the permissions for all of our services at Deno. And these, yeah, it's a big long file. It's like a thousand lines. And, you know, we manage each and every change to that in kind of precise detail. This is an example of a rule in our configuration file that blocks certain Postgres functions from being called. And so, yeah, again, Postgres being a non-HTTP protocol. And these rules can be applied even when tunneling through other systems. It supports a number of different protocols and has a plugin system to extend it when you run into a protocol that it is not yet familiar with. So here's a little demo, unfortunately not live. But we call Claw Patrol run Codex in yolo mode so that it just does what you say it should do. And you tell Codex, "Hey, delete the users table from Postgres." And Codex properly obeys and starts a psql subprocess where it deletes the users table. That psql subprocess opens a network connection to our, to the Postgres server that goes through Claw Patrol where we parse each and every byte. We understand the Postgres protocol. We apply our rules and ultimately reject that, what we call an action from doing something destructive. Claw Patrol has a dashboard that lets you see what your agents are doing. So at the top, you can see a couple of different devices or agents and the various requests that are flowing through, some of them being denied, some of them need approval, which I'll talk about in a second. ### Dashboard approvals **Ryan Dahl** [13:36] And you can click into each request or action, as we call it, because it's more general than HTTP requests, and see the details of what's going on. There's analytics and, yeah, it's very utilitarian driven. It's like what we need to understand our own agents. There, as I said, there's an approval system in this. So you can route, you can define rules that don't just reject requests or actions, but ask a human, for example, in a Slack channel, or run an LLM judge over this, or any combination thereof,right? Maybe first get an LLM judge and then get approval in Slack so that you can have, again, very precise control over what your agents are doing outside of the agent software itself,right? We treat the agent software as a black box,right? We don't require any changes to that software. ### Credential injection **Ryan Dahl** [14:42] I mentioned credential injection before. Claw Patrol has very detailed support for all sorts of systems. Credentials come in many different forms. They're not just bearer headers. It handles cookies, it handles Postgres, as I mentioned, ClickHouse, supports all sorts of OAuth protocols, supports very complex things like AWS SigV4. So, yeah, this, I guess what I'm trying to say is that this is really born out of utility here and meant for real-world systems. This is not just, you know, kind of an imaginary scenario. This system works over Tailscale or WireGuard. We ourselves run Claw Patrol, run our agents inside of Tailscale, inside of a Tailnet, and Claw Patrol acts as a Tailscale exit node. We also lean on Tailscale for authentication to the dashboard. So your Tailscale identity actually allows you access to the dashboard so that we don't have to layer on another authentication mechanism. But we also have this WireGuard for people who have not bought into the wonderful Tailscale ecosystem. But this works very well for us because we know that all of our stuff is off the internet and all of these very security-sensitive things are tightly controlled. Claw Patrol itself is holding all of these credentials to production systems. So you have to be very careful with it. So, yeah, the thesis here is basically that agents can't be trusted to police themselves. That includes security plugins or modifications to the agent software itself. The security boundary has to be elsewhere. And that's not to say that alignment is not a good thing, but, you know, for real-world security systems, we really do need to control this at a higher level. ### Thesis **Ryan Dahl** [17:00] And Claw Patrol is our attempt to make this work for ourselves. And, yeah, you can check it out here. I might have time for one question or so. Yes, sir. ### Q&A **Guest** [17:24] What kind of eval testing do you do on this to make sure it's working properly? **Ryan Dahl** [17:29] Yeah, so the question is, what sort of testing do we do to make sure it works properly? I didn't mention, but this rule file actually has a test system along with it where you can provide fixtures, action like fixture requests that can flow through the rules, and then you can essentially create unit tests to make sure that that fixture is, you know, that request will always be blocked by your set of rules. And then, of course, for the Claw Patrol software itself, we have a large suite of testing. Yes, sir. So the question is, as agents get smarter, does this problem get bigger or smaller? I think we can, we will never be able to fully trust AIs. I think it becomes less and less of a problem as they are smarter, have better context, know that they're working with a company, know that they shouldn't be doing bad things. Opus is more aligned than previous models. But I think we're always going to have to have backstop security mechanisms. Cool. Well, I'll be around for other questions, but thank you very much. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.