kings-guard/INTENT.md

# 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.
>
> The layer rule that binds every repository: **Staff never touches tooling
> directly. It acts only through engine APIs.**
>
> **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.**
>
> *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**.
> It is intentionally **aspirational and stable**, not a description of
> current implementation.

---

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

---

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

---

## 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 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;
- a reference architecture for recursive, compartment-aware cloud defense.

---

## What This Is Not

Kings Guard is not:

- 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.
3. **Bounded response:** integrate with selected effectors for isolation,
   throttling, revocation, or reconstitution under explicit policy.
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.

---

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