Launch HN: OneCLI (YC S26) – OSS sandboxed agent harness for teams (github.com)
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 ...
37 comments
[ 0.28 ms ] story [ 25.5 ms ] threadjust 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.
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
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".
Method + path + body matching is necessary but blind to provenance. GET /customers?limit=5000 looks identical whether the operator asked for it or a retrieved document did. The gateway sees a well-formed request that a policy permits what makes it an exfiltration is what entered the context window three steps earlier, and the egress boundary structurally cannot see that.
The approach we landed on binds the decision to the trajectory rather than the request: which retrieved content or tool result preceded this call, and whether any argument value originated in untrusted text. "This field traces back to a retrieved document" turns out to be a much stronger signal than any endpoint allowlist.
On testing them static policy unit tests pass trivially. What actually finds things is adversarial replay: take real traces, inject at the retrieval and tool-result boundaries, re-run, check the policy still holds. Multi-turn matters most, since single-turn injection suites miss the case where every individual step is permitted and only the sequence is the attack.
Response volume is the most under-implemented control on your list, and probably the cheapest one to add.
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.
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.
What seems to actually help is spotlighting the specific span the model claims motivated the action (Willison's dual-LLM idea, basically) and diffing it against what the user's own instruction scoped -- did the model only extract the field the user asked for, or did it also pick up embedded directives that weren't part of the user's ask. That's a much harder signal to compute than "did this field come from untrusted text," but plain provenance tagging alone will either false-positive on the legitimate case or miss the injected one.
Also +1 on multi-turn being the real gap. Most public injection test sets, including ones I've built, are still overwhelmingly single-turn, and the sequence-is-the-attack case is exactly where a policy engine that only inspects individual requests falls down.
Whatever you use to decide "this request looks injected" gets tuned against the cases you have seen. Then it is tested against those cases and it passes, which tells you nothing you did not already know. The number that matters is how it does against attacks written by someone who never saw your rules.
I have been measuring exactly that on the detection side, deliberately: write a new attack corpus from scratch, score it once, then retire it so it can never be tuned against. Seven independent sets, same engine. It read 48%, 54% and 53% on sets sampled broadly, then 13%, 6.5%, 6.7% and 6.7% on sets written so that no single message contains anything recognisable. That spread is not noise. It tracks one thing: how far each set sits from whatever the rules were last adjusted for. Closing an attack family generalises to that family and does not travel past it.
The consequence for a gateway like yours is fairly encouraging, actually. The deterministic half of what you described - method plus path plus body matching, human approval bound to the exact proposed call - is the half that holds, precisely because it never has to recognise intent. Anything that tries to classify whether a request was influenced by untrusted content will look much better in your own suite than in the wild, and it will look best of all right after you have fixed the case that prompted the test.
Precision is the easy half, for what it is worth: mine sat under 1% false positives across all seven sets and never moved. Recall on inputs nobody tuned for is the number worth publishing, and almost nobody publishes it.
Asking because that decision changes your failure mode a lot. If egress is forced through the gateway, a slow or down gateway just breaks connectivity and the agent fails closed by construction, which is a nice property. If the agent calls back explicitly, you're relying on the agent to actually make that call correctly every time, and now you need to check that no tool has a code path that reaches the real network directly and bypasses the swap.
Approve “send this exact email” and an auditor’s next question is why the agent wanted to send it at all. If the memory that produced the intent overwrote its own history, that answer is gone by the time anyone asks. I build in this space (OMEM, open source belief-revision memory for agents: https://github.com/troybrandonc-bit/Omem), and the pattern that survived contact with security reviews was: only action types registered in code can execute, the risk class comes from the registry rather than from the plan that claims it, a high-risk action waits for a named approver, and both the approval and any refusal are recorded next to what the agent believed when it proposed the action, with the evidence chain.
The gateway holding the call solves who can act. Recording why it wanted to act is the part clients ask about after the first incident. Nice launch, the exact-request binding puts you ahead of most of the field already.