Deno Just Open Sourced Their Agent Firewall ![rw-book-cover](https://img.youtube.com/vi/ZiFoTw6doGI/maxresdefault.jpg) 🔗 **Source:** [Deno Just Open Sourced Their Agent Firewall](https://www.youtube.com/watch?v=ZiFoTw6doGI) This is Claw Patrol, an open- source security firewall built by the Dino team that sits between your AI agents and the internet, and it solves three key security problems with AI agents. Access is an actual control. Your agent shouldn't see secrets, and you can't see what your agent did. I've been trying a lot of AI agent security tools recently, and I really like the approach that Claw Patrol has taken here, but it's not perfect yet. So how claw patrol works is you have one server called the gateway which holds your rules, credentials, logs and the claw patrol dashboard. Then you have any number of machines that run agents and they can join that gateway and route their agent traffic through it. In fact, you can choose to run single commands through the gateway or you can add your entire machine. In my case, my gateway is simply a yubuntu server which I connect to with tailscale which claw patrol supports out of the box as well as wire guard or both. and my agents are my Mac and my Open Claw server. I'm running the OpenClaw gateway through Claw Patrol. And on my Mac, I just use the single run command with Claude as and when I need it. With that bit of context, let's look at the three key problems that claw patrol solves. And I'll actually start with number two, which is your agents shouldn't see secrets as it leads nicely onto the other problems. So on the claw patrol gateway, you can configure your credentials like Postgress users, claude subscriptions, GitHub accounts, and any bearer tokens or custom headers like I have here for my production API server. With this, when we then run our agents through the gateway using that claw patrol run command, they don't need any of these credentials to actually make the requests work. They'll simply be injected when that request passes through the gateway. So if I ask Claude to use my API and my database to give me an overview of both of these, it's able to do so with zero issues. And I can see on the commands that it's actually running that it's not including any API keys for these curl requests, but it needs one. And on Postgress, it's just using a fake password of X that is definitely not the real password, but it's still connecting and getting the relevant information back. As the gateway has actually picked up these requests and attached the real credentials, this means that the agent never has access to the real values. So if someone saw my agent logs or tried a prompt injection, they would never get these credentials as they live on a completely separate server and the agent has no way to access them. Just to show that injection process even cleaner, if I run this curl request on my terminal here, you can see it's rejected because I didn't pass it an API key. But if I run the exact same command through claw patrol run, the data is returned as normal as that API key is being injected. The next problem that claw patrol aims to solve is that access is an action control. Claw Patrol gives you really finite control over what an agent can do with a request. For example, if I use that Postgress skill again, but this time I ask it to drop a table and create a new one. When it runs, it immediately returns a customized error message that I've set up saying that schema changes only land via migration PRs, not via the agent. The gateway has actually looked into the Postgress request that my agent made and it's checked it against a rule set that I've defined and thanks to one of my rules, it's denied the drop table request. Another way that I could handle this is with human in the loop. So I can actually make this rule reach out to me to approve the action. At the moment, this one does only support Slack, but more options are coming soon as well. There's even an option to use an LLM as judge. And the rules are incredibly customizable and flexible, so you can even have rules like checking your customer support API endpoint that sends replies, and you can see if there's any offensive content, missing greetings, or just anything that you don't want leaked in that request. And again, all of this being done on the request on the gateway means that theoretically all of this is safe from prompt injections and pretty much every other type of AI attack. The third problem that claw patrol solves is that you can't see what the agent did. But with claw patrol, every single request is visible in the dashboard here. And you can even see active sessions as well as tokens used. And if you click into a request, you can see the relevant details like the Postgress command that was actually run or in the case of an API call, you can see the API request as well as the response that it got back. This way, you don't need to spend time combing through all of the logs of the individual services that the agent touched to try and work out what it did. And instead, you can just see what it did at the point of request. So, you should see pretty much everything that the agent does. That's the three problems that Claw Patrol aims to solve. But how is all of this set up? Well, once you have Claw Patrol installed, the gateway is actually all configured with a single HCL file. In here, you define the various endpoints that you're going to have rules and credentials for. So, I have various ones like OpenAI, Slack, SSH, Postgress, and so on. So if any request goes through the gateway that matches one of these, it knows to check the rules and credentials. As for the actual credentials themselves, the setup of that is pretty straightforward as well. You say what type of credential it is and what endpoint that credential should match. There's support for loads of credential types like anthropic subscriptions, codeex ones, click house, postgress, and also the basics like bearer tokens and custom headers. So you should find it supports nearly all of the types that you need. And even if it doesn't, you can actually code plugins to add your own type. Once you've defined a credential in here, all you need to do is head to the dashboard to fill in the actual value. Setting up rules is also fairly easy. You simply say the endpoint that the rule is going to apply to, and then you write the rule using common expression language. So this can cover a wide range of things like HTTP, Postgress, Kubernetes, and so on. After this, you then say the verdict for the rule that you've just defined with your approve or deny based on it. And you'd use a proof here if you were creating an allow list based approach instead of a block list one. So you'd block all by default and then only allow certain things. In my case though, I just simply used the block list method. Finally, another really useful feature here is profiles. You can actually group your credentials into multiple profiles, which means that any rules and endpoints attached to those credentials also grouped along with it. And this allows you to set up a sort of role-based control for your agents and your teams. So developers can have certain access to credentials and different rules for them. and maybe another team like a support team has different credentials and different rules as well. To help you out when you're making rule changes, there's actually a test command where you can download real actions from the dashboard and then rerun it against your local rule changes to see if any of them have changed the outcome so you can spot if there's going to be any accidental leaks. I must admit, I did actually find this setup process a little bit tedious and I'm sure it will be improved soon as this is very early in the project life. But if there was just a simple way to add credentials and rules from the dashboard, that would be absolutely awesome. perhaps something similar to how Adguard works where you can just see a request coming through and click to add a rule or a credential for that request. I did also run into a lot of issues when I was trying to add endpoints that were just IP addresses to my local Proxmox server. For some reason, it just didn't want to intercept those requests and I couldn't see any of them coming through on the dashboard and it just gave me a bit of a headache. So, there's definitely some fixes needed or maybe I was just misusing it. But either way, yes, it's going to be some work to get to a point of usability that doesn't interrupt your flow. But that does kind of make sense since this is all about security and not just sending an agent in yolo mode. So, let me know in the comments down below what you think about Claw Patrol and if you have any security tools that you use for your agents. While you're down there, subscribe and as always, see you in the next one., Deno Just Open Sourced Their Agent Firewall, YouTube, 01ksnkrmbjev1h6r4dymncz4qg.