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 as well (agent -> Claw Patrol -> Agent Vault -> external network)
EDIT: looking at some of the comments, it sounds like Claw Patrol can work with protocols beyond HTTP/S, so potentially covers more surface area than AV
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)
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.
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
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?
Disclosure: author of a related tool here. I have create agent-vault-proxy for a very similar reason. It also can help keep credentials out of the agent process. The agent gets a placeholder, the proxy swaps in the real secret in transit.
That’s great! IIUC Agent vault is an HTTPS proxy whereas Clawpatrol is a WG/Tailscale exit node so it can handle other protocols like
Postgres and SSH without processes co-operating via HTTP_PROXY
This is very interesting. I build something like this but native to claude code and something that focus on just logging the violation. My question is if you are terminating a process with in the workflow will that about all other things that executed before. anyway would love your feed back on this https://github.com/varmabudharaju/agent-pd
claw patrol runs on the network level. There’s no process being terminated - HTTP/SQL/etc are rejected based on rules that you define. it’s resilient to the agent making changes to its own hooks or bypassing a local sandbox.
The product looks great and I'm really interested in trying it out. Very cool, congrats on shipping! Also...as a parent of young kids: this name made me laugh out loud. The OG image on the marketing site is a fun easter egg.
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.
"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
Seems like a more general solution to a Tesla API Firewall that i was thinking about. My idea was to use some kind of gateway/firewall LLM to check commands that another agent would send to the Tesla API.
really interesting work! i am curious how you handle rule configuration for different protocols such as Postgres or ssh.
Thanks for open-sourcing it under MIT.
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
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.
Great name by the way, as someone who's been forced to watch the show by cousins.
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 as well (agent -> Claw Patrol -> Agent Vault -> external network)
EDIT: looking at some of the comments, it sounds like Claw Patrol can work with protocols beyond HTTP/S, so potentially covers more surface area than AV
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)
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?
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.
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
I wonder why u used go? i thought Deno would use to rust/ts. is it because of ecosystem? i've touched some agent guardrails. and i used python
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?
Nice work shipping this.
Disclosure: author of a related tool here. I have create agent-vault-proxy for a very similar reason. It also can help keep credentials out of the agent process. The agent gets a placeholder, the proxy swaps in the real secret in transit.
I read them as complementary: action firewall in front, credential broker behind. https://github.com/inflightsec/agent-vault-proxy
That’s great! IIUC Agent vault is an HTTPS proxy whereas Clawpatrol is a WG/Tailscale exit node so it can handle other protocols like Postgres and SSH without processes co-operating via HTTP_PROXY
This is very interesting. I build something like this but native to claude code and something that focus on just logging the violation. My question is if you are terminating a process with in the workflow will that about all other things that executed before. anyway would love your feed back on this https://github.com/varmabudharaju/agent-pd
claw patrol runs on the network level. There’s no process being terminated - HTTP/SQL/etc are rejected based on rules that you define. it’s resilient to the agent making changes to its own hooks or bypassing a local sandbox.
*abort
The product looks great and I'm really interested in trying it out. Very cool, congrats on shipping! Also...as a parent of young kids: this name made me laugh out loud. The OG image on the marketing site is a fun easter egg.
For those here without young kids in their life: https://en.wikipedia.org/wiki/Paw_Patrol
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.
"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
Seems like a more general solution to a Tesla API Firewall that i was thinking about. My idea was to use some kind of gateway/firewall LLM to check commands that another agent would send to the Tesla API.
really interesting work! i am curious how you handle rule configuration for different protocols such as Postgres or ssh. Thanks for open-sourcing it under MIT.
There's a plugin API https://clawpatrol.dev/docs/plugins/
How will credentials be injected via Gateway for each user ? If we have 5 users with one gateway, how it knows whose github credential to inject ?
You can define different profiles that are associated with different credentials. Take a look here https://clawpatrol.dev/docs/credentials/#single-credential-t...
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
Neat! Reading the docs - it's default-allow and ships with no rules? Any plans for a default rule set?
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
Gonna try it out
Interesting project. I like the implementation, congratulations on shipping!
I did this