NetKingdom Security Zones v0.1

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:

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.

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:

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.

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.