alt Hacker NewsNice 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.
Replies
At a basic levels, access layers should be aware of operations that are Read-only and operations that are Write/Delete. It should be easy to give agents access to read anything, then require permission/prompt to execute any state changing operations.
Creator of OneCLI here.
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.