---
id: netkingdom-security-layer-model-v0.1
type: standard
title: "NetKingdom Security Layer Model v0.1"
domain: netkingdom
status: superseded
version: "0.1"
owner: gate-house
publication_owner: net-kingdom
created: "2026-08-28"
updated: "2026-08-28"
last_reviewed: "2026-08-28"
review_interval: 3m
source_revision: "gate-house@7f13f72"
standard_token: security-layer-model_v0.1
superseded_by: canon/standards/security-layer-model_v0.2.md
related:
  - canon/standards/security-zones_v0.1.md
  - canon/standards/tenancy-posture_v0.1.md
  - canon/standards/credential-management_v0.2.md
  - canon/standards/user-engine-boundary-contract_v0.1.md
  - canon/standards/tenant-engine-boundary-contract_v0.1.md
  - gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md
  - gate-house/INTENT.md
---

# NetKingdom Security Layer Model v0.1

> **Superseded 2026-08-28 by [v0.2](security-layer-model_v0.2.md).** All three
> repositories whose boundaries moved assented to this version and each returned
> a finding; v0.2 carries the results. Retained because the twelve estate
> `INTENT.md` review notes cite this file. Read v0.2 for the current rules —
> §5 (sanctioned shapes), §6.2 (doctrine as input), and §9 (capability
> assignment) changed materially.

## 1. Purpose

This standard states how NetKingdom's IT-security estate is layered, and what
each layer may and may not do. It answers one question:

> **Given a repository, which layer is it in, and what does that permit it to
> own?**

The model exists because the estate acquired overlapping claims to the same
responsibility — most visibly, two repositories describing themselves as the
authorization control plane — and the overlap was invisible in each
repository's own documents. A layer assignment makes the claim explicit and
checkable.

The layers are distinguished by **determinism** and by **the kind of artifact
the layer produces**, not by technical tier, deployment topology, or team.

This standard is not an org chart, not a network model, not a deployment
topology, and not a dependency graph. It does not assign work, and it does not
replace any repository's boundary contract; it constrains what such a contract
may claim.

## 2. Authority and conformance

| Fact or rule | Authority |
| --- | --- |
| The layers, their definitions, and the rules between them | This standard, owned by gate-house |
| Which layer a given repository is in | This standard, §4 catalog |
| What a repository owns within its layer | That repository's `INTENT.md` and boundary contract |
| Whether a specific request is permitted | `access-engine` — never this standard |
| Security doctrine and invariants | gate-house |
| Publication | net-kingdom canon |

A repository conforms when its `INTENT.md` declares its layer, its claims fall
within that layer's permissions (§3), and it satisfies the binding rule (§5).

## 3. The layers

| Layer | Character | Produces | Deterministic |
| --- | --- | --- | --- |
| **Taxonomy** | cross-cutting language | terms, semantic contracts, standards | n/a — describes |
| **Tooling** | infrastructure and state | data structures, persistence | yes |
| **Engines** | interfaces for a modeled concept | APIs, contracts | yes |
| **Staff** | management, operations, change, controlling | specifications, decisions, workplans, tasks | **no** |

### 3.1 Taxonomy

Cross-cutting language. Taxonomy repositories define terms and semantic
contracts so the other layers can interoperate without integration by
interpretation. They own no runtime position and no state any layer depends on.

`info-tech-canon` holds ecosystem-wide semantic contracts. NetKingdom-specific
security architecture — including this standard — is net-kingdom canon's. The
two MUST NOT be read as competing: the first names things for the whole
ecosystem, the second rules on NetKingdom security.

### 3.2 Tooling

Deterministic infrastructure: data structures, persistence, and the consistent,
performant, scalable keeping of state. Much of it is third-party; some is
homegrown; all of it is infrastructure.

Tooling MUST be reachable from Staff only through an Engine (§5).

### 3.3 Engines

Deterministic APIs for a modeled concept — a user, a tenant, a zone, a secret,
an access rule. An engine provides the functionality that concept needs and
exposes it as a contract. New concepts become new engines as they become
relevant.

An engine's defining property is that **the same authoritative input state
yields the same result**. Engines are where the estate's deterministic
guarantees live, and therefore where every enforcement boundary MUST sit.

### 3.4 Staff

Interactive and non-deterministic. Staff is the management layer: operations,
change, innovation, and controlling. It works through agentic capability —
assistants and autonomous agents — and its artifacts are specifications,
decisions, workplans, and tasks.

Staff repositories MUST NOT hold state that another layer depends on at
runtime, and MUST NOT render or cache any decision that an Engine is
responsible for.

Staff includes repositories that act at runtime, such as adaptive defence and
offensive validation. Acting at runtime does not make a repository an Engine;
being agentic makes it Staff, and §5 governs how it acts.

## 4. Layer catalog

Current assignment for the security estate. Adding a repository to this catalog
is a change to this standard.

| Repository | Layer | Owns |
| --- | --- | --- |
| `info-tech-canon` | Taxonomy | ecosystem-wide semantic contracts and terminology |
| `net-kingdom` | Taxonomy | NetKingdom standards of record; publication |
| `key-cape` | Tooling | packaged identity tooling (authelia, lldap, privacy-idea); IAM profile; authentication |
| `OpenBao` | Tooling | secret storage, leases, PKI, dynamic secret engines |
| `user-engine` | Engine | users, accounts, memberships |
| `tenant-engine` | Engine | tenant-as-an-entity facts |
| `zone-engine` | Engine | zone identity and membership — retained as offline reference conformance per its 2026-08-23 disposition |
| `secrets-engine` | Engine | credential abstraction, custody, lifecycle |
| `access-engine` | Engine | **the policy decision** — the only decision point (§6) |
| `gate-house` | Staff | security and defence doctrine, authority context, conformance review, curriculum |
| `ops-mason` | Staff | building and tearing down access routes and perimeters |
| `ops-warden` | Staff | operational access lanes, stewardship, runbooks |
| `kings-guard` | Staff | adaptive defence, observation, containment |
| `whitehat-security` | Staff | offensive validation |

