Team
Offline mode
What zn-gate does without network, with an expired or rejected policy, and after an install is revoked. It never runs without a policy.
zn-gate applies the organization policy locally, so coding keeps working on a plane or behind a broken proxy. The rule is simple: a machine never runs without a policy, and when in doubt it gets stricter, not looser.
| Situation | What zn-gate does |
|---|---|
| No network, cached policy still valid (up to 7 days) | Applies the cached policy. The audit trail stays in ~/.zn/audit.jsonl and is uploaded when the network is back |
| No network and the cached policy has expired | Strict mode: the deny rules of the last policy still apply, permissions the organization had opened are withdrawn (the stricter local settings come back), and zn team status and the agent hook say so |
| Invalid signature, unknown key or a lower version | Rejects it, keeps the last valid policy and logs policy:rejected |
| Install revoked | Stops uploading. Applies the cached policy until it expires, then strict mode. The notice says "removed from org" |
| Clock skew | Up to ±5 minutes of tolerance on the policy's issue and expiry times |
| Gap or replay in the upload | zn resumes from the last record it confirmed. A tampered record is rejected and shows in the dashboard |
Checking a machine
zn team statusshows the policy version, when it was last checked, whether strict mode is on and how many audit records are waiting to be uploaded. zn team sync retries now.
In the dashboard, Members → Installs lists each machine with the last time it was seen, so owners and admins can spot installs that are out of date or silent.
The audit trail is tamper-evident
Each machine chains its audit records with an HMAC (seq, prev, mac). zn uploads them in order and checks the chain, so a missing, reordered or edited record is visible, in the dashboard and in every export.