Inject API credentials into AI agent requests without exposing secrets
Open-source platform giving every employee a sandboxed AI agent, routed through a credential-injecting gateway with one team-wide policy.
2.6.0Add to Favorites
Why it matters
Centralize and secure API credential management for AI agents by intercepting outbound HTTP requests, transparently swapping placeholder keys with encrypted real credentials, and providing a single audit point for all agent API access without ever exposing secrets to the agents themselves.
Outcomes
What it gets done
Store encrypted API credentials once and route them to multiple agents based on host and path patterns
Intercept agent HTTP requests through a gateway proxy and inject real credentials at request time
Manage per-agent access tokens and permissions through a web dashboard with audit logging
Integrate with password managers like Bitwarden for on-demand credential injection without server storage
Source
Get it from source
Spark does not host a copy of it.
Open sourceReports
Agent outcome reports
No reports yet
Overview
Onecli
OneCLI is an open-source platform for running a sandboxed AI agent per employee under one enforced team policy. A Rust gateway intercepts every outbound request and injects credentials the agent never directly holds, agents connect via a dashboard or their own Slack app, and high-risk actions require deterministic human-in-the-loop approval. Use it when a team wants to roll out AI agents to every employee, not just one power user, with identity-provider-based provisioning, centralized policy, and credential injection instead of handing out secrets; the core is Apache-2.0 and self-hostable, with a separate enterprise license for the ee/ directories in production.
What it does
OneCLI is an open-source platform for running AI agents as a team rather than one person at a time: you create a durable, sandboxed agent per employee, grant it only the access it needs, and every outbound request it makes is routed through a Rust gateway that injects the right credentials and enforces a single team-wide policy - so an agent never actually holds the secrets it uses.
When to use - and when NOT to
Use it when a team wants to give every employee their own autonomous coding/ops agent (in the spirit of single-user tools like Hermes, OpenClaw, or NanoClaw) without the mess of manually spinning up each one, deciding permissions ad hoc, and losing track of whose agent has access to what - OneCLI's own origin story is exactly this gap: it started as a Rust credential vault for individual agents, then had to add team provisioning (via the company identity provider) and centralized policy once demand shifted from individuals to teams. Deterministic human-in-the-loop approval is built into the chat itself for actions you want 100% control over - sending an email, deleting a ticket, emptying an S3 bucket - rather than trusting the agent to just do it. Agents run on your own infrastructure (a laptop, a homelab, or a VPC), and the runner is outbound-only with no inbound ports, so there's no ingress or tunnel to expose. The core platform is Apache-2.0 and self-hostable in production for free, but code under the ee/ directories is enterprise-licensed - free for development, testing, and evaluation, but requiring a subscription for production use.
Inputs and outputs
Input is a defined agent (identity, granted connections/credentials, skills, and an optional schedule) plus messages sent through its dashboard page or its own Slack app (with images and files); sending a new message while the agent is mid-task redirects it immediately instead of queuing. Output is the agent's work inside its sandbox - filesystem and shell actions reaching only what the gateway allows - plus persistent memory the platform keeps and lets you read or edit at any time, and pending approval requests for anything flagged to need a human sign-off.
Integrations
git clone https://github.com/onecli/onecli.git && cd onecli
pnpm install
pnpm run setup
Self-hosting opens a local dashboard at http://localhost:10254; a cloud-hosted version runs at onecli.sh. Credentials can be injected two ways: static grants stored in OneCLI's own AES-256-GCM-at-rest secret store (matched by host/path pattern, decrypted only at request time), or on-demand from a connected Bitwarden or 1Password vault with nothing stored on the OneCLI server. An SSH front door terminates connections with short-lived certificates and bridges into an agent's sandbox, and the sandbox supervisor speaks a vendor-neutral harness interface, so the underlying agent runtime is swappable.
Who it's for
Companies rolling out AI agents to their whole team rather than one power user, who need per-employee identity-based provisioning, one enforced policy across every agent, and a credential model where agents never directly hold the secrets they use. The core OneCLI project is released under the Apache 2.0 license, with the ee/ directories carrying a separate OneCLI Enterprise License.
Source README
The agent harness built for teams.
A pro assistant for companies. Give every employee a secured, sandboxed personal agent.
Quick Start
Cloud-hosted: onecli.sh
Self-hosted
git clone https://github.com/onecli/onecli.git && cd onecli
pnpm install
pnpm run setup
What is OneCLI v2?
OneCLI is an open-source platform for running AI agents as a team. You create an agent per person, give each agent the access it needs, and it works in a sandbox, routed through a gateway that injects the credentials and enforces your policy.
Why we built OneCLI?
OneCLI started as a credential vault for AI agents, built in Rust. We found that most of the demand came from individuals and teams running autonomous agents like Hermes, OpenClaw and NanoClaw. People wanted agents that do real work for the person running them, but two parts were missing:
- managing secrets and permissions.
- and for teams - multiplayer management.
Every autonomous agent out there is built for one person. And for one person, they're great. The moment you need to replicate that across a team, it gets messy: spinning up each agent, deciding what each one can and cannot do, hosting them, keeping track of whose agent is whose.
So we shifted, and built OneCLI v2.
Built for teams
- Your identity provider, integrated: provision agents on behalf of each employee's identity, straight from the company IdP.
- An agent per person: everyone in the workspace gets their own sandboxed agent, reachable from the dashboard or Slack.
- One policy, enforced everywhere: manage the team policy in one place, that any agent in the workspaces would be enforced by.
- Deterministic human-in-the-loop approvals: in the chat itself, for things you need 100% control over, like sending the email, deleting the Linear ticket, emptying an S3 bucket.
- Global connections: shared at the team level, like LLM keys or service accounts, granted per agent without ever being handed to one.
The agent
An agent is a durable thing, not a single prompt. It has:
- A computer: its own isolated sandbox, with a filesystem and a shell. The only way out is the gateway, so it can reach what you granted and nothing else.
- A conversation: its own page in the dashboard, or Slack. Images and files included. A message sent while the agent is working redirects it right away instead of queueing behind it.
- Memory: what the agent learns is kept by the platform, so it is never lost. You can read and edit it any time.
- Skills: instructions and helpers you write once, always available to the agent.
- A schedule: the agent can plan future work, and the platform wakes it at the right time.
- Credentials it never sees: each agent gets only the access you granted, and the gateway enforces it on every request. Or connect Bitwarden or 1Password for on-demand injection, with nothing stored on the server.
- Its own Slack app: connect it once and it answers in channels and DMs under its own name and avatar, with files and images. Delete the agent and its Slack app goes with it.
Agents run on your own infrastructure. The runner is outbound-only and holds no inbound ports, so a laptop, a homelab, or a VPC behind NAT all work with no ingress and no tunnel.
Architecture
- Web Dashboard: Next.js app. Create agents, chat with them, edit their memory and skills, manage connections, secrets and grants.
- API Server: the control plane. Owns the database, the conversation plane, and the work queue the runner polls.
- Rust Gateway: intercepts outbound requests (HTTPS included, via MITM) and injects credentials. Agents authenticate with access tokens via
Proxy-Authorizationheaders. - Runner: starts, parks and reaps agent sandboxes. Outbound-only, and never touches the database.
- Sandbox Supervisor: runs inside each sandbox, speaking a vendor-neutral harness interface so the agent runtime is swappable.
- SSH Terminator: the SSH front door - terminates
sshconnections with short-lived certificates and bridges them into agent sandboxes through a pluggable substrate backend. - Channel Adapter: the Slack daemon, one app per agent.
- Secret Store: AES-256-GCM at rest, decrypted only at request time, matched by host and path pattern, injected as headers or query parameters.
Local Development
git clone https://github.com/onecli/onecli.git && cd onecli
mise install
pnpm install
pnpm dev
That's the whole setup: pnpm dev generates .env with every required secret, starts PostgreSQL, applies migrations, and runs the full stack. Prerequisites, the command reference, project structure, and configuration live in docs/development.md.
Security
To report a vulnerability, please follow our Security Policy. Do not open a public issue for security reports.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.