YC-backed OneCLI turns "one sandboxed agent per employee" into enterprise access control

Here’s a small but useful shift in how companies might let AI agents touch real business tools.

A YC-backed project called OneCLI started out as a Rust based credential vault. It’s now pivoting into something more like a policy gateway. The idea is simple. Instead of handing an AI agent your actual GitHub, Gmail, Notion, or Dropbox credentials, you give it a sandboxed environment tied to one employee, and the gateway injects the right credentials into that sandbox when needed. The agent never sees the raw secrets. It works underneath whatever agent framework or harness you’re already using, so it’s not locked to one AI tool.

Why should an owner care about this. If you’ve let any team member use an AI agent to check email, update a Notion doc, or push code, you’ve probably already faced the question of how much access that agent actually has. Most setups today are all or nothing. You either give the agent your real login or you don’t let it touch the tool at all. That’s a rough tradeoff when you’re trying to get real work automated. A system that treats “one sandboxed agent per employee” as the access control model gives you a middle path, closer to how you’d manage a new hire’s permissions on day one rather than handing them the master password.

The project launched on Hacker News with 85 points and 25 comments, which suggests real interest from technical people, though it’s still early and unproven at scale. It’s open source, and self-hosting docs were live from day one, per the OneCLI repo. This kind of credential and access layer is exactly the sort of thing we build into an AI command centre, so agents get useful access without anyone handing over the keys to the whole business.