coulomb/net-kingdom
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Security Layer Model v0.3 — assign approvals and maturity

Browse source 
v0.2 recorded the approval object as the one open architectural hole, and
carried a latent instance of its own §9.1 rule: gate-house was catalogued as
owning conformance review with no engine to act through. Two engines were
seeded to close both.

- §9.4: the approval object goes to approval-engine — not Staff (§3.4 forbids
  the runtime state), not access-engine (an evaluator owning what it evaluates
  is self-dealing), not audit-core (append-only is the opposite property).
  access-engine consumes approvals as input claims under §6.2; audit-core takes
  the tamper-evident evidence. Operative state and evidence record are separate
  artifacts with separate owners.
- §9.5: graded progression goes to maturity-engine. gate-house judges and
  proposes; maturity-engine computes and remembers. Carries the guardrail that
  a level may never gate a decision directly — under §6.1 that would be a
  second decision point by the graded back door.
- §4 catalog gained both engines; §13 register updated.

Status proposed: the new engines are seeded by owner direction with no other
side to assent yet, and the approval evidence half needs audit-core's assent.

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:
tegwick 2026-08-28 22:34:58 +02:00
parent 27a31f3f8f
commit 90cc64f728
3 changed files with 471 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -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.2.md) — how the
- [Security layer model](canon/standards/security-layer-model_v0.3.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)

8
canon/standards/security-layer-model_v0.2.md
View file

@ -3,7 +3,7 @@ id: netkingdom-security-layer-model-v0.2
type: standard
title: "NetKingdom Security Layer Model v0.2"
domain: netkingdom
status: accepted
status: superseded
version: "0.2"
supersedes: canon/standards/security-layer-model_v0.1.md
owner: gate-house
@ -14,6 +14,7 @@ last_reviewed: "2026-08-28"
review_interval: 3m
source_revision: "gate-house@4f618b4"
standard_token: security-layer-model_v0.2
superseded_by: canon/standards/security-layer-model_v0.3.md
assented_by:
- "flex-auth FLEX-DEC-2026-001"
- "kings-guard KG-DEC-2026-001"
@ -28,6 +29,11 @@ related:
# NetKingdom Security Layer Model v0.2
> **Superseded 2026-08-28 by [v0.3](security-layer-model_v0.3.md)**, which assigns
> the approval and maturity concepts §13 recorded as unowned. The assent record in
> §14 remains the basis on which the model was accepted; v0.3 changes §4, §9, and
> §13 only.
## 1. Purpose
This standard states how NetKingdom's IT-security estate is layered, and what

463
canon/standards/security-layer-model_v0.3.md Normal file
View file

@ -0,0 +1,463 @@
---
id: netkingdom-security-layer-model-v0.3
type: standard
title: "NetKingdom Security Layer Model v0.3"
domain: netkingdom
status: proposed
version: "0.3"
supersedes: canon/standards/security-layer-model_v0.2.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@516ed4e"
standard_token: security-layer-model_v0.3
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.3
## 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.3.** Two engines were seeded to own concepts v0.2 recorded
as unowned: `approval-engine` takes the approval object that §13 left homeless,
and `maturity-engine` takes graded progression — closing a §9.1 defect in
gate-house's own catalog claim, which asserted conformance review with no engine
to act through. §15 records the change list. v0.3 is **proposed**: the two new
engines are seeded by owner direction and have no other side to assent yet, and
the evidence half of the approval split needs `audit-core`'s assent.
**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) |
| `approval-engine` | Engine | the approval object — durable, authenticated, consumable, atomically supersedable (§9.4) |
| `maturity-engine` | Engine | graded progression against declared criteria and evidence; the gap register; capability readiness (§9.5) |
| `gate-house` | Staff | security doctrine, authority context, curriculum; **conformance review — through `maturity-engine` (§9.5)** |
| `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.
### 9.4 Approvals are an engine concept, not a Staff or audit concern
The approval object — durable, authenticated entries, distinct-approver
counting, atomic supersession, single consumption, revocation without holder
cooperation — is owned by `approval-engine`.
It is not Staff's: §3.4 forbids Staff holding state another layer depends on at
runtime. It is not the decision point's: an evaluator that owns the object it
evaluates is self-dealing. It is not the audit fabric's: an approval needs
mutable, in-path, current-state semantics, and an append-only archive is built
for the opposite property.
`access-engine` consumes approvals as **input claims** under §6.2 and never
mutates them. Every issuance, use, supersession, and revocation is emitted to
`audit-core` as tamper-evident evidence: the operative state and the evidence
record are different artifacts with different owners.
### 9.5 Graded progression is an engine concept
Maturity — how far a subject has progressed against declared criteria and
submitted evidence — is owned by `maturity-engine`. Given the same criteria and
the same evidence it MUST return the same level; that determinism is what makes
it an Engine rather than an opinion.
The division with Staff: **gate-house judges and proposes; maturity-engine
computes and remembers.** Interpretation is inference and stays Staff. A
criterion that cannot be evaluated by rule is not yet a criterion.
This closes a defect in v0.2's own catalog: `gate-house` was assigned
conformance review with no engine to act through, which is exactly the §9.1
problem raised against the containment claim. Staff acts only through Engine
APIs, including gate-house.
**A maturity level MUST NOT gate a decision directly.** Under §6.1, compiled
data that determines an outcome is still deciding. If a level determines whether
an action is permitted, it MUST reach `access-engine` as an input claim or a
versioned policy rule under §6.2, never by a consumer branching on a fetched
level.
Approvals and maturity are deliberate opposites — a closed binary state machine
against an open graded ladder — and neither engine may drift toward the other.
## 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 | **`approval-engine`** — assigned in v0.3 (§9.4) |
| Approval evidence — tamper-evident record of issuance, use, supersession, revocation | gate-house | `audit-core` — proposed, assent pending |
| Conformance review has no engine surface | gate-house (self) | **`maturity-engine`** — assigned in v0.3 (§9.5) |
The approval gap is resolved in v0.3 by seeding `approval-engine` (§9.4), which
unblocks `FLEX-WP-0017` T03 and T05 once implemented. Its evidence half is
proposed to `audit-core` and awaits that repository's assent.
Gaps are recorded here but tracked in `maturity-engine` (§9.5) once it exists;
this table is the interim register and should not outlive 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.
v0.2 → v0.3:
1. **§9.4 added** — approvals assigned to `approval-engine`, with the operative
state and the evidence record separated between it and `audit-core`.
2. **§9.5 added** — graded progression assigned to `maturity-engine`, closing
the §9.1 defect in gate-house's own conformance-review claim, and carrying
the guardrail that a level may never gate a decision directly.
3. §4 catalog gained both engines; gate-house's conformance-review claim now
names the engine it acts through.
4. §13 register updated: the approval hole is assigned, two new entries added.
## 16. Open questions
- Whether `audit-core` accepts the approval evidence half (§9.4, §13).
- Whether the gap register migrates from this standard into `maturity-engine`
once that engine exists, leaving the standard to state the rules only.
- 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.