87 points by guyb3 3 days ago|29 comments
Hi HN, Jonathan & Guy here from OneCLI, an agent harness built for teams, giving every employee a secured, sandboxed personal agent.

Here’s what you can do with it:

1. get a sandboxed agent, with all the OneCLI capabilities in place like connect your GitHub account, Gmail, Notion, or Dropbox simply from the chat.

2. deterministic human in the loop approval in the chat itself for things that you need 100% control like sending an email or deleting the Linear ticket.

3. manage team policy in one place, enforced across every agent in the workspace

4. enjoy global connections at the team level, like shared LLM keys or service accounts

Here’s a demo: https://www.youtube.com/watch?v=dlW-44ntpbE

We started working on this by accident, even though our careers were in the security space. We were working on a devtool called ChartDB, an open-source DB tool. When OpenClaw took off back in January, we started using it to orchestrate agents on top of ChartDB. We quickly understood there is a big issue around auth. Agents need credentials to do real work, but to give them those secrets would not be the best idea. They keep them in their memory and also write them down to local files and their sessions as plain text. And we knew that agents can easily be fooled into giving up those API keys/secrets. So we needed some way to control the agent and stop prompt injections from tricking it into using its services for an attacker's benefit.

We created OneCLI that started as a vault for AI Agents built in Rust.

We found out that most of our demand for OneCLI came from autonomous agents like Hermes, OpenClaw and NanoClaw for individuals and teams.

Users looked for useful agents that do things for the person who runs them with two missing parts: 1) managing secrets and permissions. 2) and for teams - multiplayer management.

We decided to pivot and provide the agent itself as a harness for teams, to give each employee an agent. We saw that teams had to deal with setting up their own harness again and again, and basically as we already had the vault as a gateway. We got the idea to provide the missing piece of the agent management out of the box and open source it (Apache-2.0, with a small enterprise exception).

We're open source first - the entire platform, not just a small portion of it like other agents, so companies can actually see the code, evaluate it, and trust it instead of taking our word for it. They run it isolated, in their own environment, fully under their control, at production quality, not a locked black box hosted somewhere else. That means the safety isn't just a promise, it's something they can verify themselves. Combined with real autonomy and least-privilege access, that's what makes it something a company can fully own and trust, not just adopt.

We also approach this from a company perspective rather than an individual one. Our solution manages agents on behalf of each employee, wrapped in deterministic guardrails that company admins configure through centralized policies.

For the agent engine itself we’re using jcode which is the core of the agent-loop. We found out that it improves the experience and makes the agent smarter and faster.

Here’s how it works:

It runs on infra you control. Fully open-source, self-host or cloud in minutes.

The agent never holds a real secret. It gets a placeholder. The real credential is injected at the gateway, per request, after the call is authorized. It never enters the agent's context, memory, or logs.

Enforcement outside the model. Prompts are suggestions. Policies defined by the org admin run at the network layer, outside the agent and the LLM. Block endpoints, rate limit per agent, require approval, scope per employee. The gateway decides. The agent can't bypass it.

Isolated VM per agent. Own memory, own keys, own permissions. Blast radius is one agent.

Speed of the Harness: Rust engine under the agent loop.

Full identity trail. Every agent is bound to an employee. Every call logged with who it acted for and which policy allowed it.

Some things people are doing with the platform include:

- Managing their company life cycle entirely from the sales calls, to the product side automatically open tickets to the engineering teams, that would kick the development agents to deliver and ship to production.

- Operational side, like automatically hygiene the CRM after calls, sourcing leads, book meetings and manage follow ups emails.

- Some of our customers also doing their entire grocery shopping using those agents and send them to take care of their chores like ordering things online.

About the team: Both founders come from cybersecurity backgrounds. Jonathan spent years at Axis Security building zero trust network access. The core idea is that you never trust the client. You decide exactly what a person can reach, and you enforce it outside of them, at the network layer, so it doesn't matter what the client tries to do. That's how every serious company gives access to humans today. Guy was the 1st employee in Argon security doing AppSec.

We would love to hear your thoughts on the move, happy to get issues open to improve and get your agent to be powerful and secure - designed for teams, not just individuals.

ericmaciver 17 hours ago
The "policy in one place, enforced across every agent" part is the piece I would have underrated a year ago.

I went looking for that in my own codebase and found six independent secret-redaction denylists, no two of which agreed. Measured against 17 real credential shapes, the list I thought was canonical caught 10. The seven it missed included a GitLab PAT, a Supabase key, a Cloudflare token and a literal password= . The widest list was a fork, not the canonical one, and only the union of all six covered everything. Nobody wrote six on purpose. Each was locally reasonable when it was added and there was no single place to put the rule.

So the question I would ask about the team layer: when a policy changes, is there exactly one artifact every agent reads, and can I diff what an agent was actually allowed to touch at run time against what the policy said? Enforcement I can audit afterward is worth a lot more to me than enforcement I have to trust.

ezzy-1630 3 days ago
Keeping the real credential out of model context is a meaningful improvement, but the gateway still becomes a confused-deputy boundary. How granular are policies below the endpoint level? An agent allowed to call a CRM API may still be tricked into exporting the wrong customer or changing a field it should only read. I'd be interested in whether policies can constrain method, path, request fields, resource ownership, and response volume, and how those rules are tested against prompt injection.
coder-pm 20 hours ago
OneCLI controls what the agent can reach. It doesnt control where it runs. Block a leaked key and the process is still on your host, so a bad rm or a prompt injected "clean up this repo" still hits real files. So I would stack them, not pick one. Sandbox the agent so it can't touch anything you care about, then route egress through a policy layer like this. Reach and blast radius are different problems:)
aliasxneo 3 days ago
How do you even win in this space? I feel like every day I see either a paid or fully OSS version of this product being posted here. As an end user I've become so overwhelmed that I've just started to mostly ignore them at this point. I can't be the only potential customer feeling this way?
guyb3 3 days ago
Honestly, we're not sure yet how we win this space. We both come from security backgrounds, and that's probably what led us to where we are today. basically we built the gateway first because we were afraid of using openclaw the way it came out of the box. we didn't even connect our gmail out of fear. then after a while working with agents behind the gateway, we just started building our own agent that integrates better with it, for me and my partner. So maybe it lands with the same kind of people as us, who worry about the security side and want that safe feeling. Still figuring out how many of us are out there.
rukshn 3 days ago
This I fully agree. I think I was few who never wanted to try Open Claw or wanted to connect my accounts because I saw someone at Meta getting their emails deleted.

