net-kingdom/canon/standards/security-layer-model_v0.1.md

id	type	title	domain	status	version	owner	publication_owner	created	updated	last_reviewed	review_interval	source_revision	standard_token	superseded_by	related
netkingdom-security-layer-model-v0.1	standard	NetKingdom Security Layer Model v0.1	netkingdom	superseded	0.1	gate-house	net-kingdom	2026-08-28	2026-08-28	2026-08-28	3m	gate-house@7f13f72	security-layer-model_v0.1	canon/standards/security-layer-model_v0.2.md	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. 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:

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.