---
id: security-zones_v0.1
type: standard
status: draft
owner: zone-engine
publication_owner: net-kingdom
date: "2026-08-22"
---

# NetKingdom Security Zones v0.1

## 1. Purpose

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.

## 2. Authority 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.

## 3. Resolution 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.

## 4. Zone 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.

## 5. Stance 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.

## 6. Declaration 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.

```yaml
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`.

## 7. Compilation and resolved view

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

```yaml
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:

```yaml
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.

## 8. Membership-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.

## 9. Time-boxed exceptions

The normative lifecycle is the T04 decision in
`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.

## 10. Adoption

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 exact consumer revisions, tests,
resolved membership digests, and live caller decision are recorded in
`docs/evidence/security-zone-adoption-2026-08-22.md` in the owning zone-engine
repository.