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

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;