Claw Patrol: an open-source security firewall for agents | DenoSkip to main contentIntroducing Claw Patrol: an open-source security firewall for agents<br>Read the post-><br>Dismiss
Claw Patrol: an open-source security firewall for agents<br>May 21, 2026<br>Ryan Dahl<br>Bert Belder<br>Divy Srivastava<br>Arnau Orriols<br>Yusuke Tanaka<br>Josh Collinsworth<br>Product Update
At Deno, we run Deno Deploy, JSR, and a handful of other production services.<br>We’re increasingly using agents to help with operations: triage PagerDuty<br>alerts, check dashboards, query logs, run kubectl, roll back a bad deploy, and<br>so on.
That means giving the agents access to many of the production systems an<br>engineer has: AWS, GCP, Postgres, Kubernetes, ClickHouse, GitHub, Slack,<br>Grafana.
This requires extreme care, and presents a dilemma.
An agent with limited access isn’t very useful. But the more access it has, the<br>more dangerous it is: kubectl delete namespace prod and<br>psql -c 'DROP TABLE users' are both one tool call away.
An agent cannot be trusted to police itself . The agent process holds tools<br>(psql, kubectl, gh, curl) and the credentials those tools need. A prompt<br>injection, a hallucination, or a bad tool call can use them.
And we can’t change how the agent behaves. Most of what we run (Claude Code,<br>Codex) is code we install, not code we wrote. Any solution has to sit outside<br>the agent.
A concrete example from our setup: We have a production Aurora database inside a<br>VPC, reachable only through an EKS apiserver. It’s extremely useful if our<br>agents, which run 24/7, have read access to this database. But we must ensure<br>the agent could never call DROP TABLE.
That’s an outbound network path the agent’s host can’t reach, on a protocol<br>that isn’t HTTP, gated by a rule that has to understand SQL.
There’s a growing set of projects and products around this area:
LLM gateways (Helicone,<br>Portkey, OpenRouter,<br>LiteLLM) and content guardrails<br>(NeMo Guardrails,<br>Lakera) watch the model call. Agents<br>talk to many services other than the models; those calls never reach the LLM<br>gateway.
HTTP tool-proxies (httpjail,<br>Crab Trap) gate the outbound HTTP call.<br>Agents also speak other non-HTTP protocols like Postgres and SSH.
Process sandboxes<br>(NVIDIA OpenShell,<br>agentsh) are generally focused on local access<br>that the agent can make. We already run our agents on standalone VMs; for us<br>these are only marginally useful.
Credential-injecting forward proxies<br>(Agent Vault,<br>Clawvisor) terminate TLS, inject<br>credentials, and filter outbound HTTP. They match on HTTP method and URL, not<br>other protocols; they decide allow or deny, without composing LLM judges and<br>human approvers in chains; and they don’t tunnel onward to networks the<br>agent’s host can’t reach.<br>(Deno Sandbox ships a similar<br>capability.)
Each of these is solving part of the problem . None of them speak anything<br>beyond HTTP, however, and no combination of them reaches a Postgres database<br>through an EKS apiserver, or gates by SQL verb.
For agents touching real production systems, that gap is the whole game.
Today we’re open-sourcing our solution to this problem: Claw Patrol
Agent traffic routes through a WireGuard or Tailscale tunnel to a gateway that<br>terminates TLS, parses the inner protocol, holds and injects the real<br>credentials, and evaluates each request against rules you write in HCL. The<br>gateway can tunnel onward to reach networks the agent’s host can’t (a kubectl<br>port-forward into EKS, a Cloud SQL proxy, a tailnet).
Here’s one rule from our config, as an example, denying reads of Kubernetes<br>secrets across our deploy clusters:
rule "k8s-no-secrets" {<br>endpoints = [kubernetes.deploy-dev, kubernetes.deploy-prod]<br>condition = "k8s.resource == 'secrets'"<br>verdict = "deny"<br>reason = "Secret values must not leave the cluster via the agent"<br>Rules match on parsed protocol facets: HTTP method, path, and body; SQL verb,<br>tables, and functions; Kubernetes verb, resource, and namespace. Verdicts can be<br>allow, deny, or a chain of approvers: a model judging against a policy you<br>write, a human in Slack, or both in sequence. We use the chain to gate<br>customer-support replies our agent drafts. The LLM checks the body for markdown<br>and tone, then a human in #support approves or edits the draft.
Credentials live on the gateway, not the agent . The agent sends a<br>placeholder like {{github_pat}} and the gateway swaps in the real token on the<br>wire. A compromised agent process can’t leak keys it never held in the first<br>place.
While we’re excited to share Claw Patrol (under MIT license), it is currently<br>alpha software. This is what’s working for us, so the protocol support is as<br>broad as we need it. You’ll find sufficient documentation to code up support for<br>other protocols. We’d especially love to see rule patterns from real<br>deployments, protocols you’d want gated next, and rough edges in the install<br>path. Issues and PRs welcome.
The getting-started guide takes<br>you from zero to a working gateway in five minutes.
Site:...