Add NetKingdom Security Layer Model v0.1 (proposed)
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 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
This commit is contained in:
parent
56f5ba8a2c
commit
1c3a9b46e3
2 changed files with 278 additions and 0 deletions
|
|
@ -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,
|
||||
|
|
|
|||
275
canon/standards/security-layer-model_v0.1.md
Normal file
275
canon/standards/security-layer-model_v0.1.md
Normal file
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue