OneCLI launches open-source sandboxed agent harness for teams
OneCLI started as a credential vault for AI agents, built in Rust. The team behind it found that most of the demand came from individuals and teams already running autonomous agents such as Hermes, OpenClaw and NanoClaw, tools built for a single user. Replicating one of those agents across a team turned out to be messy: spinning up each agent by hand, deciding what it could and could not do, hosting it, and keeping track of whose agent was whose. Two pieces were missing: managing secrets and permissions, and, for teams specifically, this kind of multiplayer management. That gap is why the company built OneCLI v2, the version it introduced in a Launch HN post identifying OneCLI as a Y Combinator S26 company.
OneCLI v2 provisions an agent for each employee directly from the company's identity provider. Every person in the workspace gets a personal, sandboxed agent reachable from a web dashboard or from Slack. A team's policy is defined once and enforced on every agent in the workspace, and deterministic human-in-the-loop approval gates sit inside the chat itself for actions a user wants full control over, such as sending an email, deleting a Linear ticket, or emptying an S3 bucket, giving 100% control over those specific actions. Shared resources such as LLM keys or service accounts are granted per agent at the team level without ever being handed directly to any individual agent.
OneCLI treats an agent as a durable thing rather than a single prompt. Each one runs in its own isolated sandbox with a filesystem and a shell, and the only way out of that sandbox is a gateway, so the agent can reach only what it has been granted. Its conversation lives on its own page in the dashboard or in Slack, complete with images and files, and a new message sent while the agent is working interrupts it immediately instead of queuing behind the current task. What the agent learns becomes memory kept by the platform, readable and editable at any time, and reusable skills, meaning instructions and helpers written once, stay available to it from then on. An agent can also be given a schedule so the platform wakes it to do planned work later. It never sees its own credentials directly: the gateway injects them per request, or, for on-demand injection, OneCLI can connect to Bitwarden or 1Password with nothing stored on OneCLI's own server. Each agent additionally gets its own named, avatar-bearing Slack app; deleting the agent removes that Slack app with it.
Agents run on the customer's own infrastructure rather than OneCLI's. The runner component is outbound-only and holds no inbound ports, so it works unmodified on a laptop, a homelab, or a VPC sitting behind NAT, with no inbound access and no tunnel required. The stack breaks down into a Next.js web dashboard for creating and chatting with agents and managing their memory, skills, connections and grants; an API server that acts as the control plane, owning the database, the conversation plane and the work queue; the Rust gateway itself, which intercepts outbound requests, HTTPS included, through a man-in-the-middle technique, injects credentials, and authenticates agents with access tokens carried in Proxy-Authorization headers; the runner, which starts, parks and reaps agent sandboxes without ever touching the database; a sandbox supervisor running inside each sandbox that speaks a vendor-neutral harness interface, so the underlying agent runtime can be swapped out; a channel adapter that runs the Slack integration, one app per agent; and a secret store that keeps credentials encrypted with AES-256-GCM at rest, decrypts them only at request time, matches them by host and path pattern, and injects them as headers or query parameters.
OneCLI is available both as a cloud-hosted service at onecli.sh and as a self-hosted install, cloned from GitHub and brought up with a pnpm-based setup documented in the project's docs/development.md. Licensing splits the project in two: everything outside its ee/ directories is Apache-2.0 and can be self-hosted in production with no commercial license, while the ee/ directories carry a separate OneCLI Enterprise License that is free for development, testing and evaluation but requires a paid subscription, price undisclosed, once used in production. The post names no funding amount, valuation or investor; the only accelerator reference anywhere is the 'YC S26' tag in its own title, and no individual founder or team member is named in the body text.
Key facts
- OneCLI v2 provisions a sandboxed AI agent for each employee straight from the company's identity provider, with every agent reachable from a web dashboard or from Slack.
- A single team policy is enforced across every agent, and human-in-the-loop approval gates sit inside the chat for actions like sending an email, deleting a Linear ticket, or emptying an S3 bucket, giving 100% control over those actions.
- Each agent's sandbox can only reach the outside through the Rust gateway, which intercepts outbound HTTPS through a man-in-the-middle technique and injects credentials via Proxy-Authorization headers; the runner itself is outbound-only and holds no inbound ports.
- Credentials are encrypted at rest with AES-256-GCM in a Secret Store decrypted only at request time, or injected on demand from Bitwarden or 1Password with nothing stored on OneCLI's server.
- The core project is Apache-2.0 and free to self-host in production; only the ee/ enterprise directories need a paid subscription for production use, and a cloud-hosted version is available at onecli.sh.
Why it matters
OneCLI is chasing a specific, narrow gap: today's autonomous coding and ops agents, tools like Hermes, OpenClaw and NanoClaw, are built for one person, and a company that wants ten or a hundred of them running has no standard way to provision, police or audit them the way it already does employee laptops and accounts. OneCLI's answer is to route every agent's identity through the company's own identity provider and every credential through one Rust gateway, so a security team sets one policy instead of trusting each employee's individual agent setup. That is a fleet-management problem, not a capability problem, and it is a different pitch from most agent frameworks, which compete on what a single agent can do rather than on how many of them an organization can safely run at once.
Who it affects
The most direct audience is companies already letting employees run autonomous agents for real work and now needing to manage that at team scale: IT and security staff who own identity, secrets and access policy, and the engineering or ops teams whose agents need to touch things like email, ticketing systems, or cloud storage under supervision. It also matters to teams already using Hermes, OpenClaw or NanoClaw, since OneCLI's pitch is explicitly built around wrapping agents like those. And it is relevant to competing credential-vault and agent-orchestration vendors, since OneCLI is positioning its gateway and sandbox as infrastructure other agent tooling would sit behind, rather than as another agent in the crowd.
How to use it
Self-hosting starts with a git clone of the onecli/onecli repository, a pnpm install, and a setup command; the project's docs/development.md covers prerequisites, the full command reference, project structure and configuration, and a single pnpm dev command generates the required secrets, starts PostgreSQL, applies migrations and brings up the full stack for local development. In production, agents run on the customer's own infrastructure rather than OneCLI's, and the runner needs no inbound ports, so it works behind NAT on a laptop, a homelab or a VPC with no tunnel required. A cloud-hosted alternative is available directly at onecli.sh for teams that would rather not run the stack themselves. On licensing, the core project is Apache-2.0 and free to self-host in production; only code inside the ee/ directories, the enterprise features, requires a paid subscription once it is used in production, and that price is not stated in the post.
How solid is it
Every claim here comes from OneCLI's own Launch HN post, written by the company itself, not from an independent review, benchmark or outside reporting, so it should be read as a pitch rather than as a verified account. The technical detail is specific enough to suggest a real, working system rather than a slide deck: a named gateway architecture, a stated encryption scheme for stored secrets, an outbound-only runner, and a vendor-neutral sandbox interface are the kind of details a team usually only writes down once it has built them. Set against that, the post gives no user count, no named customer, and no download or adoption figures to show the platform is in use at any scale, and it discloses no funding amount, valuation or investor, the only marker of outside backing being the 'YC S26' tag in its own title.
Risks and caveats
The central mechanism, a gateway that intercepts an agent's outbound HTTPS traffic via a man-in-the-middle technique in order to inject credentials, is also the central risk: the post does not explain how that interception is made safe for the agent's other traffic, how certificates are handled, what the agent or the user consents to, or what happens if the gateway itself is ever compromised, since it now sits in a position to see and alter every request an agent makes. Production use of the enterprise features carries a subscription cost that is not disclosed anywhere in the post. And because no founder or team member is named and no funding, customer or usage numbers are given, there is no way from this source alone to gauge how established the company is beyond having a spot in Y Combinator's S26 batch.
“An agent is a durable thing, not a single prompt.”
— OneCLI, Launch HN post