kings-guard/INTENT.md

---
# NetKingdom security layer declaration (statute §11, companion §2).
# Machine-readable form; the prose below is the same claim in our own voice.
# Full contact map and gap records: layer.yaml
layer: Staff
role: null                     # Engines only
standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
standard_version: "0.7"
declared_by: decisions/decisions.md#KG-DEC-2026-001
declared_at: "2026-08-29"
conformance_state: blocked-clean
principal_kinds: [human, agent]
---

# INTENT

> **Layer: Staff.** *(NetKingdom Security Layer Model
> `net-kingdom/canon/standards/security-layer-model_v0.7.md`, **accepted**, §4
> catalog; working form: `net-kingdom/SECURITY-COMPANION.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, against v0.1.)*
>
> **The declaration is the frontmatter above plus `layer.yaml`**, checked by
> `scripts/check_layer_conformance.py` and tested in
> `tests/test_layer_conformance.py`. Prose cannot distinguish a declaration from
> a transcribed review, so those are authoritative and this note is commentary
> in kings-guard's own voice, as the companion asks.
>
> **Catalog entry (v0.7 §4):** adaptive defence and judgment; observation of
> Staff-reachable sources — identity and secret observation **pending**;
> **proposes** containment, which it does not own.
>
> kings-guard is **interactive and non-deterministic**. Acting at runtime does
> not make a repository an Engine; being agentic makes it Staff.
>
> **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, and
> no §5.1 diagnostic read or §5.2 conduit either. Under §11 that is
> **blocked-clean**: the capabilities needing such a contact sit at zero rather
> than being taken locally, and §11 rules that this MUST NOT rank below
> conforming.
>
> **Containment is not ours (§9.2).** v0.6 moved it off this repository
> entirely: reduce authority, require step-up, and isolate a workload are
> authority-changing operations, so they are rendered by an Engine and enforced
> by a PEP. **kings-guard proposes containment; it never performs it.** The
> actuation surface is unowned and held at zero estate-wide, so no argument
> anywhere may assume containment is automatic.
>
> **The agent principal (§3.4).** kings-guard is Staff of the agentic kind, and
> v0.7 binds that principal with four rules this repository offered to accept
> before they were written. They are adopted here as repository invariants:
> **no standing credential** — authority is per task, time-bounded, attributable
> to the principal acted for; **tool use is a §5.2 conduit or an Engine API, and
> there is no third route** — a callable tool means the operation exists, not
> that this actor may invoke it; **agent memory is not a state plane** — immune
> memory, tool-call traces and prompt caches are kings-guard's own and MUST NOT
> become state another layer depends on at runtime unless catalogued as Tooling;
> **every action is reconstructable as the caller's**, bounded by §9.6.
>
> The third rule constrains this repository's own roadmap and is the one to
> watch: federated immune memory (*Direction of Evolution* stage 5) is exactly
> the shape that could drift into a state plane, and it may not.
>
> **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 carries an explicit
> authority boundary. Under incomplete observation this asymmetry is what bounds
> the damage: a suppressed event can only cost a tightening that should have
> happened, never manufacture authority through us (§8, §9.6).

> This file captures **why this repository exists**, the **direction it is
> moving toward**, and the **kind of system it is meant to become**.
> It is intentionally **aspirational and stable**, not a description of
> current implementation.

---

## 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.*

---

## Why This Exists

Modern cloud environments are too dynamic to protect through identity, policy,
and perimeter rules alone.

Even when authentication, authorization, and secret custody are well designed,
the environment still changes continuously:

- workloads are rebuilt and redeployed;
- dependencies shift;
- operators, agents, and automations act with real authority;
- tenants share substrates while requiring strong isolation;
- legitimate identities can become compromised;
- harmful behavior can emerge from software that still looks formally allowed.

Security therefore needs a layer that does more than authenticate and allow.
It must continuously compare **declared healthy operation** against **observed
behavior**, decide whether the current state is acceptable, and coordinate
bounded response when it is not.

This repository exists to provide that adaptive layer.

---

## The Mission

> *Where we are going.*

Kings Guard aims to become a **recursive adaptive security system** for
multi-tenant, multi-operator, and agent-active environments.

It should make security an ongoing control loop:

```text
declare healthy intent
-> establish and attest identity
-> observe actual behavior
-> compare behavior with policy and intended scope
-> assess risk and confidence
-> respond within bounded authority
-> restore known-good operation
-> validate the outcome
-> retain governed security memory
```

The mature system should:

- model intended healthy operation explicitly;
- evaluate trust as temporary, scoped, and continuously reassessed;
- detect and contain disturbances near their origin;
- coordinate local and global defensive signals without collapsing tenant
  boundaries;
- drive reconstitution and recovery, not only alerting;
- learn from incidents without normalizing compromise or leaking sensitive
  tenant data.

---

## Responsibility Boundary

Kings Guard owns the **adaptive security assessment and response layer**.

### Kings Guard owns

- the model of healthy intent, tolerated variation, and harmful deviation;
- security phenotype assessment from observed state and behavior;
- normalized immune observations and signal contracts;
- posture assessment across compartments, subjects, and resources;
- bounded response policy for containment, inflammation, quarantine, and
  reconstitution;
- recovery validation and governed immune memory;
- coordination between local autonomous defense and broader federated defense.

### Kings Guard does not own

- primary human, workload, or device identity issuance;
- login, MFA, token minting, or directory lifecycle;
- resource authorization policy administration;
- long-lived secret custody, lease issuance, or secret value delivery;
- infrastructure provisioning, workload deployment, or platform operations;
- general work coordination, task management, or live project state.

### System boundary

| 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. |
| 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.

These are **unowned capabilities**, not §5.3 declared contacts: kings-guard
makes no direct Tooling contact for any of them. v0.5 §11 added the
**blocked-clean** state for exactly this case, on kings-guard's finding, and
ruled that it MUST NOT rank below conforming.

`layer.yaml` is the authoritative machine-readable form; this table is the
human-readable view of it.

| `capability` | Needed for | `intended_owner` | `blocked_on` | `review` |
| --- | --- | --- | --- | --- |
| Authentication and assurance evidence (token assurance, attestation outcomes, authentication anomalies) exposed as an engine surface | identity-drift posture | identity layer + `audit-core` — **`access-engine` declined** (v0.6 §13); reproposed, not assented | no engine surface exists; kings-guard consumes fixtures only | 2026-11-28 |
| Secret-use evidence (lease, revocation, mount and rotation metadata) exposed as an engine surface | secret-abuse posture | `secrets-engine` | no engine surface exists; kings-guard consumes fixtures only | 2026-11-28 |
| Actuation surface — reduce authority, require step-up, isolate a workload — as a deterministic engine API carrying a decision record | containment kings-guard **proposes but does not own** | `access-engine` + runtime PEPs; not reviewed (`FLEX-DEC-2026-002`) | ruled an Engine concept held at zero (v0.6 §9.2); recorded here as a dependency, not a kings-guard gap to close | 2026-11-28 |

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

### 1. Intent before anomaly

Security should first ask whether behavior is compatible with declared healthy
operation, not merely whether it is statistically unusual.

### 2. Trust is temporary

Trust is not a permanent property of an identity, network location, or workload.
It is a time-bound judgment derived from identity, provenance, integrity,
context, and observed behavior.

### 3. Local containment first

Defensive action should happen as close as possible to the disturbed
compartment, with wider coordination only when impact crosses boundaries.

### 4. Bounded response over uncontrolled automation

Automated response must be explicitly scoped, reversible where possible, and
governed so defense does not become its own source of harm.

### 5. Recovery is part of security

Detection without reconstitution is incomplete. The system should restore
known-good operation and verify that restoration succeeded.

### 6. Memory must be governed

The system should learn from incidents, but memory must preserve tenant
confidentiality, prevent evidence poisoning, and avoid turning compromise into
"normal" behavior.

### 7. Replaceable implementations, stable contracts

Sensors, policy engines, response effectors, and deployment substrates may
change. Kings Guard should depend on stable capability contracts rather than one
mandatory product stack.

---

## What This Is

Kings Guard is:

- 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 **proposal**, recovery, and governed memory;
- a reference architecture for recursive, compartment-aware cloud defense.

---

## What This Is Not

Kings Guard is not:

- an actuator — it proposes containment and never performs it (§9.2);
- a holder of any standing credential (§3.4 rule 1);
- a state plane for any other layer, its immune memory included (§3.4 rule 3);
- an identity provider;
- an authorization registry;
- a secret store;
- a SIEM-only alerting surface;
- a generic deployment/orchestration repository;
- a justification to weaken tenant isolation in the name of global defense.

---

## Direction of Evolution

The repository should evolve through clear layers:

1. **Canonical model:** define the stable vocabulary for security genome,
   phenotype, observation, signal, effector, tolerance, inflammation, and
   immune memory.
2. **Assessment loop:** provide a minimal service that ingests observations,
   evaluates posture against declared intent, and produces typed signals —
   against **real emitted events**, not only fixtures. §12's fourth step
   ("kings-guard observes it in operation") is staffed for the
   `qonto-assistant` audit stream. Completeness of the stream is part of
   the judgment, not an assumption about it (§9.6). The deny class still
   lacks a source-published heartbeat, so completeness is not claimed.
3. **Bounded proposal:** emit containment *requests* — isolation, throttling,
   revocation, reconstitution — as typed, authority-bounded proposals to the
   engine that renders them. kings-guard never actuates (§9.2); the actuation
   surface is an Engine concept and is unowned estate-wide. This stage is
   complete when the proposals are well-formed and reconstructable, not when
   anything is contained.
4. **Recovery and validation:** prove that known-good restoration can be
   coordinated and verified, not merely requested.
5. **Federated memory:** retain reusable defensive knowledge without exposing
   tenant-confidential operational detail — and **without becoming a state
   plane**. Under §3.4 rule 3 agent memory may not become state another layer
   depends on at runtime. Immune memory may inform kings-guard's own judgment
   and may be published as evidence; no engine, PEP, or workload may read it as
   an input it depends on. If that ever becomes desirable it is a Tooling
   catalog change under §4, not a quiet integration.

---

## Guiding Question

> **How can a cloud environment continuously distinguish healthy from harmful
> behavior, contain damage near its origin, and learn from incidents without
> centralizing too much trust or harming legitimate operation?**