`access-engine` is the ruled name for the repository currently called
`flex-auth`. Until the governed rename completes, `flex-auth` is the same
repository under its former name; references to either denote the same
authority.

## 5. The binding rule

> **Staff never touches Tooling directly. It acts only through Engine APIs.**

A Staff repository MUST NOT hold a direct client for a Tooling-layer system —
no direct database connection, no direct OpenBao client, no direct cluster
mutation — and MUST route the equivalent need through the owning engine.

This is the architectural form of *no privilege from cognition*. It is why
`kings-guard` may contain a threat only by calling an engine, and why an
autonomous coding agent gets no shortcut around one.

The rule is deliberately mechanically checkable: a Staff repository holding
such a client is in violation, and the violation is greppable. A Staff
repository needing a capability no engine exposes MUST raise that as an engine
gap, not solve it locally.

Read-only observation of Tooling for diagnostics MAY be permitted where the
owning engine exposes no equivalent, but it MUST be declared in the Staff
repository's `INTENT.md` and treated as an engine gap to close, not a standing
arrangement.

## 6. One decision point

`access-engine` is the only policy decision point in NetKingdom. No other
repository, in any layer, may render or cache authorization decisions.

This was first ruled in `zone-engine/INTENT.md` §5 — *"flex-auth is the policy
decision point. It stays the only one."* — drawn by flex-auth on review of a
zone-engine draft that had it wrong. This standard generalizes that ruling from
one repository to the whole estate.

The failure mode is stated in the same source, and is adopted here:

> *"It becomes a second decision point. The failure would not announce itself;
> it would arrive as a small convenience."*

Two consequences follow:

- **Compiled data that determines an outcome is still deciding.** A registry, a
  cache, or a schema that resolves a result before the engine runs has decided
  early. Provenance must remain reconstructable from the engine's decision.
- **No Staff repository may host a decision point.** A deterministic authority
  boundary inside a non-deterministic layer contradicts the invariant the
  estate is built on. gate-house was re-cut on precisely this ground.

## 7. Relationship to the Active Secrets Management Canon

Read by determinism, the layers reproduce the Canon's three planes:

```text
Staff       interactive, non-deterministic   ≈  Cognitive Plane
Engines     deterministic APIs               ≈  Authority Plane
Tooling     deterministic state              ≈  Execution Plane
Taxonomy    cross-cutting language
```

*Cognition proposes. Authority disposes. Infrastructure executes.* is therefore
NetKingdom's layering rule, not only its security maxim. The estate's structure
is an instance of the principle its security canon teaches, and §5 and §6 are
that principle applied to repositories rather than to requests.

## 8. Vocabulary demarcations

Words the estate has used for more than one thing. These bindings are
normative.

| Term | Belongs to | Not |
| --- | --- | --- |
| **access lane** | ops-warden, ops-mason (Staff) — how a worker reaches a host | the decision about whether they may |
| **access rule** | access-engine (Engine) — whether an actor may act | the route by which they arrive |
| **control plane** | Engine layer | a Staff repository's self-description |
| **doctrine** | gate-house | a lane owner's runbook |
| **runbook** | the Staff repository that stewards the lane | a substitute for doctrine |
| **posture** | kings-guard publishes; gate-house defines its authority meaning; access-engine renders it | a privilege source |

Posture carries an asymmetry that MUST hold: adaptive systems may reduce
authority, require step-up, or request containment. They MUST NOT
probabilistically manufacture additional authority.

## 9. Changing layer

A repository's layer is not permanent. `zone-engine` changed layer in practice
when its runtime hypothesis was falsified and it was retained as offline
reference conformance rather than an engine.

A layer change MUST be recorded as a decision, MUST update the repository's
`INTENT.md`, and MUST obtain assent from the repositories whose boundaries move
as a result. A repository MUST NOT acquire a new layer's permissions by
gradual practice.

## 10. Conformance

Mechanically checkable:

- every repository in §4 declares its layer in `INTENT.md`;
- no Staff repository holds a direct Tooling client (§5);
- no repository other than `access-engine` exposes an authorization decision
  surface (§6).

Requires review:

- whether a repository's claims stay inside its layer's permissions;
- whether compiled or cached data has become an early decision (§6);
- whether the demarcated vocabulary in §8 is used correctly.

## 11. Adoption

Status is **proposed**. The estate's `INTENT.md` files carry a review note as
of 2026-08-28 recording each repository's layer and the adaptation this
standard implies; the bodies are not yet adapted.

Adoption for a repository means: its `INTENT.md` declares its layer, its
ownership claims fall inside that layer, and any boundary it shares has been
assented to by the other side — as flex-auth and zone-engine did on review.

Two adaptations carry the most weight and are not yet assented:

1. `flex-auth` reframed as an Engine, renamed `access-engine`, with policy
   authoring separated from policy evaluation.
2. `kings-guard` and `ops-warden` releasing vocabulary — "control plane" and
   the security curriculum respectively — to the layer that owns it.

## 12. Open questions

- Whether Tooling warrants subdivision between third-party and homegrown
  components; v0.1 deliberately does not.
- How a future `role-engine` divides responsibility with `access-engine`,
  given roles are inputs to access rules.
- Whether non-security repositories in the wider estate adopt the same model,
  or whether it stays scoped to the security estate as v0.1 assumes.