From 1c3a9b46e3487a0b1b5fe84ea70a08132bd47c08 Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 28 Aug 2026 20:59:00 +0200 Subject: [PATCH] Add NetKingdom Security Layer Model v0.1 (proposed) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit States how the security estate is layered — Taxonomy, Tooling, Engines, Staff — distinguished by determinism and by the artifact each layer produces, and what each layer may own. Carries two normative rules. §5: Staff never touches Tooling directly; it acts only through Engine APIs — the architectural form of "no privilege from cognition", and mechanically checkable. §6: access-engine is the only policy decision point, generalizing to the whole estate the ruling first drawn in zone-engine/INTENT.md §5, and barring any Staff repository from hosting a decision point. Also fixes the vocabulary the estate has used for more than one thing: access lane vs access rule, doctrine vs runbook, control plane as Engine vocabulary, and the posture asymmetry. Owner gate-house, published by net-kingdom. Status proposed: the two adaptations carrying the most weight — flex-auth's reframing and rename to access-engine, and kings-guard and ops-warden releasing vocabulary — are not yet assented by their owners. Co-Authored-By: Claude Opus 5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9 --- README.md | 3 + canon/standards/security-layer-model_v0.1.md | 275 +++++++++++++++++++ 2 files changed, 278 insertions(+) create mode 100644 canon/standards/security-layer-model_v0.1.md diff --git a/README.md b/README.md index eeeb71b..e3f541b 100644 --- a/README.md +++ b/README.md @@ -12,6 +12,9 @@ The dynamic, self-optimizing security platform is the long-term direction in ## Orientation - [SCOPE.md](SCOPE.md) — what this repo owns, current state, and when it is relevant +- [Security layer model](canon/standards/security-layer-model_v0.1.md) — how the + security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each + layer may own - [Security scenario composition](canon/standards/security-scenario-composition_v0.1.md) — deterministic, plan-only capability and trust composition - [Posture feedback](canon/standards/posture-feedback_v0.1.md) — deterministic, diff --git a/canon/standards/security-layer-model_v0.1.md b/canon/standards/security-layer-model_v0.1.md new file mode 100644 index 0000000..7d40951 --- /dev/null +++ b/canon/standards/security-layer-model_v0.1.md @@ -0,0 +1,275 @@ +--- +id: netkingdom-security-layer-model-v0.1 +type: standard +title: "NetKingdom Security Layer Model v0.1" +domain: netkingdom +status: proposed +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 +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 + +## 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.