coulomb/zone-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Activate ZONE-WP-0001 and decide exception lifecycle

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0291a-1e87-7151-9934-fcbfe3f65eb1
This commit is contained in:
tegwick 2026-08-22 13:01:14 +02:00
parent 6f6c893011
commit 11af8095ae
4 changed files with 174 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

121
docs/exception-lifecycle-2026-08-22.md Normal file
View file

@ -0,0 +1,121 @@
# Time-boxed security-zone exceptions — ZONE-WP-0001-T04
**Decision date:** 2026-08-22
**Decision:** the exception lifecycle does not require a zone-engine runtime.
An exception is a temporary relaxation of one control for workloads already
admitted to a named security zone. It does not change membership, lower an
admission floor, or create a temporary-sounding zone. Membership remains a
declared workload fact. The control owner remains the authority for the effect.
## 1. Grant authority
The workload's responsible party may request an exception. Only the authority
designated by the **control owner** may grant it, because that owner owns the
base stance and the enforcement point that must apply the relaxation. For a
failure-mode relaxation, the grant authority is the owner of the policy
enforcement point (PEP), never the PDP.
One person may currently perform both roles in this founder-operated estate,
but the record still names `requested_by` and `granted_by` separately. A
declarer cannot grant itself an exemption merely by changing its zone
membership.
Each control declares a `maximum_exception_duration`. If it declares no
maximum, it permits no exceptions. A grant beyond the declared maximum is
invalid rather than silently shortened.
## 2. Minimum record
This is a conceptual record for the canon draft, not an API or storage schema.
Every implementation must preserve these facts in machine-readable form:
| Fact | Rule |
| --- | --- |
| `exception_id` | Stable and unique; renewed grants get new ids |
| `security_zone` | The admitted zone whose normal rule is being relaxed |
| `control` | Stable owner-qualified control id |
| `workloads` | Authoritative workload ids; an empty or unresolved subject is invalid |
| `base` | The stance and, where relevant, PEP failure mode that auto-restores |
| `relaxation` | Explicit `advisory` or `exempt` stance and/or PEP-side failure mode |
| `justification` | The bounded work that requires the relaxation |
| `requested_by` / `granted_by` | Auditable responsible parties |
| `issued_at` / `not_before` / `not_after` | UTC instants; `not_after` is exclusive |
| `maximum_duration_policy` | Versioned rule against which duration was checked |
| `change_ref` | Reviewed source change that introduced the grant |
A grant may only relax a named control. Promotion to a stricter stance is an
ordinary policy change, not an exception. Wildcard workload scope is forbidden:
the work that needs relief must be named, and unknown membership never inherits
a permissive zone or exception.
## 3. Enforced expiry
At every decision or enforcement attempt, an exception applies only when all of
the following are true:
1. its record is valid and was granted by the control's designated authority;
2. the current authoritative workload and zone match its scope;
3. `not_before <= now < not_after`; and
4. its duration does not exceed the referenced maximum.
Missing, malformed, unresolved, or unevaluable facts make the exception
**inactive**. The enforcement point applies the base stance and failure mode.
Clock failure must never preserve the relaxation.
Expiry is an automatic return to the base rule. It does not block waiting for a
renewal, and it does not require a commit, image rebuild, rollout, scheduler, or
human reminder. Renewal is a new reviewed grant with a new id; the expired
record remains in history.
No authority created under an exception may outlive it. A certificate, token,
lease, session, or other durable result must have an expiry no later than the
exception's `not_after`, or the enforcement point must re-evaluate the exception
before each use. Otherwise the timestamp would expire while its effect remained
live.
## 4. Placement by control
| Control kind | Grant representation | Expiry evaluator | Required evidence |
| --- | --- | --- | --- |
| flex-auth decision | Versioned flex-auth policy package | Rego decision time (`time.now_ns()`) | Decision envelope includes policy package/version and active exception id/expiry |
| ops-warden CLI decision | Versioned ops-warden control data | CLI at each invocation | Verdict `reasons` includes active exception id/expiry |
| PEP failure mode | Versioned consumer configuration | PEP when the PDP/control is unreachable | PEP audit record includes exception id/expiry and fallback taken |
This placement preserves the authority boundary: zone-engine standardizes the
lifecycle, while each control owner represents and evaluates the effect where
that control already runs. In particular, fail-open cannot be implemented by
flex-auth because no PDP decision exists when flex-auth is unreachable.
The current flex-auth deployment loads registry and policy once at process
start. Granting therefore costs rebuild and rollout, but a timestamp evaluated
at decision time still lapses without either. An inert registry flag would not;
it is prohibited for exceptions.
## 5. Visibility
Someone who did not grant an exception must be able to discover it in two
places:
- the reviewed, versioned source record owned with the control, including
expired records in history; and
- the machine-readable decision or verdict whenever the exception changes an
outcome, including `exception_id` and `not_after`.
Control builds must also produce a machine-readable inventory of active and
future grants and reject overlaps that would make the selected relaxation
ambiguous. Near-expiry reporting is useful operationally but is not the expiry
mechanism.
## 6. Runtime decision
A central zone-engine service would not enforce expiry more reliably. It could
not alter flex-auth's digest-pinned, load-once artifacts at the deadline, and a
synchronous lookup would add a new availability dependency while crossing the
PDP authority boundary. The enforcement points already have the clocks and the
decision context needed to make a compiled `not_after` self-expiring.
Therefore T04 selects reviewed declarations plus enforcement-time timestamp
evaluation. `zone-engine` needs a canon contract and conformance fixtures, not a
runtime. This decision can be reopened only if a real adopting control cannot
evaluate time at the point where the relaxation takes effect.