Register kings-guard with State Hub

INTENT.md

@@ -0,0 +1,202 @@
+# INTENT
+
+> 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?**