kings-guard/INTENT.md

INTENT

Layer: Staff. (NetKingdom Security Layer Model — current version net-kingdom/canon/standards/security-layer-model_v0.4.md, §4 catalog, status accepted; 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. This declaration is made in kings-guard's own voice, per §11.)

Catalog entry (v0.4 §4): adaptive defence, observation; containment — pending (§9.2), until an engine exposes a containment surface. The pending mark exists because kings-guard raised the defect that v0.1 catalogued a capability §5 forbade discharging; the general rule is now §9.1.

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

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

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. Under §11 kings-guard is Conforming, not a tracked non-conformance. The fields follow §5.3's shape so one register can hold both, but the distinction is load-bearing — see the assessment sent to gate-house on 2026-08-29.

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	user-engine / access-engine	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
Containment surface — reduce authority, require step-up, isolate a workload — callable as a deterministic engine API, available while an incident is in progress	bounded response	access-engine, runtime engines	no engine surface exists; ruled pending in v0.4 §9.2, degraded-mode fallback ruled into the engine by §9.3	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, 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?