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.
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 loginand 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.yamlon 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.