diff --git a/README.md b/README.md index e3f541b..5dbe7d6 100644 --- a/README.md +++ b/README.md @@ -12,7 +12,7 @@ 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 layer model](canon/standards/security-layer-model_v0.2.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) diff --git a/canon/standards/security-layer-model_v0.1.md b/canon/standards/security-layer-model_v0.1.md index 7d40951..306ff72 100644 --- a/canon/standards/security-layer-model_v0.1.md +++ b/canon/standards/security-layer-model_v0.1.md @@ -3,7 +3,7 @@ id: netkingdom-security-layer-model-v0.1 type: standard title: "NetKingdom Security Layer Model v0.1" domain: netkingdom -status: proposed +status: superseded version: "0.1" owner: gate-house publication_owner: net-kingdom @@ -13,6 +13,7 @@ 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 @@ -25,6 +26,13 @@ related: # 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 diff --git a/canon/standards/security-layer-model_v0.2.md b/canon/standards/security-layer-model_v0.2.md new file mode 100644 index 0000000..39ad804 --- /dev/null +++ b/canon/standards/security-layer-model_v0.2.md @@ -0,0 +1,396 @@ +--- +id: netkingdom-security-layer-model-v0.2 +type: standard +title: "NetKingdom Security Layer Model v0.2" +domain: netkingdom +status: accepted +version: "0.2" +supersedes: canon/standards/security-layer-model_v0.1.md +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@4f618b4" +standard_token: security-layer-model_v0.2 +assented_by: + - "flex-auth FLEX-DEC-2026-001" + - "kings-guard KG-DEC-2026-001" + - "ops-warden ADR-0010" +related: + - canon/standards/security-zones_v0.1.md + - canon/standards/tenancy-posture_v0.1.md + - canon/standards/credential-management_v0.2.md + - gate-house/decisions/decisions.md + - gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md +--- + +# NetKingdom Security Layer Model v0.2 + +## 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 layers are distinguished by **determinism** and by **the kind of artifact +the layer produces**, not by technical tier, deployment topology, or team. + +It 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. + +**What changed in v0.2.** v0.1 was assented to by all three repositories whose +boundaries moved, and each returned a finding. v0.1 had one lane for a Staff +repository that legitimately touches Tooling — read-only diagnostics — which is +narrower than the estate as it actually stands, and a rule with no lane for a +real sanctioned case is satisfied by relabelling rather than by closing the gap. +v0.1 also catalogued a capability (§4, containment) that §5 forbade discharging, +and applied its reconstructability test to engines but not to the doctrine +gate-house feeds them. §15 records the full change list. + +## 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 | +| Whether a Tooling contact is sanctioned | The declaring repository, under the shapes in §5, reviewable by gate-house | +| 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 its Tooling contacts take one of the +sanctioned shapes in §5 or are declared as gaps under §5.3. + +## 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 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. + +### 3.2 Tooling + +Deterministic infrastructure: data structures, persistence, and the consistent, +performant, scalable keeping of state. Much of it is third-party. + +### 3.3 Engines + +Deterministic APIs for a modeled concept — a user, a tenant, a zone, a secret, +an access rule. 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. + +A repository whose core function is inference or judgment fails this test by +construction and is Staff, however much of its work happens at runtime. + +### 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 an Engine is responsible for. + +Acting at runtime does not make a repository an Engine. Being agentic makes it +Staff, and §5 governs how it acts. + +## 4. Layer catalog + +| 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; 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 — 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 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; SSH certificate issuance | +| `kings-guard` | Staff | adaptive defence, observation; **containment — pending (§9.2)** | +| `whitehat-security` | Staff | offensive validation | + +`access-engine` is the ruled name for the repository currently called +`flex-auth`; both denote the same authority until the governed rename completes. +Execution conditions for that rename are recorded in its migration decision, not +here. + +## 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 — outside the shapes below. This is the architectural form of *no +privilege from cognition*, and it is deliberately mechanically checkable. + +Three shapes are sanctioned. Everything else is a violation. + +### 5.1 Read-only diagnostic observation + +A Staff repository MAY read Tooling state for diagnostics where the owning +engine exposes no equivalent. It MUST be declared in the repository's +`INTENT.md`. It grants no write, and it is an engine gap to close, not a +standing arrangement. + +### 5.2 Conduit + +A Staff repository MAY run the **owner's** tool under the **caller's** identity, +supplying no authority of its own. The test is the supplied-authority property: +the conduit MUST NOT present its own credential, MUST NOT widen what the caller +could already do, and MUST be reconstructable as the caller's action in audit. + +A conduit that presents its own token is not a conduit; it is §5.3 or a +violation. This shape MUST be declared, and the no-authority property SHOULD be +covered by a test. + +### 5.3 Declared engine gap + +Where a Staff repository must contact Tooling directly and no engine exposes the +capability, it MUST declare the contact rather than take an exemption. A +declared gap carries, machine-readably: + +| Field | Meaning | +| --- | --- | +| `capability` | what the contact does | +| `intended_owner` | the engine that should own it | +| `blocked_on` | why it cannot move today | +| `review` | a date, not "when convenient" | + +A declared gap is **tracked non-conformance**, not conformance. It does not +expire on its own and it is not a licence to add more. It exists because a rule +offering no lane for a real sanctioned case gets satisfied by relabelling rather +than by closing the gap — and a tracked gap is visible, whereas a relabelled one +is not. + +Prior art: `ops-warden` runs equivalent machinery for delegated lanes (27 +catalog entries carrying `delegation:`, queryable via `warden route gaps`), and +has offered it as reusable. + +## 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. + +First ruled in `zone-engine/INTENT.md` §5 — *"flex-auth is the policy decision +point. It stays the only one."* The failure mode, from the same source: *"It +becomes a second decision point… it would arrive as a small convenience."* + +### 6.1 Compiled data that determines an outcome is still deciding + +A registry, cache, or schema that resolves a result before the engine runs has +decided early. Provenance MUST remain reconstructable from the engine's decision +record. + +### 6.2 Doctrine reaches the decision as an input, or it is not applied + +This rule binds gate-house on the same terms. **An authority ceiling, mandate +constraint, or operating-mode restriction that determines an outcome MUST reach +the decision either as an input claim on the request or as a rule in the +versioned policy package**, so that its application is reconstructable from the +decision record. + +Doctrine that influences outcomes by any other route is a second decision point +wearing an author's hat. This is not a limit on gate-house's authorship; it is +what keeps that authorship auditable at decision time. + +### 6.3 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 this ground. + +## 7. Relationship to the Active Secrets Management Canon + +```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. §5 and §6 are that +principle applied to repositories rather than to requests. + +## 8. Vocabulary demarcations + +| Term | Belongs to | Not | +| --- | --- | --- | +| **access lane** | ops-warden, ops-mason (Staff) — how a worker reaches a host | the decision 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 stewarding 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. Capability assignment + +### 9.1 The catalog may not assign what the rules forbid discharging + +A Staff repository MUST NOT be catalogued in §4 as owning a capability that +requires a Tooling contact no engine exposes. Where the capability is intended +but the engine surface does not yet exist, the catalog entry MUST be marked +**pending** and the gap declared under §5.3. + +v0.1 violated this: it catalogued kings-guard as owning containment while §5 +forbade the only route to discharging it, making the capability zero rather than +degraded. Raised by kings-guard, KG-DEC-2026-001. + +### 9.2 Containment is pending an engine surface + +No engine exposes a containment surface today — nothing to reduce authority, +require step-up, or isolate a workload as a deterministic API. kings-guard's +containment claim is marked pending in §4 until one exists. + +### 9.3 Degraded-mode fallback belongs inside the engine + +Where a capability must survive partial failure, the fallback belongs to the +engine, not to Staff. The deterministic *fail to reduced authority* default is +`access-engine`'s, applied when it cannot reach its own inputs. + +This keeps the decision at the decision point and keeps the fallback +deterministic — which a Staff-layer fallback could never be. It is also why +engine-unavailable is not grounds for a Staff break-glass path: an incident is +when an attacker most wants the shortcut, and a containment path that bypasses +the decision point becomes an authority path the moment it is subverted. + +## 10. Changing layer + +A repository's layer is not permanent. `zone-engine` changed layer in practice +when its runtime hypothesis was falsified. + +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. +A repository MUST NOT acquire a new layer's permissions by gradual practice. + +## 11. Conformance + +Conformance has three states, and the distinction is the point: + +| State | Meaning | +| --- | --- | +| **Conforming** | no Tooling contact, or only §5.1/§5.2 shapes, declared | +| **Declared gap** | a §5.3 contact with owner, blocker, and review date — tracked non-conformance | +| **Undeclared violation** | anything else — a finding | + +Mechanically checkable: + +- every repository in §4 declares its layer in `INTENT.md`; +- every direct Tooling client in a Staff repository maps to a declared §5.1, + §5.2, or §5.3 entry; +- no repository other than `access-engine` exposes an authorization decision + surface; +- no §4 capability is catalogued without an engine surface or a pending mark. + +Requires review: whether claims stay inside layer permissions; whether compiled +or cached data has become an early decision (§6.1); whether doctrine is reaching +decisions as declared inputs (§6.2); whether the §8 vocabulary is used correctly. + +## 12. The conformance loop + +Doctrine no engine implements is fiction. The loop is normative, not +aspirational: + +```text +gate-house asserts an invariant + → the engines implement it, or declare a gap + → whitehat-security tries to break it + → kings-guard observes it in operation + → findings return to gate-house as doctrine change +``` + +A finding that a rule is unsatisfiable is a **success** of this loop, not a +failure of the reporting repository. v0.2 exists because three repositories used +it on first contact. + +## 13. Open gaps + +Declared under §5.3 or raised as unowned capability, as of 2026-08-28: + +| Gap | Declared by | Intended owner | +| --- | --- | --- | +| SSH-CA signing write (`VaultCA`, `bao kv put`) | ops-warden | secrets-engine | +| Authentication / assurance evidence | kings-guard | user-engine, access-engine | +| Secret-use evidence | kings-guard | secrets-engine | +| Containment surface | kings-guard | access-engine + runtime engines | +| Registry-snapshot digest in decision provenance | flex-auth | flex-auth (self-declared) | +| **Approval storage and lifecycle** — durable object, authenticated entries, atomic supersession | flex-auth | **unowned — see below** | + +The approval gap is the one open architectural hole. It is not gate-house's +(§3.4 forbids Staff holding state another layer depends on at runtime) and not +access-engine's (it does not own the organizational approval lifecycle). It +blocks `FLEX-WP-0017` T03 and T05. Assigning it requires a decision and the +assent of the receiving repository; this standard records the gap and does not +assign it. + +## 14. Adoption + +Status is **accepted**. All three repositories whose boundaries moved have +assented in writing, each with a decision record: + +| Repository | Record | Outcome | +| --- | --- | --- | +| flex-auth | `FLEX-DEC-2026-001` | assent to all three items; one self-declared non-conformance; two rename conditions | +| kings-guard | `KG-DEC-2026-001` | assent; declined the offered §5 relaxation; raised §9.1 | +| ops-warden | `ADR-0010` | assent to all three; veto not exercised; offered the §5.3 amendment | + +Adoption for a repository means its `INTENT.md` declares its layer, its +ownership claims fall inside that layer, its Tooling contacts are declared under +§5, and any shared boundary has been assented to by the other side. + +## 15. Change log + +v0.1 → v0.2: + +1. **§5 restructured** into three sanctioned shapes. Added §5.2 conduit + (ops-warden's question, ruled) and §5.3 declared engine gap (ops-warden's + amendment, accepted). +2. **§6.2 added** — doctrine must reach the decision as an input claim or a + versioned policy rule (flex-auth's boundary drawn back, accepted). +3. **§9 added** — the catalog may not assign a capability the rules forbid + discharging; containment marked pending; degraded-mode fallback ruled into + the engine (kings-guard's finding). +4. **§11 restructured** — conformance now has three states, distinguishing a + tracked gap from an undeclared violation. +5. **§12 made normative**, with the explicit statement that an + unsatisfiability finding is a success of the loop. +6. **§13 added** — open gaps register, including the unowned approval storage + and lifecycle capability. +7. §4 catalog gained the pending mark and ops-warden's SSH certificate lane. + +## 16. Open questions + +- Who owns approval storage and lifecycle (§13). The only structural hole. +- Whether Tooling warrants subdivision between third-party and homegrown. +- How a future `role-engine` divides responsibility with `access-engine`. +- Whether declared gaps need an estate-wide register rather than per-repository + declarations; ops-warden's `warden route gaps` is candidate machinery. +- Whether non-security repositories adopt the same model.