Show HN: Claw Patrol, a security firewall for agents

107 pointsrough-sea4 days ago28 commentsView on HN

At Deno we've been using OpenClaw and other agents increasingly for addressing production problems in Deno Deploy - when a PagerDuty alert fires, the agent starts researching the cause and making fixes.

In order to do this, the agent needs access to real production systems - postgres, kubernetes, gcp, clickhouse, github, etc. But this is dangerous to say the least - we want destructive actions to be reviewed by other LLMs, approved by humans, and logged appropriately.

Claw Patrol terminates TCP connections over WireGuard or Tailscale, then parses application protocols (eg http, postgres, ssh) to apply rules that allow you to deny/allow requests.

There are a few projects that sit as a proxy in front of agents to do secret injection or apply various guardrails, but none met our needs (LLM gateways, MCP proxies, sandboxes), particularly the need to handle low-level protocols, or handle complex real world situations like tunneling postgres through k8s.

Written in Go, configured in HCL, MIT licensed. Happy to answer any questions.

https://clawpatrol.dev/

pavelpilyak4 days ago

Neat! Reading the docs - it's default-allow and ships with no rules? Any plans for a default rule set?

rough-sea4 days ago

Yes default allow and no rules by default. Some sort of default policy would be a great feature - I've been considering it. No one wants agents to DROP tables.

We have a big and detailed config file for our own internal use - but reluctant to release that exactly because it has information about our systems.

There's an example config file here that might be helpful https://github.com/denoland/clawpatrol/blob/main/examples/ga... - we use agents to write the config by pointing it at https://clawpatrol.dev/llms-full.txt

Apylon7774 days ago

This is a really cool library to look at even if you aren't running openclaw directly.

Lots of good concepts to seek inspiration from.

1. process-scoped egress policy

2. policy-as-code

3. explicit approval classes

4. normalized network/ guardrail receipts.

5. structured guardrail outcomes

6. centralized decision rules

rough-sea4 days ago

Thanks! Don't forget wire level protocol parsing - this is important because agents usually can spawn subprocesses and if they have postgres credentials, you're just one psql call away from disaster if you only have MCP/HTTP proxies in place.

oulipo22 days ago

So, why not instead limit your agents to a few endpoints / MCP functions that you control, which give access to your db (or whatever) through read-only permissions?

It seems this is a bit like "reinventing permissions" no?

rough-sea2 days ago

Could work - but our agents (codex/claude/openclaw) spawn subprocesses - imagine an engineer uses claude to debug an issue, it spawns psql directly, routing around MCP. Wire level interception is the only place a process tree can't escape.

Regarding reinventing permissions - scoped credentials solve this to some extent, but it's really nice to have a single place where we can define rules for all services (eg "DROP TABLE" never can occur), or you can SELECT unless it includes the env_vars.secrets column.

oulipo21 day ago

It would be able to spawn psql correctly, but wouldn't be able to connect to the database (if it's secured with user accounts). It would only be able to use the database through the MCP (which uses a read-only account to connect).

I understand the "centralized registry" thing, but it's also easy to "forget about one case", and agents are good at circumventing stuff ("oh, I cannot DROP table, let me just remove all rows", etc). So I'd rather trust the permissions of the original db (eg getting a read-only account) which I presume have been battle-tested for this