## 01Purpose

A security zone is a named workload-admission standard. It answers which scrutiny a workload has qualified for; control-owner policy then answers what a particular control does in that zone. A zone is not a repository label, a credential lane, a network segment, a reef, or a temporary exception.

This standard is a sibling of `tenancy-posture_v0.1`. It owns zone identity, membership, admission, resolution, and the time-boxed exception lifecycle. `flex-auth` remains the only PDP for decisions it renders. Every other control continues to be owned and evaluated at its existing enforcement point.

## 02Authority and conformance

Authority is split deliberately:

Fact or rule | Authority
--- | ---
Workload identity and requested membership | Workload's responsible repo
Zone identities and admission standards | This standard, owned by zone-engine
Per-zone stance | Owner of the control that renders the effect
Failure behavior when a dependency is unavailable | Owner of the PEP
Publication | net-kingdom canon

Conformance is accuracy, not altitude. A lower zone declared with evidence is conformant. A stricter zone that the workload cannot evidence is not. Changing membership to evade a control is not an exception mechanism.

The workload is the sole zone policy subject. It includes independently governed application, automation, maintenance, and operational/control-plane execution units. The workload executing a tunnel, credential broker, policy service, or maintenance operation requires identity; the tunnel, grant, lane, pattern, action, human, or agent does not become a workload merely because a control observes it. Those retain native typed identity and caller/resource context.

## 03Resolution is authoritative

The stable `workload_identity.name` is the join key. Runtime principals, resources, credential lanes, and controls reference it explicitly. A resolver MUST NOT infer membership from repository ownership, paths, lane types, actor classes, environment, criticality, reefs, organization posture, or naming conventions.

For a managed deployable, the authoritative cross-repository reference is the Repo Manager v1 tuple `(rapp_id, workload_identity.name)`, optionally narrowed by `deployable`. A catalog also declares whether its subject is workload applicable. Resolution returns both the reference result and admission result:

- `satisfied` — the workload has an authoritative identity and evidence meeting the declared zone's floor; `effective_zone` is the declared zone;
- `unsatisfied` — identity and membership are declared, but evidence is below the admission floor; `effective_zone` is `unknown`;
- `unknown` — identity, membership, or a required floor/evidence input cannot be resolved for a workload-applicable subject; `effective_zone` is `unknown`;
- `not-applicable` — the owning catalog explicitly establishes that the subject is an action, actor, lane, pattern, or resource rather than a workload; no zone is resolved and the control uses that subject's native identity.

`unknown` is a result, not a zone. A control MUST declare an explicit treatment for it. That treatment may deny, escalate, or use a reviewed build-stage rule; it never manufactures membership and never grants an exception.

## 04Zone catalog

The initial catalog follows the estate's existing `M0`–`M3` maturity ladder and adds one non-monotone continuity band required by ops-warden `ADR-0006`.

Zone id | Admission floor | Environment/data boundary | Purpose
--- | --- | --- | ---
`z0-experimental` | `M0` promotion evidence | Synthetic only; no real credential or user data | Experiments where advisory controls preserve iteration speed
`z1-operational` | `M1` promotion evidence | Production secret handling for at most `internal` data | Early operational workloads with an owned front door
`z2-protected` | `M2` promotion evidence | `prod`; at most `confidential` data | Production workloads requiring review, SLO/on-call, and incident readiness
`z3-critical` | `M3` promotion evidence | `prod`; at most `restricted` data | Critical or regulated workloads with the strongest normal failure behavior
`z2-continuity` | `M2` plus dependency/recovery evidence | `prod`; at most `confidential` data | Foundational access or recovery workloads where fail-closed dependency cycles would cause an outage

`z2-continuity` is a sibling of `z2-protected`, not a relaxation of its admission floor. It exists because enforcement stance is not monotone: a tunnel or credential-issuance path can require production scrutiny while deliberately remaining fail-open for one availability-sensitive control. Placement on a reef is never evidence for any zone.

### 4.1 Context floor

The declared zone must be at least as strict as the workload context requires. The context floor is the maximum of every resolved input:

`criticality` | Minimum maturity
--- | ---
`low` | `M0`
`medium` | `M1`
`high` | `M2`
`critical` | `M3`

Data-class floors are consumed from the canon-owned classification mapping; the current `synthetic → M0`, `internal → M1`, `confidential → M2`, and `restricted → M3` mapping is already used by ops-warden. An absent or unresolved floor makes admission `unknown`. In particular, `public` is disclosure policy and `synthetic` is data origin: they are not aliases, and this standard does not invent a floor while info-tech-canon's ruling is pending.

