Live data from Hacker News

Show HN: Claw Patrol, a security firewall for agents

github.com

31–40 of 40 posts

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

#32
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…

[flagged]

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

#33
post #28

Earlier quoted context omitted.

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 T…

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

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

#34
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 syste…

"The principle is that the agent doesn't need code changes, including skills/MCPs - it just accesses systems."

That's why you're having safety issues.

The real (and boring, and tedious) way to do it IS to create a unique way (API, MCP, whatever) for the agent to access your data / infra in a secure way.

Think about it as "typing" in language. Sure it's boring to have to put all the type info (even though in many case it makes dev easier too, because it forces to construct stuff cleanly), but then once it typechecks, you're relatively sure that it's doing what it's supposed to.

Here it would be the same. You build basic building blocks that you know are safe for the agent to access, and you let it compose them

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

#37
Nice library and fast Go code, which is nice to know. I'm solving the similar problem, but on different level. The agentic runtime (Go too) I'm developing, applying safety guards on different layers, including redaction and compression plugins. Do you only block the agentic request or you can redact it in the middle? How do you solve LLM caching problems? What your agent see when it's request is blocked? Does it try to reformulate the request or just stops?
Post reply on HN