Then after I listened to Garry’s talk on Gbrain last week I thought why not give it a try.

So connected my email and calendar to a simple agent I built via MCP and I get a summery of important emails and also delete all non important ones.

Still a WIP: https://github.com/rukshn/zen

But I agree the space is very much crowded

colesantiago 3 days ago
You're not alone, I don't get it either and this market is extremely crowded with many agent tools popping up everyday.

Some closed source, lots that are open source, hundreds of thousands and many which are completely vibecoded.

I feel that YC just invests in anything these days.

I mean, I don't see a moat here.

Like, why this over Grok Bot or anything that Anthropic or OpenAI would make for their 900M+ users?

Or is that the goal all along? Get acquired by a lab?

nrmitchi 3 days ago
> I feel that YC just invests in anything these days.

When there is a popular gold rush, YC invests in many companies that do the same thing with the expectation that 1) a rising tide lifts all ships, and 2) if there is a clear winner, they have eggs in every basket.

guyb3 3 days ago
It’s definitely a crowded space, totally agree about it. honestly for us we didn't want to commit to a specific provider, whether that's grok or openai. So we decided to go with a harness that lets us switch models easily when one is down, or when another provider comes out with a new improved model
robbomacrae 3 days ago
Yep. OrcaBot has all these features. Free on desktop.

It's been out for 6 months.

hugorus87 2 days ago
Sandbox choice matters more than most agent harnesses admit. Docker-in-Docker vs firecracker vs unshared namespaces each break in different ways once you start bind-mounting the user's repo. Curious which tradeoff you picked and why.
taoh 3 days ago
The important detail is whether approval binds to the exact proposed action, including the recipient, repository, issue, or data being sent, rather than just “allow Gmail” or “allow this endpoint.” How granular are the gateway policies for APIs where read and write actions share the same host?
Jonathanfishner 3 days ago
jonathan from OneCLI here, yes - approval binds to the exact req by opening it (method, URL, body) when there’s a matching policy defined. then the gateway holds the call and the card shows the parsed payload.

just to clarify how it works - on same host, rules match based on method + path + body, not only the host. for example, GET /calendar/v3/* can be allowed while POST needs approval.

GiganticCupcake 3 days ago
In a similar vein, I've been playing with Nemesis8. It provides the same sandbox and network constraint as this repo but adds orchestration and observability. You can control and communicate a fleet of agent containers that persist sessions, configure MCP tooling, and schedule events. That appears to just be the surface, I'm still digging into it. Now that I've experienced this single-pane-of-glass interface, I don't think I'm going back. If this is a trend, I hope it sticks. Check it out: https://github.com/DeepBlueDynamics/nemesis8
snthpy 3 days ago
Looks good , but I don't understand the licensing. The bottom of the read me says it's Apache 2.0, except for the /ee folder, but I don't see the /ee folder in the repo, at least not at the top-level. I also don't see anything about what the enterprise features are on the actual web page.
FailMore 3 days ago
I think it's pretty interesting - I can see why companies would want to go for this instead of build everything themselves...

Curious about how your customers are responding to pricing. 20 agents for $499/month without API costs included feels steep... but perhaps within the range of "worth it if we don't have to think about this".

sagarpatil 3 days ago
madmecodes 2 days ago
If every agent action maps to a real user, with clear limits and logs, agents become much easier to trust.
brunoborges 3 days ago
Honest question, how does this project already has over 3,200 stars on GitHub?

Their video demo was posted 13 hours ago, and it only has 38 views as of the time of this post.

The post on HN is 4 hours ago.

brabel 2 days ago
I’ve known them for months, the product was available for at least that much time. I guess this is just a funding announcement, not a launch from nothing.
pitzips 3 days ago
I started using OneCLI when Nanoclaw (came out just after Open Claw) announced them as the way to handle credentials. I think that may have been their first boost?
frangonf 3 days ago
I had the project already starred, I lurk around the sandbox space from time to time, and the project it's a few months old and was already discoverable and in a usable state before today.
brunoborges 3 days ago
Still, over 3,000 stars so quick? It's just weird.
soltanov 3 days ago
The earliest repository commits and initial public announcements show this date: March 17, 2026.
grugnog 3 days ago
How do credentials work to access user data with the right permissions? Is there a way to integrate OAuth flows via Slack, for instance?
Cameri 3 days ago
How is OneCLI different from Databrick's Omnigent?
eli_berman 3 days ago
Interesting, gonna take a closer look at this. But nice repo!
Axsuul 3 days ago
How does this compare to YC's qm?
guyb3 3 days ago
fair question and there are lots of overlap, here some diffs we found important for us - 1) the agent never holds your keys and all its traffic goes to onecli gateway. which adds the secret at the moment of the request. 2) our approval mechanism for risky actions like sending an email or deleting data need human approval. 3) each agent gets its own Slack app with a name, and its own avatar. QM uses one shared workspace bot for everyone, in onecli it will be three agents that look like three people in Slack, not one bot.