OneCLI

The deciding trait is one agent per person. Nobody shares a session, nobody inherits somebody else's context, and the thing acting on your behalf is yours, which removes the whole class of confusion that shared bot accounts create. Approvals arrive in the chat you are already reading, so the interruption lands where you can answer it.

It is young and it shows, mostly in documentation. Pick it if the problem you have is distribution rather than capability. Pick Kortix when you would rather not run the platform.

Concentration cuts both ways. Funnelling all egress through one policy-enforcing proxy is what makes the isolation meaningful, and it also means that component holds the keys to everything the organisation has connected. Nothing published describes its own hardening, its failure behaviour, or what happens to running agents when it is unavailable.

What it does right is refusing to trust the model with the decision: approval gates for destructive actions are described as deterministic rather than judged by a prompt, which is the distinction most products get wrong.

1. This is the architecturally right answer. A process that never possesses a secret cannot leak it, regardless of what text arrives in its context, which converts a prompt-injection problem into an access-control problem where the existing literature is forty years deep.

2. The sandbox gives each agent its own filesystem and shell, so the boundary is per person rather than per organisation. 3. No evaluation is offered, and none would be easy to construct, so the claim rests on the structure. Here the structure is the argument.

Pivots from infrastructure component to platform are common and rarely cheap. The original thing solved a narrow problem for a defined buyer; the new thing competes with every vendor selling agents to enterprises, most of which have a longer list of logos. 3,446 stars says the repositioning found an audience faster than a vault ever would.

No price is published, which means the commercial model is still being written. Likely acquirer: a secrets-management or identity vendor that wants the gateway. Position: watch it, pilot it, and do not route production credentials through a company still deciding what it sells.

Provisioning from the directory we already run means joiners and leavers are handled by the process that handles joiners and leavers, and that alone puts this ahead of most of the open projects I am shown. Self-hosting keeps the deployment inside our perimeter, and the licence costs nothing across sixty developers.

What it does not do is run without a person. There is no scheduled or pipeline execution, so this is a desk tool with good governance rather than automation I can measure. Support is a repository. Approved with conditions: internal systems only, and a named owner for the gateway.

The licence is right and the install is honest: clone, install, run a setup script, read whatever annoys me. What I do not get is the thing I usually insist on. Provider keys are held as global connections at the workspace level and granted to an agent, so my agent uses a key an administrator controls rather than one I export in a shell profile.

For a team product that is correct and I still resent it. No MCP client either, so my existing servers stay outside. The fork option survives, which is what keeps the score up.