Team
Drift
A developer owns their laptop and the sandbox runtime on it. Team cannot stop them from changing it. It can notice, and say so. Drift is a machine whose sandboxes do not match what the team published.
What counts as drift
The console's Drift page lists what the machines sent that does not match the console. Alerts first. The page is where you see it: drift sends no email or webhook yet.
| Level | Finding | How it is noticed |
|---|---|---|
| Alert | A running sandbox has no team revision | The machine's report lists the sandboxes it started and the revision each one got. One started outside the team policy has none. |
| Alert | The gateway approves requests automatically | The machine reports the gateway-wide approval mode. fenzi doctor --fix removes it. |
| Alert | An approval with no console review | The sandbox logs an approval with the request's id. It is matched to the reviews made in the console. |
| Alert | A request answered on the machine | On each pass the forwarder sends every request still pending on each sandbox. A request the console listed that left that list with no console review was answered on the machine. The alert says approved when a connection was allowed under the request's rule or the sandbox logged the approval; otherwise approved or denied is not known. |
| Alert | A running sandbox holds a policy other than its revision | On each pass the forwarder reads the policy the runtime holds for every running sandbox on a team revision and compares it, section by section, with the policy compiled from that revision for its agent. The rules the runtime adds for the agent's model API are left out. The alert names the machine, the sandbox, the revision, and the sections that differ, not their contents. |
| Alert | A machine refused the policy it was sent | The revision failed the signature check, or was older than the one the machine holds. The machine keeps its revision and says why in its report. |
| Warning | A machine stopped reporting | No report for more than a day. Its decisions and requests are not reaching the console. A laptop closed over a weekend shows this too. |
| Warning | A machine holds an older revision | Its report names the revision it holds. It catches up on its next sync or run. |
| Warning | The runtime is outside the pinned release line | The machine reports the runtime version. fenzi doctor fails on it too. |
| Warning | Decisions were lost | The forwarder sent a gap record. |
| Info | A sandbox runs an older revision after a path change | By design: it keeps the paths it started with, and its next run creates a new sandbox. |
| Info | A sandbox's policy was not compared | The forwarder loaded a new revision onto it and the runtime has not yet reported it loaded. It is compared on the first pass after the runtime does. |
What to do about it
- A request approved or answered on the machine. Read what was approved in the decision log; the Requests page lists the request under Reviewed, with no reviewer. If it was right, add the host to the team policy so the next one goes through the console. If not, talk to the developer.
- A policy that differs from its revision. A request approved for the sandbox adds a network rule, so a difference in
network_policiescan be an approval: check the sandbox's approvals first. Otherwise ask the developer to stop the sandbox and start the agent again withfenzi run, which creates it from the published revision. - A sandbox without a team revision. Ask the developer to stop it and start the agent again with
fenzi run, which starts it from the published revision. - Automatic approval. Ask the developer to run
fenzi doctor --fix.
What drift cannot do
Drift is a record, not a lock. A developer who stops the forwarder, signs out, or runs an agent outside Fenzi is not stopped by it. A sandbox Fenzi did not start sends no records at all. The console shows a machine that stopped checking in, not what it did afterwards.
An answer made on the machine is seen in two ways: the sandbox logs the approval, or a request the console listed leaves the machine's pending list. OpenShell 0.1.2 logs an approval in the sandbox for a request the agent filed itself, not for a draft the sandbox made from a refused connection, and logs nothing there for a denial. A request filed and answered between two forwarder passes never reaches the console's list, so it is seen only when the sandbox logs it.
The policy compare runs only while the forwarder runs, and only for sandboxes Fenzi started from a team revision. After the forwarder loads a new revision, OpenShell reports it Pending until the sandbox picks it up, and a sandbox is not compared until the runtime reports the load as Loaded.
If you need enforcement the machine's owner cannot change, run the gateway where developers do not administer it. That is the License plan, which is planned and not built yet.