D-303 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.

Admins publishEvery revision is checked before it is signed

Publish

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

boundlane policy publish acme.yaml

acme.yaml

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

Compile the document for every agent it names, with that agent's real program paths and key endpoints.
Prove each compiled policy with OpenShell's policy prover. Anything other than within_boundary refuses the publish and shows the reason or the counterexample.
Number the revision. Numbers only go up.
Sign the document and its number with the control plane's Ed25519 key.

The control plane keeps every revision: the document, the compiled policy and boundary for each agent, the prover's result, who published it, and when.

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.

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:

You changed	Kind	Running sandboxes	The console says
Hosts only	Door	Load the new rules while the agent works, on the machine's next sync.	"Applies to running agents."
Paths, workspace access, agents, or approvals	Wall	Keep the revision they started with. The next run creates a new sandbox.	"Takes effect on the next run. Running agents keep the old paths."
Only the name	None	Nothing changes.	"No change to what running agents can do."

On the machine, boundlane sync loads a door change and reports when the sandbox shows it as loaded. boundlane 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.

boundlane sync, example

decisions 0, requests 0, applied 0
note      bl-web-4f2a loaded r15. Applies to running agents.
note      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.