diff --git a/.repo-manager/index.json b/.repo-manager/index.json new file mode 100644 index 0000000..4e2adfe --- /dev/null +++ b/.repo-manager/index.json @@ -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" + } + ] +} diff --git a/AGENTS.md b/AGENTS.md index 48256dc..2a64208 100644 --- a/AGENTS.md +++ b/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/" \ ## 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 diff --git a/INTENT.md b/INTENT.md index 02acec6..7107e9e 100644 --- a/INTENT.md +++ b/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; diff --git a/README.md b/README.md index e8bb048..2f743fc 100644 --- a/README.md +++ b/README.md @@ -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; diff --git a/SCOPE.md b/SCOPE.md index 6a5f839..f0be1c2 100644 --- a/SCOPE.md +++ b/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. --- diff --git a/decisions/decisions.md b/decisions/decisions.md new file mode 100644 index 0000000..ff1c5ef --- /dev/null +++ b/decisions/decisions.md @@ -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`. diff --git a/docs/AdjacentSystemBoundary.md b/docs/AdjacentSystemBoundary.md index 240f934..180c24b 100644 --- a/docs/AdjacentSystemBoundary.md +++ b/docs/AdjacentSystemBoundary.md @@ -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. diff --git a/intakes/intakes.md b/intakes/intakes.md index 4a15a2a..e13eea7 100644 --- a/intakes/intakes.md +++ b/intakes/intakes.md @@ -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' ``` diff --git a/specs/NetKingdomImmuneArchitecture.md b/specs/NetKingdomImmuneArchitecture.md index 8628200..85ecc53 100755 --- a/specs/NetKingdomImmuneArchitecture.md +++ b/specs/NetKingdomImmuneArchitecture.md @@ -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.