Comment by oulipo2
4 days ago
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