Claw Patrol: an open-source security firewall for agents

The article introduces Claw Patrol, an open-source security firewall developed by Deno to address the risks of giving AI agents access to production systems like AWS, Kubernetes, and databases. Unlike existing solutions that only handle HTTP traffic, Claw Patrol routes agent traffic through a WireGuard or Tailscale tunnel to a gateway that parses non-HTTP protocols (e.g., SQL, Kubernetes API), injects credentials, and enforces rules written in HCL—allowing verdicts like allow, deny, or multi-step approval chains involving LLM judges and human approvers.

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