Deno Just Open Sourced Their Agent Firewall (Claw Patrol)

EnglishالعربيةDeutschEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский中文
BBetter Stack
컴퓨터/소프트웨어창업/스타트업AI/미래기술

Transcript

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

Key Takeaway

Claw Patrol secures AI agents by centralizing credential management, enforcing granular request control through rule-based firewalls, and providing real-time visibility into all agent-driven traffic.

Highlights

  • Claw Patrol functions as an open-source security firewall that intercepts and controls traffic between AI agents and the internet.

  • Credentials like Postgres passwords or API keys live exclusively on the gateway server and are injected into requests only at the moment of execution.

  • Agent actions are restricted via Common Expression Language rules that can block unauthorized commands, such as preventing drop table operations in a database.

  • The central dashboard provides visibility into all agent traffic, allowing for inspection of specific API requests, responses, and active sessions.

  • Gateway configuration uses a single HCL file to define endpoints, credentials, and security rules across multiple environments like OpenAI, Slack, and SSH.

  • Human-in-the-loop approval processes are supported for sensitive actions, with current integration for Slack and future support for additional platforms.

Timeline

Architectural Overview and Purpose

  • Claw Patrol sits as a gateway between AI agents and external services to mitigate security risks.
  • The system separates agent execution environments from the central gateway where rules and credentials reside.
  • Tailscale and WireGuard are supported for connecting agent machines to the gateway.

The architecture consists of a central gateway server and multiple agent-running machines. The gateway manages credentials, logs, and security policy enforcement. It supports flexible deployment options, such as routing traffic from specific terminal commands or entire machines via standard protocols like Tailscale.

Credential Management and Injection

  • Credentials remain on the gateway server and are injected into requests as they pass through.
  • Agents do not possess real API keys or passwords, protecting them against prompt injection or log scraping.
  • The gateway automatically attaches required authentication headers to requests initiated by agents.

By moving sensitive data out of the agent environment, the system ensures that even if an agent is compromised, the actual credentials remain safe on the gateway. The process works by identifying agent requests and applying the necessary authentication headers or passwords before forwarding them to their destination.

Fine-grained Access Control

  • Common Expression Language (CEL) enables the creation of complex security rules for diverse endpoints.
  • The gateway can block specific commands, such as dropping database tables, based on defined policies.
  • Human-in-the-loop approvals and LLM-based judges are available to govern sensitive agent actions.

Security policies go beyond simple access, allowing for deep inspection of request content. For instance, database operations can be restricted to specific commands, and API payloads can be scanned for offensive content or data leaks. This mechanism enables a proactive defense against unauthorized or malicious AI activity.

Visibility and Configuration

  • All agent traffic is recorded in a centralized dashboard for auditing and monitoring purposes.
  • Gateway configuration is managed via an HCL file and supports custom plugins for non-standard credential types.
  • Profiles enable role-based access control, allowing different teams to manage unique sets of rules and credentials.

The dashboard provides a unified view of all request-response pairs, eliminating the need to parse scattered logs from disparate services. While the setup currently requires manually managing an HCL configuration file, the project includes testing tools to validate rules before deployment. Further usability improvements are expected as the project matures.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video