`organization_posture` may select a versioned control profile, but it never changes identity, membership, or admission.

## 05Stance and failure-mode model

Every owner-qualified control publishes a total mapping over all zone ids plus `unknown`. There is no implicit default.

- `enforced` — the control's deny or escalation effect changes the outcome;
- `advisory` — the control evaluates fully and records the outcome it would have produced, but does not block;
- `exempt` — the control is deliberately not evaluated for this zone and emits the versioned exemption reason.

Failure mode is separate and PEP-side:

- `fail_closed` — an unavailable or invalid evaluator produces the control's safe blocking/escalation outcome;
- `fail_open` — the PEP proceeds and records that the control was unavailable.

`exempt` has no failure mode. A local control with no remote dependency uses `fail_closed` to describe evaluator errors. Changing stance is a policy-package change owned by the control owner, not a membership change.

### 5.1 Initial build-stage control profile

This profile is the v0.1 proposal for the first consumer. It is not stored in a workload's `zones:` declaration. flex-auth owns the pre-sign rows; ops-warden owns the other rows and every PEP failure mode.

Zone | flex-auth pre-sign stance / ops-warden PEP | agent high-risk read boundary | `warden plan` zone rule
--- | --- | --- | ---
`z0-experimental` | `advisory` / `fail_open` | `enforced` / `fail_closed` | `advisory`; evaluator failure cannot produce `autonomous`
`z1-operational` | `advisory` / `fail_open` | `enforced` / `fail_closed` | `advisory`; evaluator failure cannot produce `autonomous`
`z2-protected` | `enforced` / `fail_open` | `enforced` / `fail_closed` | `enforced`; minimum `founder_required` when the zone rule matches
`z3-critical` | `enforced` / `fail_closed` | `enforced` / `fail_closed` | `enforced`; minimum `founder_required` when the zone rule matches
`z2-continuity` | `enforced` / `fail_open` | `enforced` / `fail_closed` | `enforced`; minimum `founder_required` when the zone rule matches
`unknown` | `advisory` / `fail_open` under the versioned `build` profile | `enforced` / `fail_closed` | `enforced`; never `autonomous` from zone evidence

The `unknown` pre-sign treatment is an explicit organization-build policy, not a permissive membership default. It must change through a versioned control profile when the organization posture graduates.

The agent read boundary stays enforced in every zone: build-stage permissiveness does not extend to disclosing high-risk credentials. For a missing lane risk:

- `z0-experimental` may resolve to `standard` only when admission proves the lane can expose synthetic material exclusively;
- `z1-operational` and `z2-protected` resolve to at least `high`;
- `z3-critical` resolves to `critical`, treated by the boundary as at least `high`; and
- unresolved membership resolves to at least `high`.

An explicit grade always remains preferable. `accepted` is an acceptance record, not a risk grade.

## 06Declaration in `tenancy.yaml`

For a single-service declaration, `zones:` is a sibling of `tenancy:` and `workload_identity`. For a `services:` declaration, both `workload_identity` and `zones` occur inside the same service entry. A multi-service file MUST NOT use a top-level `zones:` block.

Every managed running deployable has an authoritative `rapp-*/declarations/rapp.yaml`. Its `workload_identity.declaration_ref` points to that declaration, and consuming catalogs reference it using the Repo Manager v1 tuple. A pre-rapp deployable is migration debt and resolves `unknown`. An independently governed operational execution unit that is not a managed deployable may declare directly in its responsible repo's `tenancy.yaml`; this does not turn a human action or infrastructure resource into a fictional rapp or workload.

    schema_version: "0.1"
    framework: netkingdom-tenancy-posture
    service: ops-bridge-tunnel
    role: operational-access-path
    workload_identity:
      name: ops-bridge-tunnel
      kind: operational-control-plane
      responsible_repo: ops-bridge
      identity_bindings:
        - scheme: ssh-certificate
          authority: ops-warden
          subject: agt-ops-bridge
          principal_type: agent
          environment: prod
    tenancy:
      # tenancy-posture_v0.1 content omitted
    zones:
      standard: security-zones_v0.1
      membership: z2-continuity
      responsible_party: ops-bridge
      justification: foundational tunnel path must retain availability under PDP loss
      context:
        maturity: M2
        criticality: high
        data_classification: confidential
      evidence:
        - ref: docs/evidence/ops-bridge-tunnel-zone.md
          supports: [M2, continuity-dependency, recovery]
      reviewed: "2026-08-22"
      review_due: "2026-11-22"

