Fenzi

Reference

Glossary

The words these docs use, in one place. Where a word comes from the sandbox runtime, it means what the runtime means by it.

Alphabetical

Terms

Admin
The Team role that can do everything: manage members and their roles, publish policy, set the boundary, review requests, and sign out any machine. A team always keeps one. See Roles.
Agent
A command-line program that uses a model to read and change code, such as Claude Code or Codex. Fenzi starts it inside a sandbox. See Agents.
Approval
A person's decision to open a door the policy did not list. It applies to the running sandbox and lasts as long as that sandbox. See Requests and approvals.
Auditor
The Team role that reads the console and exports decisions, and nothing else. An auditor cannot sign in a machine. See Roles.
Boundary
The outer limit a policy is checked against. On Free it is compiled from the same file plus the agent's key endpoints, so the check proves consistency, not safety. On Team an admin can save one for the team, written like a policy file. Every policy is then proved against it, and each signed revision carries it. See Team boundary.
Bundle
A team policy document and its revision number, signed by the control plane. When the team has a boundary, the bundle carries it under the same signature. Machines accept only a bundle with a valid signature and a higher number than the one they hold.
Catalog
The list of agents Fenzi knows how to start: each one's command, image, pinned version, program paths, key, and hosts.
Console
The Team web app. Publish policies, see machines, read decisions, review requests.
Control plane
The service behind the console. It stores policy revisions and decision records. It never connects to a developer's machine and never holds model keys.
Decision
One allow or deny the sandbox recorded for a network call: time, program, destination, rule, and for a deny, the reason. See Decision log.
Developer
The default Team role. A developer signs in their own machines with fenzi login and reads the console, but does not review, publish, or manage members. See Roles.
Door
A network rule. Doors can change while the agent runs: an approval or a host change loads into the running sandbox.
Drift
A machine whose sandboxes do not match the published policy, or an approval that did not come from the console. See Drift.
Forwarder
fenzi forward. It runs on the developer's machine and sends decisions and requests to the console. See Forwarding decisions.
Free
The plan for one machine, with no account. The policy, the log, and approvals stay on that machine, in the terminal or the Mac app. Each developer at a company can run it on their own laptop. See Getting started.
Gap
A record that says part of a sandbox's decision stream was lost, with the time span. Shown in the console instead of being hidden.
Gateway
The runtime's control process on a machine or a cluster. It holds sandboxes, their policies, and the stored keys.
License
The plan for running the control plane in your VPC and gateways on your cluster, where developers do not administer them, with single sign-on and SIEM export. It is planned and not built yet. See License plan.
OCSF
Open Cybersecurity Schema Framework. The open format the runtime writes decisions in, which is why they line up with a SIEM.
OpenShell
The open source sandbox runtime Fenzi drives, licensed under Apache 2.0. It provides the gateway, the supervisor, the policy proxy, and the prover. Fenzi pins its version. See The pieces.
Placeholder
What the agent sees where its model key would be. The runtime replaces it with the real key on the way out, only on requests to that key's endpoints.
Policy
The short file that says what the agent may touch: fenzi.yaml on a project, or the team policy on Team. Fenzi compiles it into the runtime's own policy format. See Policy file.
Profile
The endpoints an agent's key may be sent to, and the programs allowed to send it. Fenzi ships a reviewed copy per agent.
Prover
The runtime's policy checker. It compares a compiled policy with a boundary and returns within_boundary, or the action that goes past it. Nothing starts without a pass.
Request
An ask for more network access, drafted by the sandbox from a refused call or filed by the agent with a reason. It waits for a person.
Revision
A numbered, published version of a team policy. Numbers only go up. See Publish and revisions.
Reviewer
The Team role that approves or denies agent requests, reads everything, and exports decisions. A reviewer does not publish policy or manage members. See Roles.
Role
What a member may do on a team: admin, reviewer, developer, or auditor. An admin sets it on Members. See Roles.
Runtime
Short for the sandbox runtime, OpenShell, on a machine: the gateway and the sandboxes it holds. Not the container runtime, such as Docker or colima, that the sandboxes run in.
Sandbox
The isolated environment the agent runs in, created fresh for each run. It holds a copy of the project, not your machine.
Staging
The folder on your machine where the agent's changes wait after the sandbox ends, until you run fenzi apply. See Workspace and changes.
Supervisor
The runtime's enforcement process inside each sandbox. It applies the filesystem and process rules at start, and runs the proxy every network call goes through.
Team
The plan for many machines: one signed policy, one decision log, and approvals in the console at fenzi.dev. Opened on request. See Team plan.
Wall
A filesystem or process rule. Walls are fixed when a sandbox is created. Changing one means a new sandbox, and Fenzi says so.
within_boundary
The prover's pass: nothing the compiled policy allows is outside the boundary. On Free the boundary comes from the same file, so a pass means the sandbox gets what the file says, not that the file is safe. Any other result stops the run. See The check before start.