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.
MCP has plenty of problems, but standardising on OAuth was one of the better calls. Expiry, scopes, rotation, delegated access, all much better than the usual CLI pattern of long-lived API keys. The CLI story there is still pretty rough.
And once the policy model is host/path matching, GraphQL and JSON-RPC become awkward immediately unless the proxy starts understanding payload semantics.
What this appears to be is that we are now reinventing proxies with policy control and the best part of this is the solution (OneCLI) has no security audit. This would give a complete dismissal from the infosec teams to even attempt integrating this vibe-coded slop.
As long as the fake keys are known, they can be mapped directly to the real key with the endpoint in OneCLI to exfiltrate the data and you don't need to leak any keys anyway.
The correct solution is that there should be no sort of keys in the VM / Container in the first place.
> It is backwards. I bet we will move from CLIs to something else in about 3-6 months.
The hype around CLIs is just as unfounded as was MCPs and made no-sense just like OpenClaw did. Other than hosting providers almost no-one is making money from OpenClaw and from its use-cases; which is just wasting tokens.
We'll move on to the next shiny vibe-coded thing because someone else on X said so.
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.
On (1), the agent runs in its own container where OneCLI doesn't exist. It can't spin up OneCLI or access its process because it's completely isolated from it. The agent only ever sees placeholder tokens, the real secrets live in a separate container it has no way to reach.
On (2), we actually address this with OneCLI Rules, deterministic constraints enforced at the proxy level before a request ever hits the API. So the agent doesn't need to "behave", it just can't do what the rules don't allow. Would love to hear more about your signed tokens approach.
I don't get the idea of giving a claw access to your own mail account, but am now playing with the idea of it having its own email account that I selectively forward to - that offers almost the full benefit, with significantly less risk.
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.
MCP has plenty of problems, but standardising on OAuth was one of the better calls. Expiry, scopes, rotation, delegated access, all much better than the usual CLI pattern of long-lived API keys. The CLI story there is still pretty rough.
And once the policy model is host/path matching, GraphQL and JSON-RPC become awkward immediately unless the proxy starts understanding payload semantics.
As long as the fake keys are known, they can be mapped directly to the real key with the endpoint in OneCLI to exfiltrate the data and you don't need to leak any keys anyway.
The correct solution is that there should be no sort of keys in the VM / Container in the first place.
> It is backwards. I bet we will move from CLIs to something else in about 3-6 months.
The hype around CLIs is just as unfounded as was MCPs and made no-sense just like OpenClaw did. Other than hosting providers almost no-one is making money from OpenClaw and from its use-cases; which is just wasting tokens.
We'll move on to the next shiny vibe-coded thing because someone else on X said so.
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.
On (1), the agent runs in its own container where OneCLI doesn't exist. It can't spin up OneCLI or access its process because it's completely isolated from it. The agent only ever sees placeholder tokens, the real secrets live in a separate container it has no way to reach.
On (2), we actually address this with OneCLI Rules, deterministic constraints enforced at the proxy level before a request ever hits the API. So the agent doesn't need to "behave", it just can't do what the rules don't allow. Would love to hear more about your signed tokens approach.
I also do not understand the uses right now. Are we just grasping at usefulness ?
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!