From a security standpoint, I'm glad that people are starting to pay attention to basic security practices.
That said, while I'm hardly a fan of MCP (judge for yourself by reviewing my previous comments on the matter), at least its security model was standardised around OAuth, which in my opinion is a good thing, albeit with a few small issues.
I personally prefer CLIs, but their security is in fact worse. A lot worse! Sure, we can now store API keys in a vault, but it's not like you can rotate or expire them easily. Plus, the security model around APIs is based on path-based rules, which aren't very effective given that most services use REST-style APIs. This is even worse for GraphQL, JSON-RPC, and similar protocols.
It is backwards. I bet we will move from CLIs to something else in about 3-6 months.
I'm a little shocked that someone like 1Password hasn't released a vault access + approvals model. There are a lot of little menial tasks that I'd love for an agent to take care of ("book me a hair appointment next week when my calendar says I'm free"). Agent has access to a locally synced calendar and can see the existence of a password for the booking portal in my vault, asks to use it, I get a push notification and can approve.
These kinds of things aren't common enough for me to want to set up a programmatic policy, and are also low sensitivity enough that I don't mind giving access to complete the task. If it later asks to log into my bank, I decline.
I know the devil's in the details for how to actually do this well, but I would love if someone figured it out.
Nice upgrade. userpsace HTTP proxies are a good start and should make unlikely that a secret gets into the context window due to a high permission read. There are a few missing pieces in the agent security world in general
1. Full secret-memory isolation whereby an agent with root privileges can't exfilrate. Let's assume my agent is prompt injected to write a full-permissions script to spin up OneCli, modify the docker container, log all of the requests w/ secrets to a file outside the container, exfiltrate.
2. An intent layer on top of agents that models "you have access to my gmail (authN) but you can only act on emails where you are a participant". This would be more similar to universal RBAC between agent ↔ mcp etc.
I've been building on [2] for a while now using signed tokens expressing intent.
Since the vault sees every outbound request with the real credential attached, are you logging all of that? Feels like you're sitting on a full audit trail of everything agents actually did across services. That would be huge for debugging agent behavior after the fact.
> You can set rate limits so an agent can only send or delete a few emails per hour
Nice idea, but it will not work. Agents are so resourceful and determined, they will find that weird call which can delete all emails with one request (/delete?filter=*)
NanoClaw Adopts OneCLI Agent Vault
(nanoclaw.dev)103 points by turntable_pride 6 hours ago | 29 comments
Comments
That said, while I'm hardly a fan of MCP (judge for yourself by reviewing my previous comments on the matter), at least its security model was standardised around OAuth, which in my opinion is a good thing, albeit with a few small issues.
I personally prefer CLIs, but their security is in fact worse. A lot worse! Sure, we can now store API keys in a vault, but it's not like you can rotate or expire them easily. Plus, the security model around APIs is based on path-based rules, which aren't very effective given that most services use REST-style APIs. This is even worse for GraphQL, JSON-RPC, and similar protocols.
It is backwards. I bet we will move from CLIs to something else in about 3-6 months.
These kinds of things aren't common enough for me to want to set up a programmatic policy, and are also low sensitivity enough that I don't mind giving access to complete the task. If it later asks to log into my bank, I decline.
I know the devil's in the details for how to actually do this well, but I would love if someone figured it out.
I still wouldn't give to any claw access to my mail accounts, but it is a step in the good direction.
I love how NanoClaw is aggregating the effort of making personal assistants more secure.
Good job!
1. Full secret-memory isolation whereby an agent with root privileges can't exfilrate. Let's assume my agent is prompt injected to write a full-permissions script to spin up OneCli, modify the docker container, log all of the requests w/ secrets to a file outside the container, exfiltrate.
2. An intent layer on top of agents that models "you have access to my gmail (authN) but you can only act on emails where you are a participant". This would be more similar to universal RBAC between agent ↔ mcp etc.
I've been building on [2] for a while now using signed tokens expressing intent.
It’s not that agents have access to something the shouldn’t have but that the creates havoc exactly with the access they are allowed to have.
Nice idea, but it will not work. Agents are so resourceful and determined, they will find that weird call which can delete all emails with one request (/delete?filter=*)