Seed zone-engine — authority for security zones and exception lifecycle
Enforcement controls in this estate have been repo-wide booleans. ops-warden's flex-auth pre-sign gate was the first to become flippable, and flipping it would have made flex-auth a hard dependency of every warden sign — including the SSH certs the ops-bridge tunnels depend on, one of which carries the policy call. Uniform enforcement across an estate under deep refactor hardens exactly the access needed to perform the refactor. Deferred under ops-warden ADR-0006; this repo is what that ADR defers to. Seeded deliberately without a schema. ZONE-WP-0001 produces a model and a canon draft, not an API: an engine that ships a wire format before it has partitioned the real estate defines the model by accident. Whether a runtime is warranted is an output of the exception-lifecycle task, not an assumption. Invariants set now, because they are the ones easy to lose later: flex-auth stays the only PDP and receives membership by compilation, not a synchronous lookup in a latency-critical decision path; placement (reefs) is not posture; accuracy not altitude, per tenancy-posture v0.1 §6. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
98d9fd1ea9
commit
38c450f4ab
6 changed files with 359 additions and 1 deletions
183
workplans/ZONE-WP-0001-security-zone-model.md
Normal file
183
workplans/ZONE-WP-0001-security-zone-model.md
Normal file
|
|
@ -0,0 +1,183 @@
|
|||
---
|
||||
id: ZONE-WP-0001
|
||||
type: workplan
|
||||
title: "The security zone model — derive it from the estate, draft it as canon"
|
||||
domain: infotech
|
||||
repo: zone-engine
|
||||
status: proposed
|
||||
owner: zone-engine
|
||||
topic_slug: netkingdom
|
||||
planning_priority: P1
|
||||
created: "2026-08-19"
|
||||
updated: "2026-08-19"
|
||||
---
|
||||
|
||||
# ZONE-WP-0001 — The security zone model
|
||||
|
||||
Ported from `WARDEN-WP-0032` (ops-warden), which deferred `policy.enabled: true`
|
||||
under `ADR-0006` and named this repo as its successor. ops-warden keeps only its
|
||||
consumer-side task.
|
||||
|
||||
**This workplan produces a model and a canon draft. It does not produce an API,
|
||||
a schema, or storage.** An engine that ships a schema before it has partitioned
|
||||
the real estate defines the model by accident, through whatever its first wire
|
||||
format happened to be. Whether a runtime is warranted is an *output* of T02–T03,
|
||||
not an assumption of T01.
|
||||
|
||||
## The gap in one table
|
||||
|
||||
| Axis | Shipped | Answers |
|
||||
| --- | --- | --- |
|
||||
| Environment posture (`dev`/`test`/`prod`) | ops-warden WP-0015 | Where does this run? |
|
||||
| Workload maturity (`M0`–`M3`) | ops-warden WP-0015 | How ready is this workload? |
|
||||
| `organization_posture: build` | ops-warden WP-0029 | What state is the org in? |
|
||||
| **Enforcement stance** | **missing** | **Is this control enforced here, and what happens when it fails?** |
|
||||
|
||||
The first three describe. Nothing decides. That is why `policy.enabled` is a
|
||||
repo-wide boolean, and why turning it on would have hardened the access needed
|
||||
to perform the refactors currently underway.
|
||||
|
||||
## Do not reinvent these
|
||||
|
||||
**`net-kingdom/canon/standards/tenancy-posture_v0.1.md`** — the structural model
|
||||
to follow: orthogonal axes, graduated levels, a per-repo declaration
|
||||
(`tenancy.yaml`) with current/implemented/target vectors, evidence, and a review
|
||||
date; §6 *conformance is accuracy, not altitude*; §14 adoption stance
|
||||
*structure, not tooling*. That last one is why this workplan is shaped as it is.
|
||||
|
||||
**Reefs** (`repo-manager/docs/RailianceAppDeploymentGuide.md`) — `reef-railiance`
|
||||
carries a single-node/shared-control-plane residual risk requiring explicit
|
||||
acceptance. Substrate placement with risk attached is *adjacent* to a zone and
|
||||
must be reconciled with it, not duplicated. repo-manager's own rule — *topology
|
||||
is not readiness* — restates here as **placement is not posture**.
|
||||
|
||||
**flex-auth** — the PDP, `service_class: latency-critical`, already consuming a
|
||||
compiled registry snapshot built by
|
||||
`ops-warden/scripts/build_flex_auth_registry.py`. Zone membership reaches the
|
||||
decision point by **compilation**. A synchronous zone lookup in the decision
|
||||
path would be a regression dressed as an architecture.
|
||||
|
||||
**`warden plan`** (ops-warden WP-0029) — already returns
|
||||
`autonomous`/`founder_required`/`unroutable` from properties of the thing, with
|
||||
the `reasons` that produced the verdict. Zone-aware enforcement extends that
|
||||
machinery; it does not grow a second vocabulary beside it.
|
||||
|
||||
## Tasks
|
||||
|
||||
```task
|
||||
id: ZONE-WP-0001-T01
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
**Confirm ownership on the record, and say what publishes where.** This repo was
|
||||
seeded on a recommendation, not yet on agreement. Take to `net-kingdom` (canon)
|
||||
and `flex-auth` (the enforcing PDP): zone-engine owns the model and the
|
||||
exception lifecycle; canon publishes the standard, in the family of
|
||||
`tenancy-posture_v0.1` and the `*-engine` boundary contracts; flex-auth stays
|
||||
the only PDP and consumes compiled membership.
|
||||
|
||||
If either disagrees, the model moves and this repo is archived rather than kept
|
||||
for its own sake. Record the outcome either way.
|
||||
|
||||
```task
|
||||
id: ZONE-WP-0001-T02
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
**Derive the zones from the real estate.** Walk ops-warden's 27 catalog lanes,
|
||||
the `adm`/`agt`/`atm` actor inventory, and the workloads carrying posture
|
||||
descriptors. The model's test is that it partitions what exists without a
|
||||
residue of unexplained exceptions — and the exceptions found are the most
|
||||
informative output, not noise to tidy away.
|
||||
|
||||
Answer explicitly:
|
||||
|
||||
- Is a zone a property of the **actor**, the **lane**, the **workload**, or the
|
||||
**moment**? The CoulombCore decommission and the issue-core move show the last
|
||||
is real and hardest to model. A time-boxed relaxation is a *different object*
|
||||
from a standing zone; conflating them yields a permanent hole with a
|
||||
temporary-sounding name.
|
||||
- Do zones **compose with or fold in** the three existing axes? A fourth
|
||||
independent axis multiplies states; absorbing `organization_posture` may be
|
||||
the honest move.
|
||||
- How do zones relate to **reefs**? State it in the model rather than leaving
|
||||
readers to guess.
|
||||
|
||||
```task
|
||||
id: ZONE-WP-0001-T03
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
**Model stance and failure mode, per control per zone.** Enforced / advisory /
|
||||
exempt, *and* fail-closed or fail-open. The failure mode is where the bite is:
|
||||
`fail_closed` is what turns a dead tunnel into an outage, and is precisely why
|
||||
the ops-warden flip was deferred.
|
||||
|
||||
Controls in scope at minimum: the flex-auth pre-sign gate (`policy.enabled`,
|
||||
`fail_closed`), the agent read-boundary on `risk: high` lanes (ops-warden
|
||||
`ADR-0004`), and the `warden plan` escalation verdicts.
|
||||
|
||||
```task
|
||||
id: ZONE-WP-0001-T04
|
||||
status: todo
|
||||
priority: high
|
||||
```
|
||||
|
||||
**Design the time-boxed exception — this is the load-bearing task.** A standing
|
||||
classification needs no engine; canon plus a declaration file covers it. An
|
||||
exception with an expiry is *state*, and state wants an owner. Whether this repo
|
||||
earns a runtime is decided here.
|
||||
|
||||
Must specify: who may grant, against which zone and control, for how long, with
|
||||
what recorded justification; how expiry is **enforced rather than intended**;
|
||||
how an active exception is visible to someone who did not grant it; and what
|
||||
happens at expiry — auto-revert, or block until renewed.
|
||||
|
||||
If T04 concludes the lifecycle can live as reviewed declarations in git, say so
|
||||
plainly and drop the runtime. That is a valid and cheaper outcome.
|
||||
|
||||
```task
|
||||
id: ZONE-WP-0001-T05
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
**Declaration format and conformance rule.** Follow `tenancy.yaml`: per-repo,
|
||||
with evidence, `reviewed`, and `review_due`; carry over *accuracy, not
|
||||
altitude*. Include how a zone assignment changes and how that change is
|
||||
observed — a zone that can be quietly widened is not a boundary.
|
||||
|
||||
```task
|
||||
id: ZONE-WP-0001-T06
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
**Draft the canon standard and offer it.** `security-zones_v0.1.md` for
|
||||
`net-kingdom/canon/standards/`, drafted here, published there. Owner-driven
|
||||
landing, as ops-warden's WP-0015 maturity model was.
|
||||
|
||||
```task
|
||||
id: ZONE-WP-0001-T07
|
||||
status: todo
|
||||
priority: medium
|
||||
```
|
||||
|
||||
**Prove it on two consumers.** A model only its author honours is not adopted.
|
||||
The first is ops-warden: retire `policy.enabled` for a zone-aware control,
|
||||
closing `WARDEN-WP-0031-T05`. Re-run
|
||||
`ops-warden/scripts/check_policy_caller_identity.py` first — the 2026-08-19
|
||||
evidence (`decision:f3f7c88f9585582a`) will be stale, and re-establishing it is
|
||||
cheap by design. The second consumer comes from T01.
|
||||
|
||||
## Related
|
||||
|
||||
- ops-warden `ADR-0006` — enforcement is zone-scoped, never a global flag
|
||||
- ops-warden `WARDEN-WP-0032` — the ops-warden-side stub this was ported from
|
||||
- ops-warden `WARDEN-WP-0031` — the deferred flip, and the readiness evidence
|
||||
- flex-auth `FLEX-WP-0016` — the enforcing pin with no enforcing consumer
|
||||
- `net-kingdom/canon/standards/tenancy-posture_v0.1.md`
|
||||
- `repo-manager/docs/RailianceAppDeploymentGuide.md` — reefs
|
||||
Loading…
Add table
Add a link
Reference in a new issue