ops-warden/workplans/WARDEN-WP-0032-security-zones.md

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	depends_on_workplans	created	updated
WARDEN-WP-0032	workplan	Security zones — scope enforcement to bands of differing rigidity	infotech	ops-warden	proposed	ops-warden	netkingdom	P1	WARDEN-WP-0015 WARDEN-WP-0029 WARDEN-WP-0031	2026-08-19	2026-08-19

WARDEN-WP-0032 — Security zones

ADR-0006 defers policy.enabled: true until enforcement can be scoped. This workplan builds the thing it defers to.

The problem in one paragraph

ops-warden has three posture axes already: environment (dev/test/prod, WP-0015), workload maturity (M0–M3, WP-0015), and organization posture (build, WP-0029). What it does not have is a way to say "this band of the estate is enforced, that one is advisory" — so every enforcement control it ships is a repo-wide boolean. policy.enabled is the first one to actually become flippable, and flipping it would harden the access needed to perform the refactors currently underway. The axes describe posture; nothing acts on them.

What a zone has to answer

A zone is only useful if it decides something. Minimum:

• Membership — what puts a lane, actor, or workload in this zone? Derived from the existing axes where possible rather than a fourth hand-maintained list.
• Enforcement stance per control — for each gate (pre-sign policy, agent read-boundary, high-risk refusal): enforced, advisory, or exempt.
• Failure mode — fail-closed or fail-open, per control per zone. This is the actual bite: fail_closed is what makes a dead tunnel an outage.
• Who may change it, and how it is observed — a zone that can be quietly widened is not a boundary.

Open questions to settle before designing

• Is a zone a property of the actor (adm/agt/atm), the lane (catalog entry), the workload, or the moment (an active refactor)? The CoulombCore decommission suggests the last one matters and is the hardest to model — a time-boxed relaxation is a different object than a standing zone.
• Do zones compose with the three existing axes, or replace one? A fourth independent axis multiplies states; folding organization_posture in may be the honest move.
• Is this ops-warden's model to own at all, or NetKingdom canon that ops-warden consumes? ADR-0005 says implement narrowly and route broadly. A security zone model that only ops-warden honours is worth much less than one flex-auth, secrets-engine, and tenant-engine also read — but ops-warden should not absorb an estate-wide model on its own authority either. Settle this first; it changes who writes the rest.

Tasks

id: WARDEN-WP-0032-T01
status: todo
priority: high

Decide ownership before designing. Take the third open question to net-kingdom (canon) and flex-auth (the PDP that would enforce it). If it is canon, ops-warden drafts and offers, as it did for the WP-0015 maturity model, and consumes the result. If it is ops-warden's, say so explicitly and record why. Do not build a model whose owner is unsettled.

id: WARDEN-WP-0032-T02
status: todo
priority: high

Name the zones against reality, not in the abstract. Walk the current estate — the 27 catalog lanes, the actor inventory, the workloads with posture descriptors — and see what bands actually exist. A zone model that does not partition today's lanes cleanly is wrong, and the exceptions are the interesting part. Include the refactor case explicitly: what zone is a lane in while the component it fronts is being rebuilt?

id: WARDEN-WP-0032-T03
status: todo
priority: high

Model enforcement stance and failure mode per zone per control, covering at minimum: the flex-auth pre-sign gate (policy.enabled / fail_closed), the agent read-boundary on risk: high lanes (ADR-0004), and the warden plan escalation verdicts (WP-0029). Each must be expressible as enforced / advisory / exempt with an explicit failure mode.

id: WARDEN-WP-0032-T04
status: todo
priority: medium

Make policy.enabled zone-aware and retire the global boolean. The successor control reads the zone of the actor being signed for. Ship the migration in the same change as the deprecation — leaving both is exactly the second-source-of-truth failure ADR-0001 exists to prevent.

id: WARDEN-WP-0032-T05
status: todo
priority: medium

Close WARDEN-WP-0031 T05 through this model — enable the pre-sign gate for whichever zone the SSH signing lane lands in, with that zone's failure mode. Re-run scripts/check_policy_caller_identity.py first; the WP-0031 evidence will be stale by then and re-establishing it is cheap by design.