Show HN: Claw Patrol, a security firewall for agents
github.comIn 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.
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
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
It seems this is a bit like "reinventing permissions" no?
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.
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