Assent to Staff placement; release control-plane vocabulary (KG-IN-0001)
Answers gate-house intake KG-IN-0001 / GH-DEC-2026-001 against the NetKingdom Security Layer Model v0.1. Assent to all three points, recorded as KG-DEC-2026-001: - kings-guard declares layer Staff in INTENT.md; - "control plane" released to the Engine layer across INTENT, SCOPE, README, AGENTS and the adjacent-system boundary; - the posture asymmetry adopted as a repo invariant — already satisfied, every EffectorRequest carries an explicit authority_boundary. Boundary corrections: key-cape and OpenBao are Tooling, so their evidence is routed through user-engine/access-engine and secrets-engine rather than read directly. Finding on the invited challenge to §5: do not weaken the binding rule, but §4 catalogs kings-guard as owning containment while no engine exposes a containment surface — the charter is currently undischargeable. Two rulings requested of gate-house. Three engine gaps declared in INTENT.md. Residual handed off as KG-IN-0002 (vocabulary sweep of the architecture spec). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UEtvmYUBP2fDtirJGWn5MW Assistant: claude-code Assistant-Model: opus Assistant-Process: 4014379@bnt-lap001 Assistant-Session: 4af9e20f-1768-4afc-951b-b507784e382b
This commit is contained in:
parent
f78bca1586
commit
3d6025ae51
9 changed files with 457 additions and 31 deletions
149
.repo-manager/index.json
Normal file
149
.repo-manager/index.json
Normal file
|
|
@ -0,0 +1,149 @@
|
|||
{
|
||||
"schema": "repo_manager.index.v1",
|
||||
"slug": "layer-model-assent",
|
||||
"repo_root": "/home/worsch/kings-guard",
|
||||
"head_sha": "7c8ef38ee0603c4ca23e69abaff689b86da752b4",
|
||||
"observed_at": "2026-08-28T19:30:17.391432Z",
|
||||
"source_fingerprint": "ff379cda32bd3d625590480dbf164739c18022680a8390e4cd6a48514324cc5c",
|
||||
"source_files": [
|
||||
".repo-classification.yaml",
|
||||
"INTENT.md",
|
||||
"intakes/intakes.md",
|
||||
"workplans/KG-WP-0001-statehub-bootstrap.md",
|
||||
"workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md"
|
||||
],
|
||||
"work_records": [
|
||||
{
|
||||
"kind": "workplan",
|
||||
"id": "KG-WP-0001",
|
||||
"status": "finished",
|
||||
"title": "Bootstrap State Hub integration",
|
||||
"source_path": "workplans/KG-WP-0001-statehub-bootstrap.md",
|
||||
"uuid": "b7ff79b9-ae27-4a46-a782-49482392eb83",
|
||||
"parent_id": null,
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "KG-WP-0001-T01",
|
||||
"status": "done",
|
||||
"title": "Review Generated Integration Files",
|
||||
"source_path": "workplans/KG-WP-0001-statehub-bootstrap.md",
|
||||
"uuid": "add34171-9f18-48b9-a88e-07ea34cb6382",
|
||||
"parent_id": "KG-WP-0001",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "KG-WP-0001-T02",
|
||||
"status": "done",
|
||||
"title": "Verify Local Developer Workflow",
|
||||
"source_path": "workplans/KG-WP-0001-statehub-bootstrap.md",
|
||||
"uuid": "17fb3a0c-91c5-4b45-967e-962ef6c89ac5",
|
||||
"parent_id": "KG-WP-0001",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "KG-WP-0001-T03",
|
||||
"status": "done",
|
||||
"title": "Seed First Real Workplan",
|
||||
"source_path": "workplans/KG-WP-0001-statehub-bootstrap.md",
|
||||
"uuid": "5b5f56d9-7e89-43b6-94c3-db4461e9eed4",
|
||||
"parent_id": "KG-WP-0001",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "workplan",
|
||||
"id": "KG-WP-0002",
|
||||
"status": "finished",
|
||||
"title": "Canonical immune contracts and first posture pilot",
|
||||
"source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
|
||||
"uuid": "5c5c5a26-dfca-4d42-86a7-b87877677207",
|
||||
"parent_id": null,
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "KG-WP-0002-T01",
|
||||
"status": "done",
|
||||
"title": "Task: Define canonical immune contracts",
|
||||
"source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
|
||||
"uuid": "9982a3b4-1e65-493a-9b61-322f23d4fd2d",
|
||||
"parent_id": "KG-WP-0002",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "KG-WP-0002-T02",
|
||||
"status": "done",
|
||||
"title": "Task: Write adjacent-system boundary contract",
|
||||
"source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
|
||||
"uuid": "0c44035e-b1b8-4f5d-8a6c-e6514b4bc897",
|
||||
"parent_id": "KG-WP-0002",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "KG-WP-0002-T03",
|
||||
"status": "done",
|
||||
"title": "Task: Scaffold a minimal posture loop",
|
||||
"source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
|
||||
"uuid": "c88a7da6-a9ff-4bd9-ba47-7c199321666b",
|
||||
"parent_id": "KG-WP-0002",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "task",
|
||||
"id": "KG-WP-0002-T04",
|
||||
"status": "done",
|
||||
"title": "Task: Choose and specify the first pilot lane",
|
||||
"source_path": "workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md",
|
||||
"uuid": "77e1dc69-9902-4381-8028-ce1cfac7e9d5",
|
||||
"parent_id": "KG-WP-0002",
|
||||
"extra": {}
|
||||
},
|
||||
{
|
||||
"kind": "intake",
|
||||
"id": "KG-IN-0001",
|
||||
"status": "open",
|
||||
"title": "Assent requested: Staff layer placement, control-plane vocabulary, and the posture asymmetry",
|
||||
"source_path": "intakes/intakes.md",
|
||||
"uuid": null,
|
||||
"parent_id": null,
|
||||
"extra": {
|
||||
"record": {
|
||||
"id": "KG-IN-0001",
|
||||
"kind": "intake",
|
||||
"title": "Assent requested: Staff layer placement, control-plane vocabulary, and the posture asymmetry",
|
||||
"status": "open",
|
||||
"origin": "cross-repo",
|
||||
"origin_ref": "gate-house GH-DEC-2026-001",
|
||||
"priority": "medium",
|
||||
"owner": "kings-guard",
|
||||
"requested_by": "gate-house",
|
||||
"standard": "net-kingdom/canon/standards/security-layer-model_v0.1.md",
|
||||
"description": "gate-house asks kings-guard to assent to its placement in the NetKingdom security layer model. (1) kings-guard is Staff \u2014 agentic and non-deterministic \u2014 not an Engine. Acting at runtime does not make a repository an Engine; being agentic makes it Staff. (2) Consequently its self-description as an adaptive security control plane needs revisiting: control plane is Engine-layer vocabulary (standard section 8). This is not a demotion \u2014 it is the reason kings-guard may contain a threat only by calling an engine, never by reaching into OpenBao or a cluster directly (the binding rule, standard section 5: Staff never touches Tooling directly). (3) The posture contract with gate-house and its asymmetry: adaptive systems may reduce authority, require step-up, or request containment; they must never probabilistically manufacture additional authority. kings-guard publishes posture, gate-house defines its authority meaning, access-engine renders it. If the binding rule is impractical for containment in a real incident, say so \u2014 that is exactly the kind of finding that should change the doctrine rather than be worked around.",
|
||||
"created": "2026-08-28T19:30:17.201213Z",
|
||||
"updated": "2026-08-28T19:30:17.201213Z"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"events": [
|
||||
{
|
||||
"type": "repo.command.applied",
|
||||
"command": "repo.work.create_intake",
|
||||
"operation": "create",
|
||||
"correlation_id": "f9b8b130-71f6-41b9-9f06-e28d2abda2d4",
|
||||
"kind": "intake",
|
||||
"id": "KG-IN-0001",
|
||||
"git_sha": "7c8ef38ee0603c4ca23e69abaff689b86da752b4",
|
||||
"files_touched": [
|
||||
"intakes/intakes.md"
|
||||
],
|
||||
"source": "repo-manager",
|
||||
"emitted_at": "2026-08-28T19:30:17.391507Z"
|
||||
}
|
||||
]
|
||||
}
|
||||
11
AGENTS.md
11
AGENTS.md
|
|
@ -2,7 +2,12 @@
|
|||
|
||||
## Repo Identity
|
||||
|
||||
**Purpose:** Adaptive immune security control plane for complex multi-tenant cloud environments.
|
||||
**Purpose:** Adaptive immune defence for complex multi-tenant cloud environments.
|
||||
|
||||
**Layer:** Staff (NetKingdom Security Layer Model v0.1). Never open a direct
|
||||
client for a Tooling-layer system (OpenBao, key-cape components, a database, a
|
||||
cluster); route every such need through the owning engine and record the gap in
|
||||
`INTENT.md`. Never render or cache an authorization decision.
|
||||
|
||||
**Domain:** infotech
|
||||
**Repo slug:** kings-guard
|
||||
|
|
@ -120,8 +125,8 @@ curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
|
|||
## Repo-Specific Notes
|
||||
|
||||
This repo is no longer docs-only. It now has a **small Python 3.12 scaffold**
|
||||
for contract modeling and posture evaluation, but it is still **not** a
|
||||
long-running control-plane service.
|
||||
for contract modeling and posture evaluation. It is a Staff-layer repository:
|
||||
not a long-running enforcement service, and not a control plane.
|
||||
|
||||
## Working Set
|
||||
|
||||
|
|
|
|||
68
INTENT.md
68
INTENT.md
|
|
@ -1,19 +1,28 @@
|
|||
# INTENT
|
||||
|
||||
> **NetKingdom layering review — 2026-08-28.** This repository's role was reviewed
|
||||
> against the NetKingdom IT-security layer model: **Taxonomy → Tooling → Engines →
|
||||
> Staff**, layered by determinism and by the kind of artifact each layer produces.
|
||||
> Findings and the argument behind them:
|
||||
> `gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md`.
|
||||
> The model is `net-kingdom/canon/standards/security-layer-model_v0.1.md` (proposed),
|
||||
> ratified by `gate-house/decisions/decisions.md` GH-DEC-2026-001.
|
||||
> **Layer: Staff.** *(NetKingdom Security Layer Model v0.1, §4 catalog —
|
||||
> `net-kingdom/canon/standards/security-layer-model_v0.1.md`; ratified by
|
||||
> `gate-house/decisions/decisions.md` GH-DEC-2026-001; assented here by
|
||||
> `decisions/decisions.md` KG-DEC-2026-001 on 2026-08-28.)*
|
||||
>
|
||||
> The layer rule that binds every repository: **Staff never touches tooling
|
||||
> directly. It acts only through engine APIs.**
|
||||
> kings-guard is **interactive and non-deterministic**: adaptive defence,
|
||||
> observation, containment. Acting at runtime does not make a repository an
|
||||
> Engine; being agentic makes it Staff.
|
||||
>
|
||||
> **This repository is Staff — interactive, non-deterministic; adaptive defence.** Add the layer label. The self-description **"adaptive security control plane"** needs revisiting: control-plane vocabulary belongs to the Engine layer, and kings-guard is agentic and therefore Staff. This is not a demotion — it is the reason kings-guard may contain a threat only by calling an engine, never by reaching into OpenBao or a cluster directly. Also state the posture contract with gate-house and its asymmetry: **adaptive systems may reduce authority, require step-up, or request containment; they must never probabilistically manufacture additional authority.**
|
||||
> **The binding rule (§5): Staff never touches Tooling directly. It acts only
|
||||
> through Engine APIs.** kings-guard holds no direct client for a Tooling-layer
|
||||
> system — no database connection, no OpenBao client, no cluster mutation. It
|
||||
> may contain a threat only by calling an engine. Where no engine exposes a
|
||||
> capability kings-guard needs, that is raised as an **engine gap**, never
|
||||
> solved locally; the open gaps are listed under *System boundary* below.
|
||||
>
|
||||
> *This note records what should change. The body below is not yet adapted.*
|
||||
> **Posture contract.** kings-guard **publishes** posture; `gate-house` defines
|
||||
> its authority meaning; `access-engine` renders it. Posture is not a privilege
|
||||
> source. The asymmetry is absolute: kings-guard may **reduce** authority,
|
||||
> **require step-up**, or **request containment**; it MUST NOT probabilistically
|
||||
> manufacture additional authority. Every effector request it emits therefore
|
||||
> carries an explicit authority boundary and is advisory unless the owning
|
||||
> system has already delegated a narrow, deterministic action lane.
|
||||
|
||||
> This file captures **why this repository exists**, the **direction it is
|
||||
> moving toward**, and the **kind of system it is meant to become**.
|
||||
|
|
@ -24,9 +33,14 @@
|
|||
|
||||
## One-liner
|
||||
|
||||
**Recursive adaptive security control plane for complex cloud environments: it
|
||||
declares healthy intent, detects harmful deviation, contains damage locally,
|
||||
restores known-good operation, and retains governed defensive memory.**
|
||||
**Recursive adaptive defence for complex cloud environments: it declares
|
||||
healthy intent, detects harmful deviation, requests bounded containment through
|
||||
the owning engines, helps restore known-good operation, and retains governed
|
||||
defensive memory.**
|
||||
|
||||
*"Control plane" is Engine-layer vocabulary (layer model §8) and is no longer
|
||||
used here for kings-guard. kings-guard judges and proposes; engines decide and
|
||||
act.*
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -116,13 +130,31 @@ Kings Guard owns the **adaptive security assessment and response layer**.
|
|||
|
||||
| Concern | Primary owner | Kings Guard responsibility |
|
||||
| --- | --- | --- |
|
||||
| Identity, authentication, MFA, and verified claims | `key-cape` and related IAM systems | Consume identity and attestation as security inputs; do not replace identity. |
|
||||
| Resource authorization and decision logs | `flex-auth` | Contribute posture and risk context; do not become the authorization control plane. |
|
||||
| Secret custody, delivery, leases, and rotation | `railiance-platform` and `secrets-engine` | Consume secret-access evidence and drive defensive posture; do not hold raw secret authority. |
|
||||
| Identity, authentication, MFA, and verified claims | `key-cape` (Tooling) | Consume identity and attestation as security inputs — **through `user-engine` / `access-engine`, never by connecting to key-cape's components**; do not replace identity. |
|
||||
| Resource authorization and decision logs | `access-engine` (currently named `flex-auth`) | Contribute posture and risk context; never render or cache an authorization decision — it is the estate's only decision point (layer model §6). |
|
||||
| Secret custody, delivery, leases, and rotation | OpenBao (Tooling), fronted by `secrets-engine` (Engine) | Consume secret-access evidence **through `secrets-engine`**, never through an OpenBao client; do not hold raw secret authority. |
|
||||
| Operational SSH certificate issuance and access routing | `ops-warden` | Supply posture, evidence, or future response hooks; do not become the SSH issuing lane. |
|
||||
| Infrastructure, runtime, and platform execution | Railiance repos and workload operators | Signal constraints, isolation, and reconstitution needs; do not own deployment mechanics. |
|
||||
| Workstream and task coordination | `state-hub` | Emit non-secret evidence and integration events where appropriate; do not become a work tracker. |
|
||||
|
||||
#### Declared engine gaps
|
||||
|
||||
Capabilities kings-guard needs that no engine exposes today. Under the binding
|
||||
rule these are gaps to close in the owning engine, not work to route around.
|
||||
None is a standing licence to reach into Tooling.
|
||||
|
||||
| Gap | Needed for | Owning engine | Status |
|
||||
| --- | --- | --- | --- |
|
||||
| Authentication and assurance evidence (token assurance, attestation outcomes, authentication anomalies) exposed as an engine surface | identity-drift posture | `user-engine` / `access-engine` | open — no engine surface; kings-guard consumes fixtures only |
|
||||
| Secret-use evidence (lease, revocation, mount and rotation metadata) exposed as an engine surface | secret-abuse posture | `secrets-engine` | open — no engine surface; kings-guard consumes fixtures only |
|
||||
| A containment surface — reduce authority, require step-up, isolate a workload — callable as a deterministic engine API, and available while an incident is in progress | bounded response | `access-engine`, runtime engines | open — see KG-DEC-2026-001 §Finding |
|
||||
|
||||
Until a gap closes, the corresponding posture lane stays advisory and
|
||||
fixture-driven. kings-guard MUST NOT open a direct path to the Tooling system
|
||||
to fill one. If diagnostic read-only observation of Tooling ever becomes
|
||||
unavoidable, the layer model requires it to be declared in this file and
|
||||
treated as a gap to close; **no such observation is declared today.**
|
||||
|
||||
---
|
||||
|
||||
## Design Principles
|
||||
|
|
@ -171,7 +203,7 @@ mandatory product stack.
|
|||
|
||||
Kings Guard is:
|
||||
|
||||
- an adaptive security control-plane concept and implementation home;
|
||||
- an adaptive defence concept and implementation home, in the Staff layer;
|
||||
- a contract layer for healthy intent, observations, signals, posture, and
|
||||
effectors;
|
||||
- a coordination system for detection, containment, recovery, and memory;
|
||||
|
|
|
|||
|
|
@ -3,6 +3,10 @@
|
|||
Adaptive security contracts and posture-evaluation scaffold for NetKingdom's
|
||||
immune-architecture work.
|
||||
|
||||
**Layer: Staff** (NetKingdom Security Layer Model v0.1). kings-guard publishes
|
||||
posture and requests bounded response through engine APIs; it never touches
|
||||
Tooling directly and never renders an authorization decision.
|
||||
|
||||
## Current slice
|
||||
|
||||
This repository now contains four aligned pieces:
|
||||
|
|
@ -12,8 +16,8 @@ This repository now contains four aligned pieces:
|
|||
- `specs/ImmuneContracts.md` for the first canonical contract layer
|
||||
- `src/kings_guard/` plus `tests/` for a minimal posture loop scaffold
|
||||
|
||||
The current implementation is intentionally narrow. It does **not** provide a
|
||||
running security control plane yet. It provides:
|
||||
The current implementation is intentionally narrow. It does **not** enforce
|
||||
anything. It provides:
|
||||
|
||||
- typed contracts for security genome, phenotype, observation, posture,
|
||||
signal, effector request, and immune memory entry;
|
||||
|
|
|
|||
19
SCOPE.md
19
SCOPE.md
|
|
@ -4,6 +4,15 @@
|
|||
|
||||
---
|
||||
|
||||
## Layer
|
||||
|
||||
**Staff** — interactive, non-deterministic; adaptive defence, observation,
|
||||
containment. Binding rule: kings-guard never touches Tooling directly; it acts
|
||||
only through Engine APIs. See `INTENT.md` and
|
||||
`net-kingdom/canon/standards/security-layer-model_v0.1.md`.
|
||||
|
||||
---
|
||||
|
||||
## One-liner
|
||||
|
||||
Adaptive security assessment and bounded-response layer for multi-tenant cloud
|
||||
|
|
@ -38,6 +47,12 @@ without replacing those systems' primary authority.
|
|||
## Out of Scope
|
||||
|
||||
- Identity issuance, login, MFA, or token minting.
|
||||
- Any direct client for a Tooling-layer system (OpenBao, key-cape components,
|
||||
a database, a cluster) — every such need routes through the owning engine.
|
||||
- Rendering or caching an authorization decision; `access-engine` is the
|
||||
estate's only decision point.
|
||||
- "Control plane" as a self-description — that vocabulary belongs to the
|
||||
Engine layer.
|
||||
- Authorization policy administration or final resource allow/deny decisions.
|
||||
- Secret custody, lease issuance, or raw secret-value delivery.
|
||||
- Infrastructure provisioning, workload deployment, or cluster/platform
|
||||
|
|
@ -55,8 +70,8 @@ without replacing those systems' primary authority.
|
|||
- A minimal Python reference scaffold exists under `src/kings_guard/` with
|
||||
fixture-driven tests under `tests/`.
|
||||
- The implementation currently evaluates normalized observations and emits
|
||||
posture/signal results for one bounded pilot lane; it is not yet a running
|
||||
control plane or integrated enforcement service.
|
||||
posture/signal results for one bounded pilot lane; it is not an enforcement
|
||||
service and will not become one.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
152
decisions/decisions.md
Normal file
152
decisions/decisions.md
Normal file
|
|
@ -0,0 +1,152 @@
|
|||
# Decision records
|
||||
|
||||
## KG-DEC-2026-001 — Assent to Staff placement, release of control-plane vocabulary, and the posture asymmetry
|
||||
|
||||
```yaml
|
||||
id: KG-DEC-2026-001
|
||||
kind: decision
|
||||
title: Assent to Staff placement, release of control-plane vocabulary, and the posture
|
||||
asymmetry
|
||||
status: resolved
|
||||
owner: Bernd Worsch
|
||||
repo: kings-guard
|
||||
standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
|
||||
origin_ref: KG-IN-0001
|
||||
related:
|
||||
- gate-house/decisions/decisions.md GH-DEC-2026-001
|
||||
- gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md
|
||||
affects:
|
||||
- kings-guard
|
||||
- gate-house
|
||||
- net-kingdom
|
||||
- access-engine
|
||||
- secrets-engine
|
||||
- user-engine
|
||||
created: '2026-08-28'
|
||||
updated: '2026-08-28'
|
||||
decided_by: Bernd Worsch
|
||||
disposition: assent-with-finding
|
||||
```
|
||||
|
||||
## Context
|
||||
|
||||
`gate-house` raised intake `KG-IN-0001` asking `kings-guard` to assent to its
|
||||
placement in the NetKingdom Security Layer Model v0.1: Staff, not Engine; the
|
||||
release of "control plane" as a self-description; and the posture contract with
|
||||
its asymmetry. The request explicitly invited challenge to §5 — the binding
|
||||
rule — if routing containment through engine APIs proves impractical in a real
|
||||
incident.
|
||||
|
||||
## Decision
|
||||
|
||||
**Assent to all three points, with one finding against §5 that gate-house
|
||||
should rule on.**
|
||||
|
||||
### 1. Staff placement — assented
|
||||
|
||||
kings-guard is agentic and non-deterministic. Its outputs are posture
|
||||
judgments, typed signals, and bounded requests — not a deterministic result
|
||||
from an authoritative input state. It fails the Engine test in §3.3 on its
|
||||
defining property, and it fails it by design: intent-versus-behavior judgment
|
||||
is inference, and inference is not an authority. Staff is the correct layer,
|
||||
and "acting at runtime does not make a repository an Engine" resolves the only
|
||||
plausible objection kings-guard had.
|
||||
|
||||
`INTENT.md` now declares the layer.
|
||||
|
||||
### 2. Control-plane vocabulary — released
|
||||
|
||||
"Control plane" is released to the Engine layer. The one-liner, `SCOPE.md`,
|
||||
`README.md`, `AGENTS.md`, and the adjacent-system boundary have been reworded:
|
||||
kings-guard **judges and proposes; engines decide and act.**
|
||||
|
||||
We accept the framing that this is not a demotion. It is the same statement as
|
||||
the binding rule, read from the other end: a repository that may not reach into
|
||||
OpenBao or a cluster directly has no plane to control, and saying so plainly
|
||||
removes an overlap that was invisible in this repo's own documents.
|
||||
|
||||
Residual: `specs/NetKingdomImmuneArchitecture.md` uses "control plane" in
|
||||
several places describing an estate-wide arrangement of deterministic
|
||||
authorities. A layer note now scopes those readings; the full sweep is handed
|
||||
off as intake **KG-IN-0002**.
|
||||
|
||||
### 3. Posture contract and asymmetry — assented, and already implemented
|
||||
|
||||
kings-guard **publishes** posture; gate-house defines its authority meaning;
|
||||
access-engine renders it. Posture is not a privilege source.
|
||||
|
||||
The asymmetry — reduce authority, require step-up, request containment; never
|
||||
probabilistically manufacture additional authority — is adopted as an invariant
|
||||
of this repository, and the scaffold already satisfies it: every
|
||||
`EffectorRequest` carries an explicit `authority_boundary`, and the values in
|
||||
use are `advisory_only` and `metadata_only`. No code path widens authority.
|
||||
|
||||
### Conformance at time of assent
|
||||
|
||||
Per layer model §10, checked and clean:
|
||||
|
||||
- `pyproject.toml` declares **zero runtime dependencies** — no database driver,
|
||||
no OpenBao client, no cluster client. §5 holds mechanically.
|
||||
- No module exposes an authorization decision surface. §6 holds.
|
||||
- No read-only Tooling observation is claimed, so §5's declared-exception path
|
||||
is unused.
|
||||
|
||||
## Finding — §5 is right, and currently undischargeable for containment
|
||||
|
||||
gate-house asked whether the binding rule is impractical for containment during
|
||||
a real incident. Our answer is **no — do not weaken it** — but the rule has a
|
||||
consequence the standard does not yet state.
|
||||
|
||||
**Do not weaken it.** The three obvious pressures do not survive examination:
|
||||
|
||||
- *Latency.* The asymmetry means kings-guard's only available actions point in
|
||||
the safe direction. A slow authority-reducing call is a slow safe action, not
|
||||
a dangerous one. Latency is not a reason to bypass an engine.
|
||||
- *Blast radius.* A direct path is wider than an engine call, not narrower.
|
||||
The engine is what bounds the radius.
|
||||
- *Engine unavailable.* This is the real pressure, and it is exactly where a
|
||||
break-glass path is most dangerous. An incident is when an attacker most
|
||||
wants the shortcut, and a containment path that bypasses the decision point
|
||||
is an authority path in the other direction the moment it is subverted. It
|
||||
is the "small convenience" §6 names. We do not want it, and we ask that
|
||||
gate-house not grant it to us.
|
||||
|
||||
**But:** §4 catalogs kings-guard as owning "adaptive defence, observation,
|
||||
**containment**", while **no engine exposes a containment surface today** —
|
||||
nothing to reduce authority, require step-up, or isolate a workload as a
|
||||
deterministic API. Under §5, correctly obeyed, kings-guard's containment
|
||||
capability is therefore not degraded but **zero**. The charter in §4 and the
|
||||
rule in §5 are consistent in principle and unsatisfiable together in practice
|
||||
until that engine surface exists.
|
||||
|
||||
Two requests to gate-house, either of which resolves it:
|
||||
|
||||
1. **Rule that a containment capability MUST be engine-exposed before a Staff
|
||||
repository may be catalogued as owning containment** — so that §4 does not
|
||||
assign a responsibility §5 forbids discharging. Alternatively, mark
|
||||
kings-guard's containment claim as pending the engine gap.
|
||||
2. **Rule that the degraded-mode fallback belongs inside the engine, not in
|
||||
Staff.** If containment must survive partial failure, the deterministic
|
||||
"fail to reduced authority" default belongs to `access-engine`, applied when
|
||||
it cannot reach its own inputs. That keeps the decision at the decision
|
||||
point and keeps the fallback deterministic, which a Staff-layer fallback
|
||||
could never be.
|
||||
|
||||
The three open engine gaps — authentication/assurance evidence, secret-use
|
||||
evidence, and the containment surface — are recorded in `INTENT.md` under
|
||||
*Declared engine gaps*. Until they close, the corresponding posture lanes stay
|
||||
advisory and fixture-driven, which is the honest state and not a workaround.
|
||||
|
||||
## Consequences
|
||||
|
||||
- kings-guard declares Staff in `INTENT.md` and stops describing itself as a
|
||||
control plane.
|
||||
- Evidence from `key-cape` and OpenBao is routed through `user-engine` /
|
||||
`access-engine` and `secrets-engine` respectively; the boundary document no
|
||||
longer implies a direct read.
|
||||
- The `qonto-assistant` pilot is confirmed as the layer-clean lane: it needs no
|
||||
Tooling client, because the assistant publishes its own genome and audit
|
||||
stream.
|
||||
- kings-guard's assent removes one of the two adaptations §11 lists as
|
||||
outstanding. The standard remains proposed pending `flex-auth` and
|
||||
`ops-warden`.
|
||||
|
|
@ -30,17 +30,24 @@ The following rules apply to every integration below:
|
|||
advisory unless the owning system already delegates a narrow action lane.
|
||||
4. `kings-guard` must preserve **tenant isolation**: any retained evidence or
|
||||
memory must stay bounded by declared confidentiality rules.
|
||||
5. `kings-guard` is a **Staff-layer** repository and is bound by §5 of the
|
||||
NetKingdom Security Layer Model v0.1: it never holds a direct client for a
|
||||
Tooling-layer system. Evidence from Tooling (OpenBao, key-cape components)
|
||||
is consumed **through the owning engine**. Where no engine surface exists,
|
||||
the lane stays fixture-driven and the gap is declared in `INTENT.md`.
|
||||
6. `kings-guard` never renders or caches an authorization decision.
|
||||
`access-engine` is the estate's only decision point (layer model §6).
|
||||
|
||||
## 3. System-by-System Boundary
|
||||
|
||||
| Adjacent system | Primary authority | Evidence consumed by `kings-guard` | Signals returned by `kings-guard` | Non-goals |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `key-cape` | verified identity, login, MFA, assurance claims | token assurance level, attestation outcomes, claim provenance, authentication anomalies | posture hints about assurance drift or identity inconsistency | minting tokens, login flow, MFA lifecycle |
|
||||
| `flex-auth` | resource authorization policy, decision logs, protected-system registry | live allow/deny decisions, decision explanations, policy version, decision-rate anomalies | risk context or posture hints that a protected system may choose to include in an auth check | becoming the PDP, registering resources, final allow/deny |
|
||||
| `key-cape` **(Tooling — reach via `user-engine` / `access-engine`)** | verified identity, login, MFA, assurance claims | token assurance level, attestation outcomes, claim provenance, authentication anomalies | posture hints about assurance drift or identity inconsistency | minting tokens, login flow, MFA lifecycle |
|
||||
| `access-engine` (currently `flex-auth`) | resource authorization policy, decision logs, protected-system registry | live allow/deny decisions, decision explanations, policy version, decision-rate anomalies | risk context or posture hints that a protected system may choose to include in an auth check | becoming the PDP, registering resources, final allow/deny |
|
||||
| `secrets-engine` | approved secret workflow and scoped capability delivery | metadata-only records of reads, leases, deliveries, rotations, revocations | posture hints about abnormal secret-use patterns or repeated denied delivery attempts | holding secret values, issuing leases, bypassing approval |
|
||||
| `railiance-platform` / OpenBao | runtime secret custody, secret engines, dynamic credentials | engine/mount metadata, lease/revocation evidence, platform-secret posture | posture hints for secret-authority consumers or operators | root-token custody, secret-engine configuration ownership |
|
||||
| OpenBao **(Tooling — reach via `secrets-engine`)** | runtime secret custody, secret engines, dynamic credentials | engine/mount metadata, lease/revocation evidence, platform-secret posture | posture hints for secret-authority consumers or operators | root-token custody, secret-engine configuration ownership |
|
||||
| `ops-warden` | operational SSH certificate issuance and routing guidance | signing attempts, TTL/principal anomalies, access-routing misuse evidence | sign-request posture hints, actor-scrutiny hints, metadata-only evidence requests | issuing certificates, routing non-SSH credentials, host trust config |
|
||||
| Railiance runtime layers | provisioning, deployment, isolation, workload lifecycle | deployment provenance, runtime health, workload/network/storage events, recovery outcomes | bounded requests for isolate, rebuild, or validate, always within the runtime's own authority | becoming the deployment repo or cluster operator |
|
||||
| Railiance runtime layers **(reach via the owning engine)** | provisioning, deployment, isolation, workload lifecycle | deployment provenance, runtime health, workload/network/storage events, recovery outcomes | bounded requests for isolate, rebuild, or validate, always within the runtime's own authority | becoming the deployment repo or cluster operator |
|
||||
| Governed domain assistants (example: `qonto-assistant`) | service-local business logic, service-local fast loops, customer/domain-facing policy enforcement points | audit events, policy denies, local safety loop outcomes, service-owned genome records | service-local posture hints and metadata-only evidence requests | replacing local policy kernels or business logic |
|
||||
| `state-hub` | live coordination state and work-record indexing | repo/workplan/task/progress metadata, incident references | non-secret progress events, posture evidence, incident notes | becoming canon, storing secret payloads, driving irreversible response |
|
||||
|
||||
|
|
@ -54,7 +61,7 @@ explicitly in the boundary model:
|
|||
- and it already emits an audit stream and operates a local fast loop.
|
||||
|
||||
That class of system is not identical to a generic workload behind
|
||||
`flex-auth`, and it is not an infrastructure control plane either.
|
||||
`access-engine`, and it is not infrastructure either.
|
||||
|
||||
`kings-guard`'s relationship to this class is:
|
||||
|
||||
|
|
@ -75,3 +82,19 @@ pattern:
|
|||
control paths
|
||||
|
||||
See `docs/pilots/QontoAssistantPosturePilot.md`.
|
||||
|
||||
The pilot lane is chosen partly *because* it is layer-clean: `qonto-assistant`
|
||||
publishes its own audit stream and genome record, so kings-guard needs no
|
||||
Tooling client to run it. The `key-cape`, OpenBao and runtime rows above stay
|
||||
fixture-driven until the engine surfaces named in `INTENT.md` §*Declared engine
|
||||
gaps* exist.
|
||||
|
||||
## 6. Layer conformance
|
||||
|
||||
Mechanically checkable, per layer model §10:
|
||||
|
||||
- `pyproject.toml` declares **zero runtime dependencies** — no database driver,
|
||||
no OpenBao client, no Kubernetes client;
|
||||
- every `EffectorRequest` carries an explicit `authority_boundary`, and the
|
||||
values in use are `advisory_only` and `metadata_only`;
|
||||
- no module exposes an authorization decision surface.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,9 @@ id: KG-IN-0001
|
|||
kind: intake
|
||||
title: 'Assent requested: Staff layer placement, control-plane vocabulary, and the
|
||||
posture asymmetry'
|
||||
status: open
|
||||
status: closed
|
||||
outcome: absorbed
|
||||
promoted_to: KG-DEC-2026-001
|
||||
origin: cross-repo
|
||||
origin_ref: gate-house GH-DEC-2026-001
|
||||
priority: medium
|
||||
|
|
@ -30,4 +32,38 @@ description: 'gate-house asks kings-guard to assent to its placement in the NetK
|
|||
that should change the doctrine rather than be worked around.'
|
||||
created: '2026-08-28T19:30:17.201213Z'
|
||||
updated: '2026-08-28T19:30:17.201213Z'
|
||||
closed: '2026-08-28'
|
||||
resolution: 'Assent with finding. All three points assented and adopted in
|
||||
INTENT.md, SCOPE.md, README.md, AGENTS.md, and docs/AdjacentSystemBoundary.md.
|
||||
The invited challenge to the binding rule was taken up and answered: do not
|
||||
weaken section 5 — but section 4 catalogs kings-guard as owning containment
|
||||
while no engine exposes a containment surface, so the charter is currently
|
||||
undischargeable. Two rulings requested of gate-house. Full record:
|
||||
decisions/decisions.md KG-DEC-2026-001. Vocabulary sweep of the architecture
|
||||
spec handed off as KG-IN-0002.'
|
||||
```
|
||||
|
||||
## KG-IN-0002 — Sweep "control plane" and layer vocabulary through NetKingdomImmuneArchitecture.md
|
||||
|
||||
```yaml
|
||||
id: KG-IN-0002
|
||||
kind: intake
|
||||
title: Sweep "control plane" and layer vocabulary through NetKingdomImmuneArchitecture.md
|
||||
status: open
|
||||
origin: residual
|
||||
origin_ref: KG-DEC-2026-001
|
||||
priority: low
|
||||
owner: kings-guard
|
||||
standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
|
||||
description: 'specs/NetKingdomImmuneArchitecture.md (approx. 1900 lines) predates the
|
||||
NetKingdom Security Layer Model and uses "control plane" in several places —
|
||||
including a "Platform Immune Control Plane" subgraph — where the layer model
|
||||
reserves that vocabulary for the Engine layer. A scoping note now sits at the head
|
||||
of the document so no reading takes it as a kings-guard self-description, but the
|
||||
body is not adapted. Sweep it: separate the components that are engine-layer
|
||||
authorities from the observation-and-judgment surface kings-guard actually owns,
|
||||
and check that no part of the architecture places a decision point in Staff
|
||||
(layer model section 6).'
|
||||
created: '2026-08-28'
|
||||
updated: '2026-08-28'
|
||||
```
|
||||
|
|
|
|||
|
|
@ -14,6 +14,16 @@ classification: Public
|
|||
|
||||
# NetKingdom Immune Architecture
|
||||
|
||||
> **Layer note (2026-08-28).** kings-guard is a **Staff**-layer repository
|
||||
> under the NetKingdom Security Layer Model v0.1 (assented in
|
||||
> `decisions/decisions.md` KG-DEC-2026-001). Where this document uses "control
|
||||
> plane", read it as naming an **estate-wide, Engine-layer** arrangement of
|
||||
> deterministic authorities — never as a self-description of `kings-guard`,
|
||||
> which publishes posture and requests bounded response through engine APIs.
|
||||
> The parts of this architecture that render decisions or hold state belong to
|
||||
> engines; kings-guard owns observation, judgment, and the request. A full
|
||||
> vocabulary sweep of this document is tracked as intake KG-IN-0002.
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This document defines the reference architecture for **Kings Guard Security**, implemented in the `kings-guard` repository and positioned within the wider **NetKingdom** ecosystem.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue