One policy.Every laptop.
Publish the rules once, set up a new laptop with one sign-in, and let one approval answer the whole team. The agents still run on your machines.
curl -fsSL https://fenzi.dev/install.sh | sh
Linux, Apple Silicon, WSL 2. Free at work too.
See how it worksMissions6
Engineering answers to problems you have already had.
Each card opens the mission that answers it.
Day one starts from zero.
Each developer wires up servers, hosts and rules by hand, and no two laptops match.
Set it all up again.
A new agent means new MCP servers, new keys and new rules, typed in from memory.
Every tool, wide open.
The server's token sits in a config file the agent can read, and every tool it offers is allowed.
Publish once. Every laptop takes it.
An admin publishes one policy for the team: hosts, paths, MCP servers, and the agents it covers. Each revision is checked by the prover, numbered and signed, and a machine ignores a bundle that fails the signature or is older than the one it holds.
fenzi policy publish team.yamlfenzi sync| You changed | Running sandboxes |
|---|---|
| Hosts | Load the new hosts on the machine's next sync or forwarder pass. |
| Paths, workspace access, agents | Keep the old revision. The next fenzi run creates a new sandbox. |
Walls before move-in. Doors while it runs.
A new teammate is set up after one sign-in.
fenzi login signs the machine in, and the next fenzi run uses the team's policy, MCP servers included, with any agent the policy covers. Nobody copies a config by hand, and every laptop starts from the same revision.
Each developer stores their own model key on their own machine. It never reaches our cloud.
One developer asks. The whole team stops asking.
A request travels out from the machine to the console; nothing in our cloud connects in. The reviewer sees the machine, the host, the program and the agent's reason, never the code or the conversation.
Approve and add to policy opens the host for that sandbox within seconds and drafts the next revision with it, so once an admin publishes it, every laptop has the host.
| Approve | Approve and add to policy | |
|---|---|---|
| Who can | An admin or a reviewer | An admin |
| The sandbox that asked | Gets the host at its next forwarder pass | The same |
| Every other laptop | No change | Gets the host once the draft is published |
Connect every MCP server you use. Allow only the tools you mean.
List each server once in fenzi.yaml, with the tools the agent may call. Fenzi writes it into each agent's own config format, and the sandbox checks every remote call against that list.
A server's token is stored with fenzi mcp token, outside the sandbox. The agent holds a placeholder, and the real token goes only to that server. fenzi mcp import starts you from the .mcp.json you already have.
fenzi mcp importfenzi mcp addfenzi mcp tokenYour claude.ai connectors, one tool at a time.
The connectors you added on claude.ai come with your Claude sign-in and share one Anthropic host. Without an entry the sandbox refuses that host. With one, it checks every call against the tool names you list.
fenzi mcp add claude-ai --claude-account --tool list_issues --tool get_issueYour MCP servers, keys and rules outlive the agent you picked.
Servers you use everywhere go in one file on the machine. Keys and tokens are stored once, outside every sandbox. The project's rules live in fenzi.yaml, committed, so everyone on the project runs with them.
Switch from one agent to another and all of it comes along. Nothing is configured twice.
Claude's account connectors go to Claude Code only. A local server's secret reaches Claude Code and Codex today; OpenCode and Grok refuse it until it is tested.
| What | Set with | Lives in |
|---|---|---|
| MCP servers for every project | fenzi mcp add --machine | ~/.config/fenzi/mcp.yaml |
| MCP tokens and secrets | fenzi mcp token | The sandbox runtime on this machine |
| Model keys | fenzi key set | The sandbox runtime on this machine |
| The project's rules | fenzi init | fenzi.yaml, committed |
Four roles. Only admins change the rules.
Every member has exactly one role. Developers run agents, reviewers also answer requests, admins also publish and manage members, and auditors read and export without ever enrolling a machine.
An admin or reviewer can approve a request their own agent filed, and the console records who approved it. Members sign in with email and password, plus MFA with an authenticator app, which an admin can require. SSO is not on Team.
| Right | Admin | Reviewer | Developer | Auditor |
|---|---|---|---|---|
| Read the console, export decisions | yes | yes | yes | yes |
| Sign in their own machine | yes | yes | yes | no |
| Answer a request | yes | yes | no | no |
| Publish, set the boundary | yes | no | no | no |
| Invite members, change roles | yes | no | no | no |
The same sandbox, seen from another seat.
Know what every agent did, on every laptop.
All use cases and every feature with its docs page.
You pay for the fleet, not for sandbox hours.
$0 Per machine. No account.
Fine at work, on each developer's own laptop.
$20 Per developer a month, billed yearly.
$25 billed monthly, two developers at least. One policy, one log and one approval queue across every laptop. Machines and sandbox hours are not counted.
Price has every plan side by side.
One line to install. One command to run.
curl -fsSL https://fenzi.dev/install.sh | sh
Free per machine. No account. The model does not get a vote on its own limits.