diff --git a/.repo-manager/index.json b/.repo-manager/index.json deleted file mode 100644 index 4e2adfe..0000000 --- a/.repo-manager/index.json +++ /dev/null @@ -1,149 +0,0 @@ -{ - "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 2a64208..48256dc 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -2,12 +2,7 @@ ## Repo Identity -**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. +**Purpose:** Adaptive immune security control plane for complex multi-tenant cloud environments. **Domain:** infotech **Repo slug:** kings-guard @@ -125,8 +120,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. It is a Staff-layer repository: -not a long-running enforcement service, and not a control plane. +for contract modeling and posture evaluation, but it is still **not** a +long-running control-plane service. ## Working Set diff --git a/INTENT.md b/INTENT.md index 7107e9e..02acec6 100644 --- a/INTENT.md +++ b/INTENT.md @@ -1,28 +1,19 @@ # INTENT -> **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.)* +> **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. > -> 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. +> The layer rule that binds every repository: **Staff never touches tooling +> directly. It acts only through engine APIs.** > -> **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 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.** > -> **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 note records what should change. The body below is not yet adapted.* > This file captures **why this repository exists**, the **direction it is > moving toward**, and the **kind of system it is meant to become**. @@ -33,14 +24,9 @@ ## One-liner -**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.* +**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.** --- @@ -130,31 +116,13 @@ Kings Guard owns the **adaptive security assessment and response layer**. | Concern | Primary owner | Kings Guard responsibility | | --- | --- | --- | -| 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. | +| 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. | | 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 @@ -203,7 +171,7 @@ mandatory product stack. Kings Guard is: -- an adaptive defence concept and implementation home, in the Staff layer; +- an adaptive security control-plane concept and implementation home; - 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 2f743fc..e8bb048 100644 --- a/README.md +++ b/README.md @@ -3,10 +3,6 @@ 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: @@ -16,8 +12,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** enforce -anything. It provides: +The current implementation is intentionally narrow. It does **not** provide a +running security control plane yet. 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 f0be1c2..6a5f839 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -4,15 +4,6 @@ --- -## 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 @@ -47,12 +38,6 @@ 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 @@ -70,8 +55,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 an enforcement - service and will not become one. + posture/signal results for one bounded pilot lane; it is not yet a running + control plane or integrated enforcement service. --- diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index e7a0e25..1618f86 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -17,4 +17,3 @@ | task | KG-WP-0002-T02 | done | — | workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md | | task | KG-WP-0002-T03 | done | — | workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md | | task | KG-WP-0002-T04 | done | — | workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md | -| intake | KG-IN-0001 | open | — | intakes/intakes.md | diff --git a/decisions/decisions.md b/decisions/decisions.md deleted file mode 100644 index ff1c5ef..0000000 --- a/decisions/decisions.md +++ /dev/null @@ -1,152 +0,0 @@ -# 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 180c24b..240f934 100644 --- a/docs/AdjacentSystemBoundary.md +++ b/docs/AdjacentSystemBoundary.md @@ -30,24 +30,17 @@ 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` **(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 | +| `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 | | `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 | -| 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 | +| `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 | | `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 **(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 | +| 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 | | 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 | @@ -61,7 +54,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 -`access-engine`, and it is not infrastructure either. +`flex-auth`, and it is not an infrastructure control plane either. `kings-guard`'s relationship to this class is: @@ -82,19 +75,3 @@ 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 e13eea7..4a15a2a 100644 --- a/intakes/intakes.md +++ b/intakes/intakes.md @@ -7,9 +7,7 @@ id: KG-IN-0001 kind: intake title: 'Assent requested: Staff layer placement, control-plane vocabulary, and the posture asymmetry' -status: closed -outcome: absorbed -promoted_to: KG-DEC-2026-001 +status: open origin: cross-repo origin_ref: gate-house GH-DEC-2026-001 priority: medium @@ -32,38 +30,4 @@ 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 85ecc53..8628200 100755 --- a/specs/NetKingdomImmuneArchitecture.md +++ b/specs/NetKingdomImmuneArchitecture.md @@ -14,16 +14,6 @@ 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.