Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Claw Patrol, a security firewall for agents

github.com

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Show HN: Claw Patrol, a security firewall for agents

#25

Post by rough-sea »

MadsRC wrote: post #24

The approval part is really interesting - No problems with timeouts or operators not being around to approve?

If the operator isn't around, then it shouldn't be approved. But yes, this is a problem, we have to ask the agent to retry after approval if its timed out. Currently the design philosophy is that the agent doesn't need to know anything about the firewall - no skill files, no code changes, completely transparent. But we're soon introducing a discovery endpoint that will allow the agent to know which services it has credentials for and tell the agent how to poll for HITL approval. This is an area of active development: https://github.com/denoland/clawpatrol/pull/666

Re: Show HN: Claw Patrol, a security firewall for agents

#26

Post by rough-sea »

jameslk wrote: post #18

I think this sounds very cool! It sounds similar to Agent Vault (github.com/Infisical/agent-vault) but with an added feature of having security policies for denial/human-in-the-loop of traffic based on the contents of requests? The nice thing about Agent Vault is the encryption of credentials and other ways they handle making sure those don't leak from storage. I suppose you could potentially wrap the two in layers a…

Yes works at the wire level, not http. Have a look at the example config file https://github.com/denoland/clawpatrol/blob/d2e531d8cb0f1a3a...

Claw Patrol holds credentials - so probably doesn't make sense to layer with AV - but it's true that AV has more sophisticated storage of creds (eg using 1p)

Re: Show HN: Claw Patrol, a security firewall for agents

#27

Post by oulipo2 »

Not sure why I would put another software to check that the agent doesn't do "SQL writes", rather than providing them... with a read-only account?

It looks like those projects are trying to reinvent service-accounts and permissions... Just define the permissions for each of your APIs, and provide only endpoints to these (through MCP or whatever) to your agents...

Re: Show HN: Claw Patrol, a security firewall for agents

#28

Post by oulipo2 »

rough-sea wrote: post #5
Apylon777 wrote: post #3

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

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.

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?

Re: Show HN: Claw Patrol, a security firewall for agents

#29

Post by rough-sea »

oulipo2 wrote: post #28
rough-sea wrote: post #5

Earlier quoted context omitted.

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.

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?

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.

Re: Show HN: Claw Patrol, a security firewall for agents

#30

Post by rough-sea »

oulipo2 wrote: post #27

Not sure why I would put another software to check that the agent doesn't do "SQL writes", rather than providing them... with a read-only account? It looks like those projects are trying to reinvent service-accounts and permissions... Just define the permissions for each of your APIs, and provide only endpoints to these (through MCP or whatever) to your agents...

It's not about enforcing read-only - we want agents to do destructive things. Like rebooting a pod, rolling back a deployment, etc.

Plus a lot of these services are reached by tunneling through something else. We tunnel into k8s where it has dangerous credentials.

We also don't want to define MCPs for everything. The principle is that the agent doesn't need code changes, including skills/MCPs - it just accesses systems.

Claw Patrol lets us give agents more access because it's watching everything at the wire. `kubectl delete pod foo` waits for slack approval, SELECT on env_vars runs through an LLM judge to check if it actually returns secret data. For our setup this is security policy that is a single file, checked into git, that gates access across 14 k8s clusters, clickhouse, postgres, a dozen other HTTP APIs.

Post reply on HN