The `zones:` block contains only membership evidence. It MUST NOT contain control stance, failure mode, organization posture, or exceptions.

Required fields are:

- `standard` — exactly `security-zones_v0.1`;
- `membership` — one zone id from §4;
- `responsible_party` — the party answering for this membership;
- `justification` — why the zone fits the workload's actual context;
- `context` — the evidenced `maturity`, `criticality`, and `data_classification` used for admission. A managed workload's latter two values must agree with its resolved rapp projection; `n/a` requires an evidence-backed reason;
- `evidence` — one or more references and the admission facts each supports;
- `reviewed` and `review_due` — ISO dates, with review due after review.

Permanent membership changes are reviewed source changes. A change to a lower floor also records its reason and approver in the change review. Temporary relaxation uses an exception and never changes `membership`.

## 07Compilation and resolved view

Compilation produces a workload-addressable resolved record. At minimum it contains:

    workload_id: ops-bridge-tunnel
    workload_ref:
      applicability: applicable
      rapp_id: null                 # required for a managed deployable
      name: ops-bridge-tunnel
      deployable: null              # optional for a managed deployable
    identity_binding: ssh-certificate/ops-warden/agt-ops-bridge
    declared_zone: z2-continuity
    admission: satisfied
    effective_zone: z2-continuity
    membership_revision: sha256:<digest>
    guarantees:
      - authoritative-workload-identity
      - explicit-zone-membership
      - non-inferred-resolution
      - enforcement-time-exception-expiry
    controls:
      - id: flex-auth/pre-sign
        policy_owner: flex-auth
        stance: enforced
        pep_owner: ops-warden
        failure_mode: fail_open
        policy_ref: <versioned-package>

The `membership_revision` covers the authoritative workload binding, `zones:` block, and source revision. Control results include their policy/profile version and any active exception id and expiry. This is the machine-readable answer to “which zone is this workload in, and what applies there?” It may be compiled into existing consumer artifacts; it is not a synchronous zone-engine lookup.

For managed deployables, compilation consumes the exact Repo Manager reference projection:

    workload_ref:
      applicability: applicable
      rapp_id: rapp-issue-core
      name: issue-core
      deployable: issue-core  # optional

The owning catalog uses `applicability: not-applicable` for a native non-workload subject. Absence of either applicability or an expected reference is `unknown`, not `not-applicable`. Zone-engine consumes these outcomes; it does not parse a path or repository name to repair them.

For flex-auth's pre-sign control, the governed workload is the target of the certificate or grant, so the compiler writes `workload_id`, `security_zone`, `security_zone_admission`, and `security_zone_revision` on the resource attributes. Caller identity remains in the subject. A control that governs the requesting workload must declare that role explicitly and use separately named caller-workload attributes.

The dormant `trust_zone: platform` constant is not security-zone membership and MUST be retired before adoption. The new concept is named `security_zone`; the two fields must not coexist as competing zone sources.

## 08Membership-change observability

A membership change becomes effective only through a reviewed declaration and a newly compiled artifact. The compiler emits the source and membership revision, rejects ambiguous identities, and reports additions, removals, and changes against the preceding snapshot. Controls expose the membership revision in their decision or verdict evidence.

A zone that can be widened by editing an unversioned runtime label is not conformant.

## 09Time-boxed exceptions

The normative lifecycle is the ZONE-WP-0001-T04 decision in `zone-engine/docs/exception-lifecycle-2026-08-22.md`: only the control owner's designated authority grants a named-workload, named-zone, named-control relaxation within a declared maximum duration. Enforcement applies it only for `not_before <= now < not_after`; invalid or unevaluable records are inactive, expiry restores the base rule automatically, and no minted credential, lease, or session may outlive the exception.

Exceptions live with the versioned control policy or PEP configuration and are evaluated where their effects occur. This requires no zone-engine runtime.

## 10Adoption

Net-kingdom published this standard at revision `337484a`. Adoption requires:

1. flex-auth and ops-warden accept the initial control profile or publish a versioned replacement with total zone and `unknown` coverage;
2. at least two workload owners declare authoritative identities and zones;
3. a third consumer compiles or reads the resolved view; and
4. ops-warden retires `policy.enabled` and the dormant `trust_zone` constant in the same migration.

All four gates were met on 2026-08-22. The owning zone-engine repository records the exact consumer revisions, tests, resolved membership digests, and live caller decision in `docs/evidence/security-zone-adoption-2026-08-22.md`.