OneCLI gives every employee a sandboxed agent that never sees

The security model caught my attention first: the agent holds only placeholder tokens, and a gateway injects actual secrets per-request after policy checks. Nothing hits the model context, memory, or logs. That's a fundamentally different threat surface than "here's your API key, good luck."

How the gateway enforces least privilege

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│   Agent     │────▶│   Gateway    │────▶│  External   │
│ (placeholder)   │  (policy +    │     │   Service   │
│  tokens)    │     │  injection)  │     │  (real key) │
└─────────────┘     └──────────────┘     └─────────────┘

The gateway sits at the network layer, not the prompt layer. Prompts are suggestions; policies are enforcement. Admins define:

• Allowed endpoints per agent
• Rate limits per identity
• Approval gates for destructive actions (send email, delete ticket)
• Scope boundaries per employee

What you get out of the box

1. Sandboxed agent per employee — connects GitHub, Gmail, Notion, Dropbox from chat
2. Deterministic human-in-the-loop — approval flows render in the chat thread itself
3. Centralized team policy — one config, enforced across every agent in the workspace
4. Shared credentials at org level — LLM keys, service accounts managed once, injected everywhere

Deployment model

Self-host on your infra (Docker Compose, Kubernetes, bare metal) or use their cloud. Apache-2.0 with a narrow enterprise exception — the entire platform is open, not a teaser slice.

# docker-compose.yml snippet
services:
  gateway:
    image: onecli/gateway:latest
    environment:
      - POLICY_CONFIG=/etc/onecli/policy.yaml
      - VAULT_BACKEND=hashicorp
    volumes:
      - ./policy.yaml:/etc/onecli/policy.yaml
  agent:
    image: onecli/agent:latest
    depends_on: [gateway]

The jcode engine

They're using jcode for the agent loop — same core that powers some of the faster autonomous agents (Hermes, OpenClaw). In practice this means tighter tool-calling cycles and less hallucinated parameter drift.

Why this matters for teams

Most orgs end up rebuilding the same harness: secret storage, approval UIs, audit logs, role scoping. OneCLI packages that scaffolding so you stop reinventing it. The vault-origin story shows — they built credential isolation first, then wrapped the agent around it.

Worth evaluating if you're past the "one developer with a script" stage and need something auditable.