ops-warden-adr-0009 accepted · 1 ops-warden reviewed 2026-08-22generated from canonical source — do not edit

ADR-0009 — Adopt security-zones v0.1 as a consumer

Source: ops-warden · docs/adr/ADR-0009-adopt-security-zones-as-a-consumer.md · 8afcc9c32170d76f6d5d02ea153967ed5c6fc4d5

Review due: 2026-11-22

Status

Accepted 2026-08-22 after zone-engine completed ZONE-WP-0001-T03/T05 and published the declaration, compilation, stance, and failure-mode contract in canon revision 337484a; zone-engine's reference compiler is revision 9b6ada7.

Context

ADR-0006 rejected a repo-wide policy.enabled switch because one boolean plus one fail_closed value made flex-auth a uniform dependency of every signing path, including continuity paths needed to repair that dependency. It deferred the replacement to zone-engine rather than designing an estate model here.

The owning model now exists. A zone is an evidenced workload-admission fact; control stance remains with the control owner, and dependency failure behavior remains with the PEP. Membership resolves only through an authoritative workload identity. Missing identity, membership, admission evidence, or a required floor is unknown, never an inferred permissive zone.

Decision

Ops-warden adopts security-zones_v0.1 and accepts its initial build-stage rows for the controls ops-warden owns:

  • the pre-sign PEP fails open for z0-experimental, z1-operational, z2-protected, z2-continuity, and build-profile unknown; it fails closed for z3-critical;
  • the agent high-risk read boundary remains enforced and fail-closed in every zone and for unknown;
  • warden plan never derives autonomous authority from unknown zone evidence.

The implementation follows four rules:

  1. policy.enabled and the global policy.fail_closed setting are retired and rejected by configuration loading. The PEP chooses failure behavior from a total per-zone map.
  2. The existing compiled flex-auth registry is the resource-membership carrier. Actor resources receive workload_id, security_zone, security_zone_admission, and security_zone_revision. The dormant trust_zone: platform constant is removed; it is not repurposed.
  3. Workload joins are explicit. Managed deployables use Repo Manager's exact (rapp_id, workload_identity.name, deployable?) tuple. Independent operational workloads use their owner-reviewed tenancy.yaml. Catalog owners distinguish not-applicable from applicable-but-unknown; no path or repository-name inference is allowed.
  4. A fail-open signing result is metadata, not silence. Signature and unified audit records carry the selected zone, failure mode, outcome, and decision id when one exists.

Ops-warden itself declares z1-operational. That is an accuracy decision: the workload has M1 evidence and does not yet have the SLO history, on-call rotation, or exercised recovery evidence needed for z2 admission.

Consequences

The global flip and its failure cycle no longer exist. An unknown target remains observable and follows the versioned build profile without manufacturing membership. A future organization-posture graduation changes the versioned control profile, not each workload declaration.

The flex-auth policy package still owns pre-sign stance. Ops-warden can compile and send the membership attributes, handle allow/audit_only/deny, and apply the correct PEP failure mode; it does not write flex-auth's Rego rows.

Catalog coverage is intentionally honest at adoption: exact references resolve where authoritative declarations exist, applicable lanes without one report unknown with a reason, and generic actions/patterns are explicitly not-applicable. Resolution coverage improves by adding owner declarations, never by adding heuristics here.