Team

Publish and revisions

A team policy is the same short file as a project policy, published once for everyone. Each published version is checked, numbered, and signed. Machines accept only a signed revision newer than the one they hold.

Publish

Edit the policy in the console and publish it, or publish a file from the terminal while signed in as an admin:

version: 1
name: acme
agents: [claude, codex]
workspace: read-write
hosts:
  - host: api.github.com
    access: read-only
  - host: registry.npmjs.org
    access: read-only
  - host: npm.acme.internal
    access: read-only
approvals: person

A team policy is complete on its own. It does not merge over developer-default; start from that file and add what your projects need. The fields are the same as in the policy file.

What publish checks

1. Compile the document for every agent it names, with that agent's real program paths and key endpoints.

2. Prove each compiled policy with OpenShell's policy prover. Anything other than within_boundary refuses the publish and shows the reason or the counterexample.

3. Number the revision. Numbers only go up.

4. Sign the document and its number with the team's own Ed25519 key. Each team has its own.

The control plane keeps every revision: the document, its signature, the prover's result for each agent, the kind of change, who published it, and when. The compiled policy is not stored; every machine compiles the signed document again and checks it before a sandbox starts.

How machines get it

An enrolled machine asks for the current revision whenever it runs a command that needs the policy. It checks the signature against the key it received at sign-in, and ignores a bundle that fails or that is older than the one it already has. Then, before each sandbox starts, the CLI compiles the document for that agent and runs the prover again on the machine. A machine never runs a policy only because the server said so.

Who holds the signing key

Each team has its own Ed25519 signing key. Our control plane generates it, keeps the secret half encrypted in its database, and signs each revision you publish with it. Machines check every revision against the public key they received at sign-in, refuse a bad signature or a lower number, and run the prover on the machine before a sandbox starts.

Someone who took over our control plane could sign a revision. The local prover check still holds it to the boundary carried in the same bundle.

What happens to running sandboxes

The console compares each new revision with the previous one and says which kind of change it is, before you publish. The CLI prints the same verdict on the machine:

On the machine, fenzi sync loads a door change and reports when the sandbox shows it as loaded. fenzi forward does the same on every pass. A wall change is never applied to a running sandbox, because filesystem and process rules are fixed when a sandbox is created. The CLI prints which sandboxes will pick it up on their next run.

■ Sync

✓ Decisions         0
✓ Requests          0
✓ Applied           0
  bl-web-4f2a loaded r15. Applies to running agents.
  bl-api-90cc: Takes effect on the next run. Running agents keep the old paths.

Going back to an earlier policy

Publish the earlier document again. It is checked and signed like any other, and gets the next number. Machines never accept a lower number, so an old signed bundle cannot be replayed to roll a team back.

Who can publish

Admins. Members sign in and run under the published policy. A developer's machine cannot change the team policy, and a project file does not widen it. If a sandbox runs something other than the published revision, the console shows it as drift.