diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..e4e0199 --- /dev/null +++ b/.gitignore @@ -0,0 +1,5 @@ +# state-hub: track .claude/rules +# Claude Code local state (track shared rules; ignore machine-specific files) +.claude/* +!.claude/rules/ +!.claude/rules/*.md diff --git a/.repo-classification.yaml b/.repo-classification.yaml new file mode 100644 index 0000000..873abe8 --- /dev/null +++ b/.repo-classification.yaml @@ -0,0 +1,29 @@ +repo_classification: + standard: Repo Classification Standard + version: '1.0' + classified_at: '2026-07-23' + classified_by: codex + category: product + domain: infotech + secondary_domains: + - government + capability_tags: + - access-control + - policy + - governance + - risk + - platform + - operations + business_stake: + - technology + - operations + - legal + - product + business_mechanics: + - control + - coordination + - adaptation + notes: Adaptive security assessment and bounded-response control plane for + multi-tenant cloud environments; consumes evidence from identity, + authorization, secret, and runtime systems without replacing their primary + authority. diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..965ceae --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,222 @@ +# kings-guard — Agent Instructions + +## Repo Identity + +**Purpose:** Adaptive immune security control plane for complex multi-tenant cloud environments. + +**Domain:** infotech +**Repo slug:** kings-guard +**Topic ID:** `cee7bedf-2b48-46ef-8601-006474f2ad7a` +**Workplan prefix:** `KG-WP-` + +--- + +## State Hub Integration + +The Custodian State Hub tracks work across all domains. Interact via HTTP REST — +there is no MCP server for Codex agents. + +| Context | URL | +|---------|-----| +| Local workstation | `http://127.0.0.1:8000` | +| Remote via tunnel | `http://127.0.0.1:18000` | +| Optional local edge relay | http://127.0.0.1:18080 | + +When an operator has enabled the edge relay, set API_BASE to the relay URL. +Queueable writes return an explicit queued receipt if the central hub is +unreachable. Treat that as pending local evidence, then ask the operator to run +statehub outbox status/replay after connectivity returns. + +### Orient at session start + +```bash +# Offline brief — works without hub connection +cat .custodian-brief.md + +# Active workplans for this domain +curl -s "http://127.0.0.1:8000/workplans/?topic_id=cee7bedf-2b48-46ef-8601-006474f2ad7a&status=active" \ + | python3 -m json.tool + +# Check inbox +curl -s "http://127.0.0.1:8000/messages/?to_agent=kings-guard&unread_only=true" \ + | python3 -m json.tool +``` + +Mark a message read: +```bash +curl -s -X PATCH "http://127.0.0.1:8000/messages//read" \ + -H "Content-Type: application/json" -d '{}' +``` + +### Log progress (required at session close) + +```bash +curl -s -X POST http://127.0.0.1:8000/progress/ \ + -H "Content-Type: application/json" \ + -d '{ + "summary": "what was done", + "event_type": "note", + "author": "codex", + "workplan_id": "", + "task_id": "" + }' +``` + +Omit `workplan_id` / `task_id` when not applicable. + +### Update task status + +```bash +curl -s -X PATCH "http://127.0.0.1:8000/tasks/" \ + -H "Content-Type: application/json" \ + -d '{"status": "progress"}' +# values: wait | todo | progress | done | cancel +``` + +### Flag a task for human review + +```bash +curl -s -X PATCH "http://127.0.0.1:8000/tasks/" \ + -H "Content-Type: application/json" \ + -d '{"needs_human": true, "intervention_note": "reason"}' +``` + +--- + +## Session Protocol + +**Start:** +1. `cat .custodian-brief.md` — domain goal and open workplans (offline-safe) +2. Check inbox: `GET /messages/?to_agent=kings-guard&unread_only=true`; mark read +3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks +4. Check human-needed tasks: `GET /tasks/?needs_human=true` + +**During work:** +- Update task statuses in workplan files as tasks progress +- Record significant decisions via `POST /decisions/` + +**Close:** +1. Update workplan file task statuses to reflect progress +2. If finishing a workplan: hand off **residuals** as live work records first + (intake with `origin: residual` + `origin_ref: `, or a next workplan / + decision / engagement). Do not park leftovers only in prose or `SCOPE.md`. + Canon: `the-custodian/canon/standards/work-record-types_v0.1.md` § Residuals. +3. Log: `POST /progress/` with a summary of what changed (name handoff ids) +4. After workplan file changes, run: + ```bash + statehub fix-consistency + ``` + Coding agents should run this directly; ask the operator only if the CLI or + State Hub API is unavailable. This syncs task status from files into the hub DB. + +--- + +{CREDENTIAL_ROUTING} + + + + +## Repo-Specific Notes + +This repo is currently **docs-first**. There is no application runtime, package +manifest, or test suite yet. Do not invent build/test commands that do not +exist; add them only when the corresponding implementation lands. + +## Working Set + +Start with these files: + +```bash +cat INTENT.md +cat SCOPE.md +sed -n '1,260p' specs/NetKingdomImmuneArchitecture.md +sed -n '1,220p' history/InitialExploration.md +ls workplans/ +``` + +## Verification + +Current verification is structural, not runtime: + +```bash +# Check markdown/frontmatter edits and workplan formatting +git diff --check + +# Sync workplan/task state into State Hub after workplan changes +cd /home/worsch/state-hub && ./.venv/bin/statehub fix-consistency --repo kings-guard +``` + +When this repo gains executable code, extend this section with the real +install/test/lint/run commands in the same change. + +--- + +## Workplan Convention (ADR-001) + +Work items originate as files in this repo — not in the hub. The hub is a +read/cache/index layer that rebuilds from files. + +**File location:** `workplans/KG-WP-NNNN-.md` + +**Archived location:** finished workplans may move to +`workplans/archived/YYMMDD-KG-WP-NNNN-.md`. The `YYMMDD` prefix is +the completion/archive date; the frontmatter `id` does not change. + +**Ad Hoc Tasks:** small opportunistic fixes discovered during a session use +`workplans/ADHOC-YYYY-MM-DD.md` with task ids `ADHOC-YYYY-MM-DD-T01`, etc. Use +this only for low-risk work completed directly; create a normal workplan for +anything needing analysis, design, approval, dependencies, or multiple phases. + +**Frontmatter:** + +```yaml +--- +id: KG-WP-NNNN +type: workplan +title: "..." +domain: infotech +repo: kings-guard +status: proposed | ready | active | blocked | backlog | finished | archived +owner: codex +topic_slug: ... +created: "YYYY-MM-DD" +updated: "YYYY-MM-DD" +state_hub_workstream_id: "" # fix-consistency — do not edit (legacy field name; workplan UUID) +--- +``` + +Use `proposed` for a new draft, `ready` after review against current repo +state, and `finished` after implementation. `stalled` and `needs_review` are +derived health labels, not frontmatter statuses. + +**Terminology:** workplan is the fleet term; `workstream` appears only in legacy +API/MCP/frontmatter bridges until `STATE-WP-0069` retires them — see +`the-custodian/canon/standards/workplan-terminology-fleet_v0.1.md`. + +**Task block format** (one per `##` section): + +``` +## Task Title + +` ` `task +id: KG-WP-NNNN-T01 +status: wait | todo | progress | done | cancel +priority: high | medium | low +state_hub_task_id: "" # written by fix-consistency — do not edit +` ` ` + +Task description text. +``` + +Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work. + +**Residuals when finishing:** actionable leftovers become live work records +before `status: finished` — usually an intake (`origin: residual`, +`origin_ref: KG-WP-NNNN`) or a spawned workplan. Residual is a *role*, +not a kind. Fleet list lives on State Hub, not in `SCOPE.md`. + +To create a new workplan: +1. Write the file following the format above +2. Run `statehub fix-consistency` locally; ask the operator only if the CLI or + State Hub API is unavailable. diff --git a/INTENT.md b/INTENT.md new file mode 100644 index 0000000..7050575 --- /dev/null +++ b/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?** diff --git a/SCOPE.md b/SCOPE.md new file mode 100644 index 0000000..7d4b9a9 --- /dev/null +++ b/SCOPE.md @@ -0,0 +1,66 @@ +# SCOPE + +> Lightweight boundary for agents and contributors. + +--- + +## One-liner + +Adaptive security assessment and bounded-response layer for multi-tenant cloud +platforms. + +--- + +## Core Idea + +`kings-guard` turns declared healthy intent plus observed runtime behavior into +posture judgments, typed security signals, and bounded response requests. It +consumes evidence from identity, authorization, secret, and runtime systems +without replacing those systems' primary authority. + +--- + +## In Scope + +- Canonical terminology and contracts for security genome, phenotype, + observation, signal, effector, tolerance, inflammation, and immune memory. +- Reference architecture and boundary documents for adaptive defense in + multi-tenant and agent-active environments. +- Minimal posture-evaluation loop design: ingest observations, compare against + intended healthy state, and emit typed posture/signal results. +- Integration seams to adjacent security systems such as `key-cape`, + `flex-auth`, `secrets-engine`, `ops-warden`, and the Railiance runtime + layers. +- Non-secret evidence, workplans, and repo-operational metadata. + +--- + +## Out of Scope + +- Identity issuance, login, MFA, or token minting. +- Authorization policy administration or final resource allow/deny decisions. +- Secret custody, lease issuance, or raw secret-value delivery. +- Infrastructure provisioning, workload deployment, or cluster/platform + operations. +- Generic SIEM ownership, ticket tracking, or live work coordination beyond + this repo's own workplans. + +--- + +## Current State + +- Markdown-first exploration repo. Current canon is `INTENT.md`, + `specs/NetKingdomImmuneArchitecture.md`, and `history/InitialExploration.md`. +- No executable service, schemas, or integration adapters exist yet. +- The first implementation strand should establish canonical contracts and a + minimal posture pilot before broader integrations. + +--- + +## Getting Oriented + +- Start with: `INTENT.md` +- Architecture draft: `specs/NetKingdomImmuneArchitecture.md` +- Exploration notes: `history/InitialExploration.md` +- Agent instructions: `AGENTS.md` +- Workplans: `workplans/` diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md new file mode 100644 index 0000000..88b9c22 --- /dev/null +++ b/WORK-RECORDS.md @@ -0,0 +1,19 @@ +# Work Records — kings-guard + +> Generated by `statehub fix-consistency` (CUST-WP-0061-T04, work-record +> stage 3). Do not edit by hand — edit the source file/block listed for +> each record and re-run fix-consistency to refresh this index. Archived +> workplans are omitted; closed decisions/intakes/engagements stay listed +> so recently-resolved work is still visible. [auto] + +| Kind | ID | Status | Lane | Source | +| --- | --- | --- | --- | --- | +| workplan | KG-WP-0001 | finished | — | workplans/KG-WP-0001-statehub-bootstrap.md | +| workplan | KG-WP-0002 | ready | — | workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md | +| task | KG-WP-0001-T01 | done | — | workplans/KG-WP-0001-statehub-bootstrap.md | +| task | KG-WP-0001-T02 | done | — | workplans/KG-WP-0001-statehub-bootstrap.md | +| task | KG-WP-0001-T03 | done | — | workplans/KG-WP-0001-statehub-bootstrap.md | +| task | KG-WP-0002-T01 | todo | — | workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md | +| task | KG-WP-0002-T02 | todo | — | workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md | +| task | KG-WP-0002-T03 | todo | — | workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md | +| task | KG-WP-0002-T04 | todo | — | workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md | diff --git a/history/InitialExploration.md b/history/InitialExploration.md new file mode 100644 index 0000000..bb6717c --- /dev/null +++ b/history/InitialExploration.md @@ -0,0 +1,687 @@ +# Adaptive Immune Security Architecture + +Kings Guard Security is an exploration about how to establish robust security in a continuously changing complex IT environment. + +How would the architecture of an it security system for a multitenant multipurpose it cloud platfrom look like that is inspired by analogy to a biological immune system? + +A recursive, identity-centred security system that continuously distinguishes intended from harmful behaviour, contains disturbances locally, restores healthy operation, and learns from every incident without weakening tenant isolation. + +The objective is not an impossible state in which nothing malicious ever enters. It is to preserve the platform’s **viability** by enabling it to: + +1. anticipate threats, +2. withstand compromise, +3. contain damage, +4. recover healthy operation, +5. adapt its future defences. + +This closely matches the NIST cyber-resiliency formulation of anticipating, withstanding, recovering from and adapting to adverse conditions. ([NIST Computer Security Resource Center][1]) + +Biologically, the architecture draws on barriers, innate immunity, adaptive immunity, signalling, memory, regulation and tissue repair. Innate immunity provides fast, general responses, while adaptive immunity develops specific responses and memory; both depend on regulation to avoid damaging the organism itself. ([NCBI][2]) + +## 1. The crucial interpretation of “self” + +A simplistic security analogy would classify everything as either: + +* self and trusted, or +* foreign and hostile. + +That would be dangerous. A legitimate workload can be compromised, an administrator account can be hijacked, and a previously permitted behaviour can become harmful. + +Therefore, **self must not mean “inside the network.”** + +In this architecture, self means: + +> A subject whose identity, provenance, integrity, current state, requested action and behavioural context remain consistent with explicitly declared intent. + +This follows the zero-trust shift away from trusting network locations toward protecting identified users, workloads, resources and actions. NIST explicitly rejects implicit trust based solely on location or ownership and, for cloud-native systems, recommends policies based on application and service identities. ([NIST Computer Security Resource Center][3]) + +A workload should therefore continuously be able to answer: + +* Who am I? +* Which tenant do I belong to? +* Which software and configuration am I running? +* Who authorized this deployment? +* Which capabilities may I exercise? +* Which data may I access? +* With whom may I communicate? +* What behaviour is expected from me? +* Is my current state consistent with that declaration? + +This could be called the workload’s **security phenotype**. + +--- + +# 2. Biological concepts and architectural counterparts + +| Biological concept | Security counterpart | Architectural capability | +| ----------------------------- | -------------------------------- | ------------------------------------------------------------------------------------------- | +| Genome | Canonical intended state | Signed architecture, configuration, policies, SBOMs, identities and capability declarations | +| Skin and mucosa | External barriers | Edge gateway, DDoS protection, ingress validation, protocol filtering | +| Organ boundaries | Tenant compartments | Tenant-specific identity, network, compute, data, key and policy boundaries | +| Cell membrane | Workload boundary | Workload identity, sandbox, runtime policy, least privilege | +| Self markers | Attested identity and provenance | Cryptographic workload identity, signatures, deployment provenance | +| Innate immunity | Immediate general defence | Deny-by-default, validation, rate limits, runtime rules, isolation | +| Pattern-recognition receptors | Security sensors | Kernel, network, identity, API, data and application telemetry | +| Antigen presentation | Normalized security evidence | Contextual observation records presented to decision services | +| Cytokines | Security signalling | Typed event fabric carrying alerts, state changes and response requests | +| Lymph nodes | Local correlation centres | Tenant-local detection, evidence aggregation and response coordination | +| Adaptive immunity | Incident-specific defence | New detections, policies, playbooks and countermeasures | +| Antibodies | Targeted countermeasures | Signatures, deny rules, revocations, filters and compensating controls | +| Complement system | Automated response primitives | Block, throttle, quarantine, terminate, revoke and rotate | +| Memory cells | Security memory | Threat knowledge, attack paths, successful countermeasures and lessons | +| Regulatory T cells | Safety and governance | Response limits, approval rules, suppression, rollback and exception control | +| Inflammation | Elevated defensive posture | Temporary restriction, increased telemetry and reduced trust | +| Tissue repair | Reconciliation and recovery | Immutable redeployment, restoration, secret rotation and validation | + +The point is not to reproduce biology literally. The analogy provides a useful decomposition of **distributed protection, signalling, regulation, learning and repair**. + +--- + +# 3. Top-level architecture + +```mermaid +flowchart TB + EXT["Users, Agents, Services, Devices and External Systems"] + + subgraph GOV["Security Genome and Governance"] + INTENT["Intent and Capability Registry"] + CANON["Security Canon and Policy Sources"] + SUPPLY["Software and Configuration Provenance"] + RISK["Risk Appetite and Tenant Profiles"] + end + + subgraph ICP["Platform Immune Control Plane"] + ID["Identity and Attestation Authority"] + MEMORY["Immune Memory and Countermeasure Graph"] + DECIDE["Policy and Response Decision Engine"] + REGULATE["Tolerance, Safety and Escalation Controller"] + AUDIT["Independent Audit and Validation"] + BUS["Security Signal Fabric"] + end + + subgraph TENANT["Tenant Immune Compartment — repeated per tenant"] + MEMBRANE["Tenant Membrane"] + THYMUS["Admission and Deployment Education"] + APPS["Applications, Data and Workloads"] + SENTINELS["Local Sentinels"] + NODE["Tenant Immune Node"] + EFFECTORS["Local Response Effectors"] + HEAL["Recovery and Reconstitution"] + end + + subgraph PLATFORM["Shared Platform Compartments"] + SHARED["Brokered Shared Services"] + INFRA["Cluster, Network, Storage and Runtime"] + PLATFORM_SENTINELS["Platform Sentinels"] + end + + EXT --> MEMBRANE + GOV --> ID + GOV --> DECIDE + GOV --> THYMUS + + MEMBRANE --> APPS + THYMUS --> APPS + ID --> APPS + + APPS --> SENTINELS + INFRA --> PLATFORM_SENTINELS + + SENTINELS --> NODE + NODE --> BUS + PLATFORM_SENTINELS --> BUS + + BUS --> DECIDE + MEMORY --> DECIDE + RISK --> REGULATE + DECIDE --> REGULATE + + REGULATE --> EFFECTORS + EFFECTORS --> APPS + EFFECTORS --> MEMBRANE + EFFECTORS --> HEAL + + HEAL --> APPS + BUS --> MEMORY + AUDIT --> MEMORY + AUDIT --> DECIDE + + APPS <--> SHARED +``` + +The most important topological feature is that the architecture is **recursive**: + +* every workload has a local protective boundary; +* every application has a security context; +* every tenant has an immune compartment; +* every cluster has a platform immune system; +* the complete cloud estate has a federated security system. + +Local systems act autonomously within bounded authority, while higher levels coordinate events whose impact crosses compartments. + +--- + +# 4. Seven orthogonal security planes + +## 4.1 Security Genome Plane + +The genome describes what healthy operation is supposed to look like. + +For each workload or capability, it should contain: + +* tenant and ownership; +* intended purpose; +* software and configuration provenance; +* permitted interfaces; +* dependencies; +* permitted callers and destinations; +* data classifications; +* expected resource consumption; +* expected execution behaviour; +* availability and recovery requirements; +* applicable policies; +* known exceptions. + +This connects naturally with your distinction between **stable INTENT and actual SCOPE**. + +The immune system does not merely ask whether behaviour is statistically unusual. It asks: + +> Is actual behaviour compatible with the declared intent and authorized scope? + +This prevents the system from gradually learning that a persistent compromise is “normal.” + +## 4.2 Identity and Attestation Plane + +This plane establishes identity for: + +* humans; +* agents; +* devices; +* workloads; +* services; +* deployment pipelines; +* infrastructure components; +* external organizations. + +Human identity could remain within the **KeyCape IAM profile**, while workload identity is handled through a replaceable attestation contract. + +SPIFFE/SPIRE is a strong implementation model because it provides cryptographically verifiable workload identities based on node and workload attestation rather than relying solely on long-lived secrets. Its trust-domain model also lends itself to tenant and platform compartmentation. ([spiffe.io][4]) + +An identity is not permanently trusted. It acquires a current **trust posture** derived from: + +* strength of attestation; +* software integrity; +* configuration integrity; +* device or node state; +* recent behaviour; +* credential age; +* active incident context; +* requested resource sensitivity. + +## 4.3 Membrane and Compartment Plane + +There should be several nested membranes: + +1. **platform membrane** between the cloud and the outside world; +2. **tenant membrane** between tenants; +3. **application membrane** around an application domain; +4. **workload membrane** around each execution unit; +5. **data membrane** around sensitive data sets; +6. **management membrane** around control-plane operations. + +Each tenant should have its own: + +* identity namespace; +* policy bundle; +* encryption context; +* secrets domain; +* network policy; +* data partition; +* telemetry partition; +* security memory scope; +* response authority. + +Kubernetes supports multiple tenancy patterns, but its documentation explicitly distinguishes softer and harder isolation and notes trade-offs among security, complexity and cost. A biological architecture should therefore support several **isolation phenotypes**, rather than assuming namespaces alone are sufficient. ([Kubernetes][5]) + +A practical classification would be: + +| Isolation class | Typical realization | +| --------------- | ---------------------------------------------------------------------- | +| Shared | Namespace and policy isolation | +| Reinforced | Virtual control plane, dedicated nodes or sandboxed runtimes | +| Strong | Dedicated cluster and tenant trust domain | +| Sovereign | Dedicated cloud account, keys, control plane and operational authority | + +The risk profile of a tenant or workload determines the required isolation class. + +## 4.4 Sentinel and Evidence Plane + +Sentinels are distributed throughout the system: + +* edge sentinels; +* API sentinels; +* identity sentinels; +* workload sentinels; +* kernel sentinels; +* network sentinels; +* data-access sentinels; +* control-plane sentinels; +* application-domain sentinels. + +They produce normalized **security observations**, not immediately final conclusions. + +A useful observation envelope would include: + +```yaml +security_observation: + observation_id: uuid + timestamp: datetime + + tenant_id: tenant-reference + compartment_id: compartment-reference + subject_id: attested-subject-reference + resource_id: resource-reference + + operation: requested-or-observed-action + evidence: + - evidence-reference + + intent_relation: + expected: true + deviation_type: none | unknown | prohibited | anomalous + + assessment: + confidence: 0.0-1.0 + severity: informational | low | medium | high | critical + novelty: known | variant | unknown + blast_radius: local | application | tenant | platform + + proposed_response: + action: observe | challenge | restrict | isolate | revoke | rebuild + ttl: duration +``` + +The evidence remains distinguishable from its interpretation. That allows later reassessment when new information becomes available. + +## 4.5 Signal and Coordination Plane + +Biological cytokines coordinate immune activity. The platform equivalent is a typed, authenticated **security signal fabric**. + +It transports: + +* observations; +* identity posture changes; +* integrity failures; +* policy violations; +* suspected attack chains; +* response requests; +* response outcomes; +* recovery state; +* escalation messages. + +Signals require: + +* tenant and compartment scope; +* origin identity; +* evidence references; +* confidence; +* severity; +* expiry time; +* deduplication identity; +* confidentiality classification; +* permitted consumers. + +Raw tenant evidence should not automatically enter a global platform data lake. The architecture should distinguish: + +* **tenant-private evidence**; +* **platform-operational evidence**; +* **shareable threat characteristics**; +* **global countermeasure knowledge**. + +This allows collective learning without creating a cross-tenant surveillance or leakage mechanism. + +## 4.6 Response and Recovery Plane + +The response system should use a graduated ladder: + +1. **observe** — collect more evidence; +2. **challenge** — require stronger authentication or attestation; +3. **constrain** — reduce permissions, destinations or rate; +4. **degrade** — disable nonessential capabilities; +5. **isolate** — quarantine workload, identity, node or tenant segment; +6. **revoke** — invalidate credentials, sessions or deployment authority; +7. **terminate** — stop malicious execution; +8. **reconstitute** — rebuild from known-good state; +9. **restore** — recover validated data and service; +10. **immunize** — distribute a tested countermeasure. + +Responses should be local by default. A workload sentinel may stop its workload, but it should not be able to shut down unrelated tenants. + +Every automated response should carry: + +* authority source; +* reason and evidence; +* scope; +* duration or lease; +* rollback procedure; +* expected outcome; +* validation condition; +* escalation threshold. + +Runtime detection and enforcement can be realized by different interchangeable effectors. Current cloud-native examples include Falco for runtime detection and Tetragon for Kubernetes-aware eBPF observation and inline enforcement. ([Falco][6]) + +## 4.7 Memory and Adaptation Plane + +Immune memory should not be just a SIEM archive. It should be an active knowledge graph connecting: + +```text +Observation + → Evidence + → Subject + → Asset + → Vulnerability + → Attack technique + → Intended capability + → Countermeasure + → Response action + → Outcome + → Residual risk +``` + +MITRE D3FEND is particularly suitable as an external vocabulary because it models defensive countermeasures and their relationships to offensive techniques as a knowledge graph. ([d3fend.mitre.org][7]) + +Memory objects need: + +* provenance; +* confidence; +* applicability conditions; +* tenant visibility; +* creation and expiry dates; +* successful and unsuccessful outcomes; +* counter-evidence; +* versioning; +* revocation. + +Security memory must be allowed to **decay**. A rule that was useful two years ago may now be ineffective or actively harmful. + +--- + +# 5. Tenant-local and platform-wide immunity + +The system should distinguish three kinds of security knowledge. + +## Tenant-local immunity + +Contains: + +* tenant-specific behaviour; +* tenant-specific risks; +* local incidents; +* business-process expectations; +* local countermeasures; +* confidential evidence. + +The tenant immune node owns this information and can act rapidly inside its compartment. + +## Platform immunity + +Contains: + +* infrastructure attacks; +* shared service compromise; +* cluster and control-plane conditions; +* supply-chain risks; +* cross-tenant attack patterns; +* platform countermeasures. + +The platform immune system may contain or disconnect a tenant compartment, but it should not inspect tenant-private data without an explicit legal and policy basis. + +## Federated immune memory + +Contains only information approved for broader use, such as: + +* attack fingerprints; +* affected component versions; +* defensive techniques; +* anonymized behavioural patterns; +* successful containment strategies; +* externally sourced threat intelligence. + +Cross-tenant learning should distribute **countermeasures and abstract characteristics**, not raw customer evidence. + +--- + +# 6. Preventing digital autoimmune disease + +A biological analogy becomes truly valuable when it includes immune failure modes. + +## Autoimmunity + +The security system attacks legitimate activity. + +Countermeasures: + +* policy simulation; +* shadow mode; +* canary enforcement; +* independent evidence requirements; +* bounded response authority; +* automatic expiry; +* rollback; +* tenant-specific tolerance profiles. + +## Immunodeficiency + +The system lacks sensors, policies or response capabilities. + +Countermeasures: + +* coverage measurement; +* mandatory baseline controls; +* sentinel health monitoring; +* capability maturity assessment; +* periodic attack simulation. + +## Chronic inflammation + +The platform remains permanently in a high-alert state. + +Consequences include: + +* alert fatigue; +* excessive logging; +* degraded performance; +* blocked delivery; +* permanently elevated privileges for security tooling. + +Controls should include response budgets, signal suppression, incident closure criteria and automatic return to baseline. + +## Immune evasion + +An attacker appears legitimate or disables sensors. + +Countermeasures: + +* independent telemetry paths; +* remote attestation; +* immutable evidence; +* separation of control and observation; +* detection of missing signals; +* periodic re-attestation. + +## Malignant growth + +A legitimate component expands beyond its intended role. + +This includes: + +* privilege accumulation; +* uncontrolled agent autonomy; +* data hoarding; +* hidden dependencies; +* excessive resource consumption. + +The response is not signature detection, but comparison of actual growth against declared purpose, resource limits and capability boundaries. + +--- + +# 7. Cybernetic control loops + +The architecture should operate at three timescales. + +## Fast local loop — innate immunity + +```text +Sense → match local rule → constrain → report +``` + +Examples: + +* reject an invalid request; +* block an unauthorized syscall; +* rate-limit abnormal traffic; +* quarantine a workload. + +## Tenant loop — adaptive response + +```text +Correlate → assess tenant context → select response +→ observe outcome → update tenant memory +``` + +Examples: + +* revoke a tenant user session; +* restrict an application; +* rotate tenant credentials; +* deploy a tenant-specific rule. + +## Platform learning loop + +```text +Aggregate abstract findings → analyze attack pattern +→ validate countermeasure → publish policy update +→ measure effectiveness +``` + +Examples: + +* revise a platform baseline; +* block a vulnerable artifact; +* introduce a new supply-chain requirement; +* change default isolation for a workload class. + +--- + +# 8. VSM mapping + +The architecture maps neatly onto the Viable System Model. + +| VSM system | Immune-security responsibility | +| --------------------------- | ------------------------------------------------------------------------------- | +| **System 1 – Operation** | Workload, application and tenant-local sentinels and effectors | +| **System 2 – Coordination** | Security signal fabric, deduplication, suppression and incident coordination | +| **System 3 – Control** | Tenant and platform response controllers | +| **System 3* – Audit** | Independent validation, red teaming, forensic evidence and control verification | +| **System 4 – Intelligence** | Threat research, attack simulation, adaptive policies and immune memory | +| **System 5 – Policy** | Security identity, risk appetite, legal constraints and response authority | + +This supports recursion: each tenant is a viable security system while remaining part of the larger platform security system. + +--- + +# 9. Suggested NetKingdom capability structure + +For NetKingdom, I would organize the architecture into these stable capabilities rather than tightly coupling it to individual products: + +```text +netkingdom +├── security-genome +│ ├── intent-registry +│ ├── capability-registry +│ ├── policy-canon +│ └── provenance-registry +│ +├── identity-immunity +│ ├── human-identity +│ ├── workload-identity +│ ├── attestation +│ └── trust-posture +│ +├── compartment-control +│ ├── tenant-isolation +│ ├── workload-boundaries +│ ├── data-boundaries +│ └── shared-service-brokers +│ +├── sentinel-mesh +│ ├── edge-sentinel +│ ├── identity-sentinel +│ ├── runtime-sentinel +│ ├── network-sentinel +│ └── data-sentinel +│ +├── immune-coordination +│ ├── observation-model +│ ├── signal-fabric +│ ├── tenant-immune-node +│ └── platform-immune-node +│ +├── immune-response +│ ├── decision-engine +│ ├── response-orchestrator +│ ├── effectors +│ └── escalation +│ +├── immune-memory +│ ├── evidence-store +│ ├── countermeasure-graph +│ ├── outcome-learning +│ └── memory-federation +│ +└── immune-regulation + ├── tolerance-control + ├── simulation + ├── response-budgets + ├── audit + └── recovery-validation +``` + +The stable core would consist of the contracts between these capabilities. KeyCape, SPIRE, OPA, Tetragon, Falco, network-policy engines, evidence stores and other implementations would remain replaceable components behind those contracts. OPA/Gatekeeper, for example, can serve as one admission-policy implementation rather than becoming the architecture itself. ([openpolicyagent.org][8]) + +# Central architectural proposition + +The resulting NetKingdom system would not primarily be a collection of scanners, dashboards and blocking products. It would be a **recursive security control system** that: + +```text +declares healthy intent +→ establishes cryptographic identity +→ observes actual behaviour +→ detects meaningful divergence +→ responds within bounded authority +→ restores known-good operation +→ validates the outcome +→ retains governed memory +``` + +Its most distinctive property would be the combination of: + +* **zero-trust identity**, +* **tenant compartmentation**, +* **distributed innate protection**, +* **adaptive countermeasure generation**, +* **cybernetic response loops**, +* **regulated autonomy**, +* **continuous repair**. + +A logical next artifact is an OAS-formatted `NetKingdomImmuneArchitecture.md` with context, capability, control-loop, deployment, data, trust-boundary and failure-mode views. + +[1]: https://csrc.nist.gov/pubs/sp/800/160/v2/r1/final "SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach | CSRC" +[2]: https://www.ncbi.nlm.nih.gov/books/NBK539801/?utm_source=chatgpt.com "Physiology, Immune Response - StatPearls - NCBI Bookshelf" +[3]: https://csrc.nist.gov/pubs/sp/800/207/final "SP 800-207, Zero Trust Architecture | CSRC" +[4]: https://spiffe.io/docs/latest/spire-about/spire-concepts/ "SPIRE Concepts | SPIFFE" +[5]: https://kubernetes.io/docs/concepts/security/multi-tenancy/ "Multi-tenancy | Kubernetes" +[6]: https://falco.org/docs/?utm_source=chatgpt.com "The Falco Project" +[7]: https://d3fend.mitre.org/about/ "About | MITRE D3FEND™" +[8]: https://openpolicyagent.org/docs/kubernetes?utm_source=chatgpt.com "OPA for Kubernetes Admission Control" + diff --git a/specs/NetKingdomImmuneArchitecture.md b/specs/NetKingdomImmuneArchitecture.md new file mode 100755 index 0000000..8628200 --- /dev/null +++ b/specs/NetKingdomImmuneArchitecture.md @@ -0,0 +1,2292 @@ +--- +title: NetKingdom Immune Architecture +document_id: KG-ARCH-IMMUNE +version: 0.1.0 +status: Draft +date: 2026-07-23 +repo: kings-guard +brand: Kings Guard Security +ecosystem: NetKingdom +owners: + - Kings Guard Security Architecture +classification: Public +--- + +# NetKingdom Immune Architecture + +## 1. Purpose + +This document defines the reference architecture for **Kings Guard Security**, implemented in the `kings-guard` repository and positioned within the wider **NetKingdom** ecosystem. + +The architecture applies principles observed in biological immune systems to the design of a secure, resilient, multi-tenant and multi-purpose cloud platform. The biological analogy is used as an architectural reasoning model, not as a literal implementation prescription. + +The system is intended to protect heterogeneous cloud environments containing: + +- multiple independent tenants; +- multiple vendors and operators; +- human users, machine identities and autonomous agents; +- shared and tenant-dedicated infrastructure; +- applications with different criticality and trust requirements; +- data with different confidentiality, integrity and availability requirements; +- changing workloads, dependencies and threat conditions. + +The architecture aims to preserve the platform's viability by enabling it to: + +1. distinguish intended from harmful behaviour; +2. identify and contain disturbances near their origin; +3. adapt defensive measures to new evidence; +4. restore known-good operation after compromise; +5. learn without violating tenant confidentiality; +6. avoid damaging legitimate activity through uncontrolled defensive action. + +--- + +## 2. Architectural Proposition + +Kings Guard Security is a **recursive adaptive security control system**. + +It continuously executes the following cycle: + +```text +declare healthy intent +→ establish and attest identity +→ observe actual behaviour +→ compare behaviour with intent and policy +→ assess risk and confidence +→ respond within bounded authority +→ restore known-good operation +→ validate the outcome +→ retain governed security memory +``` + +The system does not treat trust as a permanent property. + +Trust is a temporary, scoped and continuously reassessed condition derived from: + +- identity; +- provenance; +- attestation; +- integrity; +- configuration; +- behaviour; +- requested operation; +- data sensitivity; +- current incident context; +- tenant and platform policy. + +--- + +## 3. Scope + +### 3.1 In Scope + +This architecture covers: + +- human, device, workload, service and agent identities; +- authentication, authorization and continuous trust evaluation; +- tenant compartmentation; +- workload isolation; +- network and data boundaries; +- policy distribution and enforcement; +- admission control; +- runtime detection; +- security event transport; +- local and global security decisions; +- automated and human-approved response; +- recovery and reconstitution; +- incident evidence; +- adaptive security memory; +- cross-tenant defensive learning; +- security governance and safety controls; +- security observability and assurance. + +### 3.2 Out of Scope + +This document does not prescribe: + +- a single cloud provider; +- a single container or orchestration platform; +- a single identity provider; +- a single SIEM, SOAR, EDR or policy engine; +- a fixed commercial product stack; +- one mandatory deployment topology; +- detailed legal or regulatory mappings; +- application-specific business controls. + +Implementations may use different products behind stable Kings Guard capability and interface contracts. + +--- + +## 4. Core Terminology + +### 4.1 Organism + +The complete governed platform environment whose viability is to be preserved. + +An organism may be: + +- one cloud platform; +- one sovereign deployment; +- one company environment; +- a federation of cooperating platform environments. + +### 4.2 Compartment + +A bounded security domain with an explicit identity, authority, policy, telemetry and response scope. + +Examples: + +- tenant; +- cluster; +- namespace; +- application domain; +- data domain; +- management plane; +- sovereign environment. + +### 4.3 Subject + +An entity capable of performing or requesting an action. + +Examples: + +- person; +- service; +- workload; +- device; +- agent; +- pipeline; +- operator; +- external organization. + +### 4.4 Resource + +An entity on which an operation may be performed. + +Examples: + +- API; +- dataset; +- secret; +- queue; +- workload; +- deployment; +- infrastructure object; +- identity; +- policy. + +### 4.5 Security Genome + +The canonical description of intended healthy operation. + +It includes: + +- declared purpose; +- ownership; +- identities; +- permitted capabilities; +- dependencies; +- policies; +- provenance requirements; +- expected behaviour; +- recovery requirements; +- applicable risk profile. + +### 4.6 Security Phenotype + +The observable, attested state and behaviour of a subject or compartment at a point in time. + +### 4.7 Immune Observation + +A normalized statement about a security-relevant event or state, kept distinct from its interpretation. + +### 4.8 Immune Signal + +An authenticated, typed message used to coordinate security assessment or response. + +### 4.9 Effector + +A component authorized to perform a concrete defensive action. + +Examples: + +- reject; +- throttle; +- isolate; +- revoke; +- terminate; +- rotate; +- restore; +- rebuild. + +### 4.10 Immune Memory + +Governed knowledge derived from observations, incidents, threat intelligence, countermeasures and response outcomes. + +### 4.11 Tolerance + +The explicit permission for a known deviation, exception or variation that must not trigger an inappropriate defensive response. + +### 4.12 Inflammation + +A temporary elevated defensive posture with increased observation and restricted freedom of operation. + +### 4.13 Reconstitution + +The replacement of a compromised or uncertain component with a newly established known-good component. + +--- + +## 5. Biological Analogy + +| Biological mechanism | Security interpretation | Kings Guard capability | +|---|---|---| +| Genome | Intended healthy state | Security Genome | +| Skin and mucosa | External protection | Platform Edge Membrane | +| Organ boundary | Compartment isolation | Tenant and Domain Membranes | +| Cell membrane | Workload boundary | Workload Guard | +| Self markers | Verifiable identity | Identity and Attestation | +| Innate immunity | Immediate general defence | Local Sentinels and Baseline Policies | +| Pattern-recognition receptors | Detection mechanisms | Sensor and Observation Mesh | +| Antigen presentation | Contextualized evidence | Evidence Normalization | +| Cytokines | Distributed coordination signals | Immune Signal Fabric | +| Lymph nodes | Local correlation and decision | Tenant Immune Node | +| Adaptive immunity | Incident-specific learning | Adaptive Decision and Policy Generation | +| Antibodies | Targeted countermeasures | Signatures, Rules and Revocations | +| Complement system | Immediate action primitives | Response Effectors | +| Memory cells | Retained defensive knowledge | Immune Memory | +| Regulatory T cells | Safety and restraint | Immune Regulation | +| Inflammation | Elevated defensive state | Defensive Posture Management | +| Tissue repair | Recovery and healing | Reconciliation and Reconstitution | + +The analogy must never override explicit engineering, legal, safety or operational requirements. + +--- + +## 6. Design Principles + +### 6.1 Identity Before Location + +Network position does not establish trust. + +Every relevant action must be attributable to an authenticated and, where required, attested subject. + +### 6.2 Intent Before Anomaly + +Statistical anomaly alone is insufficient. + +Observed behaviour should be evaluated against: + +- declared intent; +- permitted scope; +- current policy; +- expected dependencies; +- operational context. + +### 6.3 Compartmentation Before Global Trust + +The platform is divided into bounded security compartments. + +Compromise of one compartment must not automatically compromise another. + +### 6.4 Local Response Before Central Escalation + +Disturbances should be handled as close to their origin as safely possible. + +Local components receive bounded authority and escalate when: + +- evidence is insufficient; +- impact may cross compartment boundaries; +- response exceeds local authority; +- platform-level coordination is required. + +### 6.5 Evidence Before Judgment + +Observations, interpretations, decisions and actions remain distinguishable. + +This enables: + +- independent reassessment; +- forensic reconstruction; +- policy improvement; +- explainability; +- reduction of cascading false conclusions. + +### 6.6 Reversible Automation Before Irreversible Action + +Automated response should prefer temporary, scoped and reversible controls. + +Irreversible or high-impact actions require stronger evidence or approval. + +### 6.7 Recovery Before Perfect Prevention + +The system assumes that some controls will fail. + +Every critical capability must have: + +- containment; +- restoration; +- reconstitution; +- validation; +- continuity procedures. + +### 6.8 Memory With Provenance and Decay + +Security knowledge must include: + +- source; +- confidence; +- applicability; +- scope; +- effective date; +- expiry or review date; +- counter-evidence; +- observed outcomes. + +### 6.9 Tenant Sovereignty Within Platform Viability + +Tenants control their own security policy within boundaries required to preserve the platform and other tenants. + +### 6.10 Replaceable Implementations + +Kings Guard defines stable capability contracts. + +Specific identity, policy, runtime, network and observability products remain replaceable. + +### 6.11 Fail Securely, Not Blindly + +Loss of a security dependency must result in an explicitly defined degraded mode rather than an accidental unrestricted mode. + +### 6.12 Minimum Necessary Observation + +Telemetry collection must be proportional to: + +- security purpose; +- legal basis; +- tenant policy; +- data sensitivity; +- retention need. + +--- + +## 7. Recursive Security Model + +Kings Guard applies the same security logic at multiple levels. + +```mermaid +flowchart TB + GLOBAL["Federated NetKingdom Security"] + PLATFORM["Platform Immune System"] + TENANT["Tenant Immune System"] + APP["Application Immune System"] + WORKLOAD["Workload Guard"] + OPERATION["Protected Operation"] + + GLOBAL --> PLATFORM + PLATFORM --> TENANT + TENANT --> APP + APP --> WORKLOAD + WORKLOAD --> OPERATION + + OPERATION --> WORKLOAD + WORKLOAD --> APP + APP --> TENANT + TENANT --> PLATFORM + PLATFORM --> GLOBAL +``` + +Each level has: + +- an identity; +- a declared intent; +- observable state; +- policy; +- bounded authority; +- local memory; +- escalation rules; +- recovery procedures. + +Higher levels coordinate lower levels without erasing their autonomy. + +--- + +## 8. Top-Level Architecture + +```mermaid +flowchart TB + EXT["Users, Agents, Devices, Services and External Systems"] + + subgraph GENOME["Security Genome and Governance"] + INTENT["Intent and Capability Registry"] + POLICY["Policy Canon"] + PROVENANCE["Artifact and Configuration Provenance"] + RISK["Risk Profiles and Security Objectives"] + end + + subgraph CONTROL["Platform Immune Control Plane"] + IDENTITY["Identity and Attestation Authority"] + DECISION["Decision and Response Engine"] + REGULATION["Safety, Tolerance and Escalation Controller"] + MEMORY["Immune Memory and Countermeasure Graph"] + AUDIT["Independent Audit and Validation"] + SIGNAL["Immune Signal Fabric"] + end + + subgraph TENANT["Tenant Immune Compartment"] + MEMBRANE["Tenant Membrane"] + EDUCATION["Admission and Deployment Education"] + APPLICATIONS["Applications, Data and Workloads"] + SENTINELS["Tenant Sentinels"] + NODE["Tenant Immune Node"] + EFFECTORS["Tenant Response Effectors"] + RECOVERY["Tenant Recovery and Reconstitution"] + end + + subgraph SHARED["Shared Platform Compartments"] + BROKER["Brokered Shared Services"] + INFRA["Compute, Network, Storage and Runtime"] + PSENTINELS["Platform Sentinels"] + PEFFECTORS["Platform Effectors"] + end + + EXT --> MEMBRANE + MEMBRANE --> APPLICATIONS + + GENOME --> IDENTITY + GENOME --> DECISION + GENOME --> EDUCATION + + IDENTITY --> MEMBRANE + IDENTITY --> APPLICATIONS + EDUCATION --> APPLICATIONS + + APPLICATIONS --> SENTINELS + INFRA --> PSENTINELS + + SENTINELS --> NODE + NODE --> SIGNAL + PSENTINELS --> SIGNAL + + SIGNAL --> DECISION + MEMORY --> DECISION + RISK --> REGULATION + DECISION --> REGULATION + + REGULATION --> EFFECTORS + REGULATION --> PEFFECTORS + + EFFECTORS --> APPLICATIONS + EFFECTORS --> MEMBRANE + EFFECTORS --> RECOVERY + PEFFECTORS --> INFRA + + RECOVERY --> APPLICATIONS + SIGNAL --> MEMORY + AUDIT --> MEMORY + AUDIT --> DECISION + + APPLICATIONS <--> BROKER +``` + +--- + +## 9. Architectural Planes + +The architecture is organized into nine orthogonal planes. + +### 9.1 Security Genome Plane + +The Security Genome Plane defines intended healthy operation. + +#### Responsibilities + +- maintain canonical security intent; +- register capabilities and dependencies; +- define permitted interactions; +- bind workloads to owners and tenants; +- define expected software and configuration provenance; +- define data sensitivity and handling requirements; +- define resilience and recovery expectations; +- define accepted variations and exceptions. + +#### Minimum Genome Record + +```yaml +security_genome_record: + id: kg:genome:example-service + version: 1.0.0 + + ownership: + tenant_id: tenant-a + accountable_owner: team-example + operational_owner: platform-team + + purpose: + intent: "Provide document conversion for authorized tenant applications." + criticality: high + + identities: + workload_identity: spiffe://tenant-a.example/workload/document-converter + deployment_identity: pipeline:converter-release + + capabilities: + provides: + - document.convert + consumes: + - object-storage.read + - object-storage.write + - audit-event.publish + + communication: + ingress: + - caller: document-api + protocol: https + egress: + - destination: tenant-object-storage + protocol: https + - destination: audit-broker + protocol: tls + + data: + classifications: + - tenant-confidential + persistence: ephemeral + export_allowed: false + + provenance: + signed_artifact_required: true + approved_registry: registry.example + sbom_required: true + reproducible_build_preferred: true + + expected_behavior: + max_request_rate: 100/minute + external_network_access: false + interactive_shell: prohibited + privilege_escalation: prohibited + + recovery: + redeployable: true + maximum_recovery_time: PT15M + maximum_data_loss: PT0S + + tolerances: + - id: temporary-migration-egress + expires_at: 2026-09-01T00:00:00Z +``` + +### 9.2 Identity and Attestation Plane + +This plane establishes and reassesses subject identity. + +#### Identity Classes + +- human identity; +- service identity; +- workload identity; +- device identity; +- agent identity; +- infrastructure identity; +- deployment identity; +- organization identity. + +#### Required Properties + +- globally or compartment-unique identifier; +- tenant affiliation; +- issuer; +- authentication strength; +- attestation evidence; +- credential validity; +- owner; +- permitted capabilities; +- current trust posture; +- revocation state. + +#### Trust Posture + +Trust posture is computed rather than assigned permanently. + +```yaml +trust_posture: + subject_id: kg:subject:example + calculated_at: 2026-07-23T18:00:00Z + valid_until: 2026-07-23T18:05:00Z + + dimensions: + identity_assurance: 0.98 + runtime_integrity: 0.95 + configuration_integrity: 0.91 + behavioral_consistency: 0.72 + incident_exposure: 0.30 + + status: constrained + reasons: + - unexpected-egress-attempt +``` + +### 9.3 Membrane and Compartment Plane + +This plane establishes nested boundaries. + +#### Membrane Types + +1. platform edge membrane; +2. tenant membrane; +3. application membrane; +4. workload membrane; +5. data membrane; +6. management membrane; +7. supply-chain membrane. + +#### Boundary Controls + +- authenticated ingress; +- authenticated egress; +- protocol validation; +- policy enforcement; +- segmentation; +- encryption; +- rate control; +- content inspection where permitted; +- data-loss controls; +- management-path separation; +- response hooks. + +### 9.4 Sentinel and Evidence Plane + +Sentinels observe security-relevant behaviour. + +#### Sentinel Classes + +- edge sentinel; +- identity sentinel; +- admission sentinel; +- workload sentinel; +- kernel sentinel; +- network sentinel; +- API sentinel; +- data-access sentinel; +- secret sentinel; +- control-plane sentinel; +- supply-chain sentinel; +- application-domain sentinel. + +#### Observation Contract + +```yaml +immune_observation: + schema_version: 1.0 + observation_id: uuid + observed_at: 2026-07-23T18:00:00Z + + source: + sentinel_id: kg:sentinel:runtime-01 + subject_id: kg:subject:runtime-agent + integrity_state: attested + + scope: + platform_id: platform-eu-1 + tenant_id: tenant-a + compartment_id: app-documents + + actor: + subject_id: spiffe://tenant-a.example/workload/document-converter + trust_posture_ref: kg:trust:1234 + + target: + resource_id: kg:resource:external-network + operation: connect + + evidence: + - type: kernel-event + reference: evidence://event/9876 + + intent_relation: + expected: false + classification: prohibited + + assessment: + confidence: 0.97 + severity: high + novelty: known + potential_blast_radius: application + + proposed_response: + action: isolate + scope: workload + ttl: PT15M +``` + +### 9.5 Signal and Coordination Plane + +The Immune Signal Fabric transports authenticated security messages. + +#### Signal Types + +- observation; +- posture change; +- policy violation; +- integrity failure; +- attack hypothesis; +- response request; +- response authorization; +- action result; +- recovery status; +- escalation; +- countermeasure publication; +- memory update; +- audit challenge. + +#### Signal Properties + +Every signal must carry: + +- signal identifier; +- signal type; +- origin identity; +- tenant and compartment scope; +- issue time; +- expiry time; +- confidentiality class; +- evidence references; +- confidence; +- severity; +- deduplication key; +- permitted consumers; +- signature or equivalent integrity proof. + +#### Signal Isolation + +Signals are separated into: + +- tenant-private; +- tenant-shareable; +- platform-operational; +- platform-restricted; +- federated-defensive. + +Raw tenant evidence must not be elevated to platform or federation scope without policy authorization. + +### 9.6 Decision Plane + +The Decision Plane evaluates observations and determines response. + +#### Decision Inputs + +- security genome; +- current policy; +- trust posture; +- identity and attestation; +- observation evidence; +- asset criticality; +- tenant risk profile; +- active incidents; +- historical outcomes; +- response authority; +- tolerance records; +- legal and operational constraints. + +#### Decision Output + +```yaml +immune_decision: + decision_id: uuid + decided_at: 2026-07-23T18:00:02Z + + scope: + tenant_id: tenant-a + compartment_id: app-documents + + hypothesis: + type: compromised-workload + confidence: 0.91 + + authorized_response: + action: isolate + target: spiffe://tenant-a.example/workload/document-converter + ttl: PT15M + authority: tenant-immune-node + rollback: automatic + + required_follow_up: + - collect-memory-image + - rotate-workload-credentials + - reconstitute-workload + - validate-service-health + + explanation: + policy_refs: + - kg:policy:no-external-egress + evidence_refs: + - evidence://event/9876 +``` + +### 9.7 Response Plane + +The Response Plane executes defensive actions. + +#### Response Ladder + +| Level | Response | Typical effect | +|---|---|---| +| R0 | Observe | Collect additional evidence | +| R1 | Challenge | Require stronger authentication or attestation | +| R2 | Constrain | Reduce permissions, destinations or rate | +| R3 | Degrade | Disable nonessential functions | +| R4 | Isolate | Quarantine a subject, workload or segment | +| R5 | Revoke | Invalidate sessions, credentials or authority | +| R6 | Terminate | Stop malicious or uncertain execution | +| R7 | Reconstitute | Replace with known-good state | +| R8 | Restore | Recover validated service and data | +| R9 | Immunize | Distribute tested countermeasures | + +#### Response Safety Envelope + +Every automated action requires: + +- authorized issuer; +- permitted scope; +- maximum blast radius; +- time-to-live; +- rollback procedure; +- evidence threshold; +- expected outcome; +- validation condition; +- escalation condition; +- audit record. + +### 9.8 Recovery and Reconstitution Plane + +Recovery is an architectural peer of detection and response. + +#### Recovery Capabilities + +- immutable redeployment; +- secret rotation; +- session invalidation; +- data restoration; +- configuration reconciliation; +- dependency substitution; +- tenant evacuation; +- cluster evacuation; +- continuity mode; +- post-recovery validation. + +#### Recovery States + +```text +healthy +→ suspected +→ constrained +→ isolated +→ eradication +→ reconstitution +→ validation +→ restored +→ monitored +→ healthy +``` + +A component must not return directly from `isolated` to `healthy` without validation. + +### 9.9 Memory and Adaptation Plane + +The Memory Plane retains and evaluates security knowledge. + +#### Memory Objects + +- observation pattern; +- incident; +- attack hypothesis; +- attack path; +- affected asset; +- vulnerability; +- defensive technique; +- policy; +- countermeasure; +- response action; +- response outcome; +- residual risk; +- exception; +- lesson; +- invalidated conclusion. + +#### Memory Graph + +```mermaid +flowchart LR + O["Observation"] --> E["Evidence"] + E --> H["Attack Hypothesis"] + H --> A["Affected Asset"] + H --> T["Attack Technique"] + T --> C["Countermeasure"] + C --> R["Response Action"] + R --> OUT["Outcome"] + OUT --> L["Lesson"] + L --> P["Policy or Playbook Update"] + P --> C + OUT --> RR["Residual Risk"] +``` + +#### Memory Governance + +Every memory object includes: + +- provenance; +- confidence; +- scope; +- tenant visibility; +- applicability; +- effective date; +- review date; +- expiry date; +- success evidence; +- counter-evidence; +- version; +- revocation state. + +--- + +## 10. Tenant Security Architecture + +Each tenant is represented as an immune compartment. + +```mermaid +flowchart TB + subgraph TENANT["Tenant Immune Compartment"] + TM["Tenant Membrane"] + TI["Tenant Identity Domain"] + TP["Tenant Policy Bundle"] + TW["Tenant Workloads"] + TD["Tenant Data Domains"] + TS["Tenant Sentinel Mesh"] + TN["Tenant Immune Node"] + TR["Tenant Response Effectors"] + TMEM["Tenant Immune Memory"] + TREC["Tenant Recovery Controller"] + + TM --> TW + TI --> TM + TI --> TW + TP --> TM + TP --> TN + TW --> TD + TW --> TS + TD --> TS + TS --> TN + TMEM --> TN + TN --> TR + TR --> TW + TR --> TM + TR --> TREC + TREC --> TW + TN --> TMEM + end +``` + +### 10.1 Tenant-Local Responsibilities + +The tenant immune system owns: + +- tenant-specific security intent; +- application and data policies; +- tenant identities and delegated roles; +- tenant-specific anomaly baselines; +- local incident correlation; +- local response decisions; +- tenant-private evidence; +- tenant-specific countermeasures; +- tenant recovery procedures. + +### 10.2 Platform Responsibilities + +The platform immune system owns: + +- platform availability and integrity; +- shared infrastructure; +- cluster and control-plane security; +- common identity and attestation services; +- baseline security controls; +- supply-chain controls; +- prevention of cross-tenant impact; +- platform incident coordination; +- federated countermeasure distribution. + +### 10.3 Tenant Sovereignty Boundary + +The platform may override tenant policy only when required to: + +- prevent cross-tenant compromise; +- preserve platform integrity; +- satisfy mandatory legal obligations; +- contain platform-level incidents; +- enforce agreed minimum security controls. + +Every override must be: + +- attributable; +- explainable; +- time-bounded where possible; +- auditable; +- visible to the tenant unless prohibited by law or active investigation constraints. + +--- + +## 11. Isolation Profiles + +Different workloads require different strengths of isolation. + +| Profile | Description | Typical realization | +|---|---|---| +| I0 Shared | Logical isolation for low-risk workloads | Namespace, identity and policy boundaries | +| I1 Reinforced | Stronger runtime and node separation | Sandboxed runtime, dedicated node pools | +| I2 Dedicated | Tenant-specific control and compute plane | Dedicated cluster or virtual cluster | +| I3 Sovereign | Independent authority and infrastructure boundary | Dedicated account, keys, control plane and operations | +| I4 Air-Gapped | Deliberately disconnected or highly mediated environment | Offline or broker-only exchange | + +Isolation profile selection considers: + +- data sensitivity; +- workload privilege; +- tenant risk; +- regulatory requirements; +- blast radius; +- recovery expectations; +- supply-chain trust; +- exposure to untrusted code; +- autonomous agent capabilities. + +--- + +## 12. Shared Service Brokerage + +Shared services must not become implicit trust bridges between tenants. + +Every shared service is accessed through a **brokered contract** containing: + +- authenticated subject; +- tenant context; +- declared purpose; +- permitted operations; +- rate and resource limits; +- data classification; +- isolation requirements; +- audit requirements; +- response integration; +- failure mode. + +Examples include: + +- object storage; +- message brokers; +- model inference; +- logging; +- email delivery; +- document conversion; +- secrets management; +- identity services. + +Shared service operators must not infer permission merely from network reachability. + +--- + +## 13. Admission and Deployment Education + +Biological immune systems distinguish tolerated self through developmental processes. Kings Guard applies an analogous admission process. + +Before a workload is admitted, the system verifies: + +- declared owner; +- tenant affiliation; +- signed artifact; +- approved provenance; +- dependency declarations; +- software bill of materials where required; +- known vulnerabilities against policy; +- requested privileges; +- intended communication; +- secrets requirements; +- data classifications; +- resource limits; +- recovery capability; +- observability hooks; +- response compatibility. + +### 13.1 Admission Outcomes + +- admitted; +- admitted with restrictions; +- admitted to observation-only environment; +- admitted temporarily; +- quarantined for analysis; +- rejected. + +### 13.2 Continuous Re-Education + +Admission is not permanent. + +Reassessment occurs when: + +- artifact changes; +- configuration changes; +- dependency changes; +- policy changes; +- ownership changes; +- risk classification changes; +- new vulnerability intelligence appears; +- behaviour diverges from intent. + +--- + +## 14. Control Loops + +### 14.1 Fast Local Loop + +Purpose: immediate containment. + +```text +sense +→ match local rule +→ apply reversible constraint +→ report observation and outcome +``` + +Target latency: milliseconds to seconds. + +Examples: + +- reject malformed input; +- block prohibited syscall; +- deny unapproved egress; +- throttle abusive request; +- isolate a process. + +### 14.2 Tenant Adaptive Loop + +Purpose: contextual tenant response. + +```text +correlate tenant observations +→ assess against tenant intent +→ select bounded response +→ observe outcome +→ update tenant memory +``` + +Target latency: seconds to minutes. + +Examples: + +- revoke a tenant session; +- restrict an application; +- rotate tenant credentials; +- isolate a tenant workload group; +- deploy a tenant-specific detection. + +### 14.3 Platform Coordination Loop + +Purpose: protect shared infrastructure and tenants. + +```text +aggregate platform signals +→ identify shared or cross-tenant impact +→ coordinate platform response +→ validate containment +→ distribute safe countermeasures +``` + +Target latency: seconds to hours. + +### 14.4 Strategic Learning Loop + +Purpose: improve future architecture and policy. + +```text +review incidents and outcomes +→ identify structural weaknesses +→ test improved controls +→ update genome, standards or architecture +→ measure long-term effectiveness +``` + +Target latency: days to quarters. + +--- + +## 15. Viable System Model Mapping + +| VSM function | Kings Guard responsibility | +|---|---| +| System 1 — Operations | Workload, application and tenant sentinels and effectors | +| System 2 — Coordination | Signal routing, deduplication, suppression and incident coordination | +| System 3 — Control | Tenant and platform response controllers | +| System 3* — Audit | Independent validation, forensic inspection and adversarial testing | +| System 4 — Intelligence | Threat research, simulation, adaptive policies and immune memory | +| System 5 — Policy | Security identity, principles, risk appetite and response authority | + +The same mapping applies recursively to: + +- workloads; +- applications; +- tenants; +- platforms; +- federated environments. + +--- + +## 16. Response Authority Model + +No component receives unlimited security authority. + +### 16.1 Authority Dimensions + +Authority is constrained by: + +- tenant; +- compartment; +- resource type; +- action type; +- maximum severity; +- maximum blast radius; +- time-to-live; +- evidence threshold; +- approval requirement; +- operating mode. + +### 16.2 Example Authority Grant + +```yaml +response_authority: + authority_id: kg:authority:tenant-isolator + subject_id: kg:subject:tenant-immune-node-a + + scope: + tenant_id: tenant-a + compartments: + - app-* + resource_types: + - workload + - service-identity + + permitted_actions: + - constrain + - isolate + - revoke-ephemeral-credential + + prohibited_actions: + - delete-persistent-data + - modify-platform-policy + - affect-other-tenant + + limits: + maximum_ttl: PT1H + maximum_concurrent_targets: 20 + minimum_confidence: 0.85 + + escalation_required_for: + - terminate + - restore-data + - revoke-human-admin +``` + +--- + +## 17. Defensive Posture Model + +The system maintains explicit defensive posture. + +| Posture | Meaning | Typical controls | +|---|---|---| +| Green | Normal healthy operation | Baseline observation and policy | +| Blue | Increased awareness | Additional telemetry and shorter trust leases | +| Amber | Credible local threat | Restricted capabilities and active investigation | +| Red | Active compromise | Isolation, revocation and reconstitution | +| Black | Platform viability threatened | Emergency segmentation and continuity mode | + +Posture may be set at: + +- workload; +- application; +- tenant; +- cluster; +- region; +- platform; +- federation. + +A higher-level posture does not automatically require every lower-level compartment to take identical action. Policies translate posture into context-specific controls. + +--- + +## 18. Failure Modes and Immune Pathologies + +### 18.1 Autoimmunity + +The system attacks legitimate behaviour. + +#### Causes + +- incorrect policy; +- incomplete intent; +- biased anomaly models; +- stale memory; +- excessive automation; +- missing tolerance records. + +#### Controls + +- shadow evaluation; +- simulation; +- canary enforcement; +- bounded authority; +- response leases; +- independent evidence; +- rollback; +- tenant appeal and override workflows. + +### 18.2 Immunodeficiency + +The system lacks sufficient coverage or response capability. + +#### Causes + +- missing sensors; +- unmonitored assets; +- broken signal paths; +- disabled effectors; +- expired policy; +- insufficient identity assurance. + +#### Controls + +- coverage measurement; +- mandatory minimum controls; +- sentinel health checks; +- control conformance tests; +- adversarial simulation; +- maturity assessments. + +### 18.3 Chronic Inflammation + +The environment remains permanently in elevated defensive mode. + +#### Consequences + +- alert fatigue; +- excessive cost; +- operational friction; +- degraded service; +- normalization of emergency access. + +#### Controls + +- posture expiry; +- response budgets; +- signal suppression; +- closure criteria; +- de-escalation validation; +- periodic review. + +### 18.4 Immune Evasion + +An attacker suppresses or imitates legitimate security signals. + +#### Controls + +- independent observation paths; +- remote attestation; +- missing-signal detection; +- immutable evidence; +- cross-sensor correlation; +- periodic re-attestation; +- protected time sources. + +### 18.5 Malignant Growth + +A legitimate capability expands beyond its intended purpose. + +Examples: + +- privilege accumulation; +- data hoarding; +- unauthorized dependency growth; +- uncontrolled agent autonomy; +- resource monopolization; +- hidden external communication. + +Controls compare actual scope with intended scope and trigger review when expansion is unexplained. + +### 18.6 Memory Poisoning + +False or adversarial evidence corrupts defensive learning. + +#### Controls + +- provenance; +- confidence scoring; +- source reputation; +- independent confirmation; +- quarantined learning; +- reversible policy rollout; +- counter-evidence; +- memory revocation. + +### 18.7 Cytokine Storm + +Security responses amplify one another and cause disproportionate damage. + +#### Controls + +- global response budgets; +- action deduplication; +- rate limits; +- circuit breakers; +- hierarchical coordination; +- maximum blast radius; +- emergency human control. + +--- + +## 19. Security Data Model + +### 19.1 Core Entities + +```mermaid +erDiagram + TENANT ||--o{ COMPARTMENT : contains + COMPARTMENT ||--o{ SUBJECT : hosts + COMPARTMENT ||--o{ RESOURCE : protects + SUBJECT ||--o{ OBSERVATION : produces + RESOURCE ||--o{ OBSERVATION : concerns + OBSERVATION }o--o{ EVIDENCE : references + OBSERVATION ||--o{ DECISION : informs + DECISION ||--o{ RESPONSE_ACTION : authorizes + RESPONSE_ACTION ||--o{ RESPONSE_OUTCOME : produces + RESPONSE_OUTCOME ||--o{ MEMORY_OBJECT : informs + SECURITY_GENOME ||--o{ SUBJECT : defines + SECURITY_GENOME ||--o{ RESOURCE : defines + POLICY ||--o{ DECISION : constrains + TRUST_POSTURE ||--o{ DECISION : informs +``` + +### 19.2 Separation Requirements + +The data model must preserve separation among: + +- raw evidence; +- normalized observation; +- attack hypothesis; +- decision; +- response authorization; +- action execution; +- outcome; +- lesson; +- policy change. + +--- + +## 20. Policy Architecture + +Policies are layered. + +### 20.1 Policy Layers + +1. **NetKingdom constitutional policy** + Defines non-negotiable security principles. + +2. **Kings Guard platform policy** + Defines platform-wide minimum controls. + +3. **Environment policy** + Defines region, cluster or sovereign-environment rules. + +4. **Tenant policy** + Defines tenant-specific requirements. + +5. **Application policy** + Defines application behaviour. + +6. **Workload policy** + Defines concrete runtime permissions. + +7. **Temporary incident policy** + Defines time-bounded emergency controls. + +### 20.2 Policy Resolution + +A lower layer may strengthen a higher-layer requirement but may weaken it only through an authorized exception. + +Policy decisions must expose: + +- effective policies; +- precedence; +- exceptions; +- reason; +- decision inputs; +- resulting constraints. + +--- + +## 21. Evidence Architecture + +Evidence is treated as a protected asset. + +### 21.1 Evidence Requirements + +- immutable or tamper-evident storage; +- accurate time reference; +- source identity; +- integrity proof; +- tenant classification; +- access control; +- retention policy; +- legal hold capability; +- minimization; +- chain of custody where required. + +### 21.2 Evidence Zones + +- ephemeral local evidence; +- tenant incident evidence; +- platform incident evidence; +- audit evidence; +- forensic archive; +- shareable defensive intelligence. + +--- + +## 22. Observability + +Security observability includes both threat state and immune-system health. + +### 22.1 Threat Observability + +- unauthorized attempts; +- policy violations; +- anomalous behaviour; +- integrity failures; +- attack-path progression; +- credential abuse; +- data access deviations; +- cross-compartment interaction. + +### 22.2 Immune-System Observability + +- sentinel coverage; +- signal delivery latency; +- decision latency; +- response latency; +- failed effectors; +- stale trust posture; +- policy distribution lag; +- memory freshness; +- recovery readiness; +- false-positive rate; +- rollback success; +- response amplification. + +### 22.3 Mandatory Health Signals + +Every security component publishes: + +- liveness; +- readiness; +- identity; +- software version; +- policy version; +- attestation state; +- last successful observation or action; +- degraded-mode state. + +--- + +## 23. Key Performance Indicators + +### 23.1 Protection + +- percentage of assets with current genome records; +- percentage of subjects with attested identity; +- policy coverage by compartment; +- sentinel coverage; +- percentage of prohibited paths technically blocked. + +### 23.2 Detection + +- mean time to observe; +- mean time to correlate; +- proportion of incidents detected locally; +- evidence completeness; +- detection confidence calibration. + +### 23.3 Containment + +- mean time to constrain; +- mean time to isolate; +- containment success rate; +- average containment blast radius; +- cross-tenant incident count. + +### 23.4 Recovery + +- mean time to reconstitute; +- mean time to validate; +- percentage of workloads reproducibly redeployable; +- recovery test success rate; +- restoration integrity failure rate. + +### 23.5 Regulation + +- false-positive response rate; +- rollback success rate; +- number of expired temporary controls; +- number of chronic elevated-posture compartments; +- automated action override rate; +- response budget violations. + +### 23.6 Learning + +- countermeasure effectiveness; +- memory objects with valid provenance; +- stale-memory percentage; +- time from incident to tested policy improvement; +- repeated-incident rate. + +--- + +## 24. Capability Decomposition + +```text +kings-guard/ +├── architecture/ +│ ├── NetKingdomImmuneArchitecture.md +│ ├── TrustArchitecture.md +│ ├── TenantCompartmentArchitecture.md +│ ├── ImmuneControlLoops.md +│ └── DeploymentProfiles.md +│ +├── security-genome/ +│ ├── intent-registry/ +│ ├── capability-registry/ +│ ├── policy-canon/ +│ ├── provenance-registry/ +│ └── schemas/ +│ +├── identity-immunity/ +│ ├── human-identity/ +│ ├── workload-identity/ +│ ├── agent-identity/ +│ ├── attestation/ +│ ├── trust-posture/ +│ └── contracts/ +│ +├── compartment-control/ +│ ├── tenant-isolation/ +│ ├── application-boundaries/ +│ ├── workload-boundaries/ +│ ├── data-boundaries/ +│ ├── shared-service-brokers/ +│ └── isolation-profiles/ +│ +├── sentinel-mesh/ +│ ├── edge-sentinel/ +│ ├── identity-sentinel/ +│ ├── admission-sentinel/ +│ ├── runtime-sentinel/ +│ ├── network-sentinel/ +│ ├── data-sentinel/ +│ └── observation-schema/ +│ +├── immune-coordination/ +│ ├── signal-fabric/ +│ ├── tenant-immune-node/ +│ ├── platform-immune-node/ +│ ├── federation/ +│ └── signal-schema/ +│ +├── immune-decision/ +│ ├── policy-evaluation/ +│ ├── risk-evaluation/ +│ ├── attack-hypothesis/ +│ ├── response-selection/ +│ └── decision-schema/ +│ +├── immune-response/ +│ ├── response-orchestrator/ +│ ├── effectors/ +│ ├── authority-control/ +│ ├── escalation/ +│ └── response-schema/ +│ +├── immune-recovery/ +│ ├── reconciliation/ +│ ├── reconstitution/ +│ ├── secret-rotation/ +│ ├── data-restoration/ +│ └── validation/ +│ +├── immune-memory/ +│ ├── evidence-store/ +│ ├── incident-graph/ +│ ├── countermeasure-graph/ +│ ├── outcome-learning/ +│ ├── memory-federation/ +│ └── memory-governance/ +│ +├── immune-regulation/ +│ ├── tolerance-control/ +│ ├── safety-envelopes/ +│ ├── response-budgets/ +│ ├── simulation/ +│ ├── audit/ +│ └── emergency-control/ +│ +└── reference-implementations/ + ├── kubernetes/ + ├── vm-platform/ + ├── serverless/ + ├── edge/ + └── sovereign/ +``` + +--- + +## 25. Stable Architecture Contracts + +The architecture should stabilize contracts before selecting implementations. + +### 25.1 Required Contracts + +- Identity Contract; +- Attestation Contract; +- Trust Posture Contract; +- Security Genome Contract; +- Immune Observation Contract; +- Immune Signal Contract; +- Decision Contract; +- Response Authority Contract; +- Effector Contract; +- Response Outcome Contract; +- Recovery Contract; +- Memory Object Contract; +- Tenant Federation Contract; +- Audit Challenge Contract. + +### 25.2 Effector Contract + +```yaml +effector_request: + request_id: uuid + decision_ref: kg:decision:123 + target_ref: kg:subject:456 + action: isolate + scope: workload + ttl: PT15M + authority_ref: kg:authority:tenant-isolator + expected_outcome: "No network or workload execution outside forensic channel." + rollback: + mode: automatic + condition: "ttl-expired or explicit-release" + validation: + required: true + checks: + - network-isolation-confirmed + - execution-suspended +``` + +```yaml +effector_result: + request_id: uuid + effector_id: kg:effector:runtime-01 + started_at: 2026-07-23T18:00:03Z + completed_at: 2026-07-23T18:00:04Z + status: successful + observed_outcome: + network_isolated: true + execution_suspended: true + evidence_refs: + - evidence://action/123 +``` + +--- + +## 26. Deployment Profiles + +### 26.1 Shared Kubernetes Profile + +Suitable for: + +- moderate-risk tenants; +- standard SaaS applications; +- stateless services. + +Typical characteristics: + +- shared cluster; +- tenant namespaces; +- workload identities; +- network policies; +- admission control; +- runtime sentinels; +- tenant-specific policy bundles; +- shared platform immune node; +- logical tenant memory separation. + +### 26.2 Reinforced Kubernetes Profile + +Suitable for: + +- sensitive workloads; +- untrusted code; +- autonomous agents. + +Typical characteristics: + +- virtual clusters or dedicated node pools; +- sandboxed runtimes; +- tenant-specific trust domains; +- stronger egress mediation; +- dedicated tenant immune node; +- isolated evidence stores. + +### 26.3 Dedicated Tenant Profile + +Suitable for: + +- high-value tenants; +- strict regulatory environments; +- large blast-radius concerns. + +Typical characteristics: + +- dedicated cluster; +- dedicated keys; +- dedicated tenant control plane; +- tenant-specific recovery environment; +- platform federation through signed defensive signals. + +### 26.4 Sovereign Profile + +Suitable for: + +- national, critical-infrastructure or highly regulated contexts. + +Typical characteristics: + +- independent cloud account or physical environment; +- tenant-controlled roots of trust; +- local operations; +- restricted federation; +- explicit intelligence exchange; +- independent audit. + +### 26.5 Edge Profile + +Suitable for: + +- intermittently connected environments; +- remote installations; +- industrial or physical systems. + +Typical characteristics: + +- strong local innate loop; +- cached policy; +- bounded autonomous response; +- delayed evidence synchronization; +- local recovery; +- federation after reconnection. + +--- + +## 27. Example Incident Flow + +### Scenario + +A tenant workload attempts an external connection that is not declared in its Security Genome. + +```mermaid +sequenceDiagram + participant W as Workload + participant S as Runtime Sentinel + participant N as Tenant Immune Node + participant D as Decision Engine + participant R as Regulation Controller + participant E as Network Effector + participant M as Immune Memory + participant H as Recovery Controller + + W->>S: Attempt prohibited external connection + S->>S: Block attempt using local rule + S->>N: Publish observation and evidence + N->>D: Request contextual assessment + D->>D: Compare identity, intent, posture and history + D->>R: Propose temporary workload isolation + R->>R: Validate authority, blast radius and TTL + R->>E: Authorize isolation + E->>W: Isolate workload + E->>N: Return action outcome + N->>H: Request credential rotation and reconstitution + H->>W: Replace with known-good workload + H->>N: Return validation result + N->>M: Store evidence, action and outcome + M->>D: Update future decision context +``` + +### Result + +- the local attempt is blocked immediately; +- the tenant compartment contains the possible compromise; +- credentials are rotated; +- the workload is replaced rather than merely restarted; +- the restored workload is validated; +- the incident becomes governed tenant memory; +- a shareable attack characteristic may be submitted to platform memory without exporting tenant-private evidence. + +--- + +## 28. Federation and Collective Immunity + +Federated environments may share defensive knowledge without sharing unrestricted telemetry. + +### 28.1 Shareable Objects + +- component vulnerability; +- attack technique; +- malicious artifact digest; +- defensive rule; +- mitigation guidance; +- response outcome summary; +- anonymized behaviour characteristic. + +### 28.2 Non-Shareable by Default + +- raw tenant logs; +- tenant data content; +- user identifiers; +- business process details; +- tenant-specific topology; +- unrestricted forensic images; +- confidential incident narrative. + +### 28.3 Federation Requirements + +- signed objects; +- source identity; +- confidence; +- scope; +- handling classification; +- expiry; +- revocation; +- compatibility information; +- policy-controlled import; +- quarantine before automatic enforcement. + +--- + +## 29. Implementation Independence + +Potential implementations may include: + +- human identity providers; +- workload identity and attestation systems; +- policy engines; +- admission controllers; +- eBPF runtime sensors; +- service meshes; +- network policy engines; +- message brokers; +- evidence stores; +- graph databases; +- SIEM and SOAR systems; +- backup and restore systems; +- infrastructure reconciliation systems. + +No implementation becomes part of the constitutional architecture merely because it is selected for an initial deployment. + +Each implementation must map to one or more Kings Guard capabilities and conform to the corresponding contracts. + +--- + +## 30. Security Assurance + +### 30.1 Continuous Assurance + +The architecture requires continuous validation of: + +- identity issuance; +- attestation; +- policy enforcement; +- network boundaries; +- workload restrictions; +- response authority; +- recovery capability; +- evidence integrity; +- signal isolation; +- federation controls. + +### 30.2 Adversarial Validation + +The system should support: + +- policy unit tests; +- architecture conformance tests; +- attack simulations; +- chaos-security experiments; +- credential compromise exercises; +- tenant-isolation tests; +- recovery exercises; +- memory-poisoning tests; +- response-amplification tests. + +### 30.3 Independent Audit Path + +Audit components must be able to challenge operational security conclusions. + +The audit path should be organizationally and technically separated from the components it validates where practical. + +--- + +## 31. Incremental Realization Roadmap + +### Phase 1 — Security Genome and Identity Foundation + +Deliver: + +- tenant, subject and resource identifiers; +- workload identity; +- Security Genome schema; +- baseline policy hierarchy; +- signed deployment provenance; +- initial trust posture model. + +Success condition: + +Every protected workload has an attributable identity and declared intended behaviour. + +### Phase 2 — Compartment and Membrane Foundation + +Deliver: + +- tenant isolation profiles; +- ingress and egress policy; +- shared-service brokerage; +- management-plane separation; +- tenant-specific encryption and secret boundaries. + +Success condition: + +A tenant compromise cannot trivially cross into another tenant. + +### Phase 3 — Sentinel and Signal Mesh + +Deliver: + +- observation schema; +- edge, identity, runtime and network sentinels; +- tenant-scoped signal transport; +- evidence references; +- sentinel health monitoring. + +Success condition: + +Security-relevant behaviour is attributable, normalized and routed to the correct compartment. + +### Phase 4 — Tenant Immune Nodes + +Deliver: + +- tenant-local correlation; +- policy evaluation; +- trust posture integration; +- response recommendations; +- tenant-private memory. + +Success condition: + +Common tenant incidents can be assessed without central manual correlation. + +### Phase 5 — Bounded Automated Response + +Deliver: + +- response authority model; +- reversible effectors; +- response leases; +- rollback; +- action validation; +- response budgets. + +Success condition: + +Selected high-confidence incidents can be contained automatically without uncontrolled blast radius. + +### Phase 6 — Recovery and Reconstitution + +Deliver: + +- immutable workload replacement; +- secret rotation; +- recovery workflows; +- restoration validation; +- recovery readiness metrics. + +Success condition: + +Compromised workloads can be replaced and validated predictably. + +### Phase 7 — Adaptive Memory + +Deliver: + +- incident graph; +- countermeasure graph; +- response outcome learning; +- policy improvement workflow; +- memory review and decay. + +Success condition: + +Past incidents measurably improve future detection, containment and recovery. + +### Phase 8 — Federated Collective Immunity + +Deliver: + +- shareable intelligence schema; +- signed federation; +- import quarantine; +- tenant privacy controls; +- countermeasure distribution. + +Success condition: + +Multiple environments can share useful defensive knowledge without exposing tenant-private evidence. + +--- + +## 32. Initial Repository Deliverables + +The initial `kings-guard` repository should contain: + +1. `INTENT.md` +2. `NetKingdomImmuneArchitecture.md` +3. `SecurityGenomeSpecification.md` +4. `IdentityAndAttestationContract.md` +5. `TenantCompartmentStandard.md` +6. `ImmuneObservationSchema.md` +7. `ImmuneSignalSchema.md` +8. `ResponseAuthorityStandard.md` +9. `EffectorInterfaceSpecification.md` +10. `ImmuneMemoryModel.md` +11. `DeploymentProfiles.md` +12. `ThreatAndFailureModeCatalog.md` +13. `ImplementationRoadmap.md` +14. `ArchitectureDecisionRecords/` + +--- + +## 33. Architectural Decisions + +### AD-001 — Self Is Attested Intent-Conformant Identity + +A subject is not trusted because it is internal. It is treated as self only while its identity, state and behaviour remain consistent with declared intent and policy. + +### AD-002 — Tenants Are Immune Compartments + +Every tenant has an explicit security boundary, policy scope, evidence scope, response authority and memory scope. + +### AD-003 — Security Is Recursive + +The same observation, decision, response, recovery and learning pattern applies from workload to federation level. + +### AD-004 — Evidence Is Distinct From Interpretation + +Raw evidence, observations, hypotheses, decisions and actions are separate entities. + +### AD-005 — Automated Responses Are Bounded + +Every automated action is limited by scope, authority, duration, evidence threshold and rollback requirements. + +### AD-006 — Recovery Is a First-Class Security Capability + +A security architecture is incomplete without tested restoration and reconstitution. + +### AD-007 — Memory Is Governed and Reversible + +Learned security knowledge requires provenance, confidence, scope, review, expiry and revocation. + +### AD-008 — Shared Services Are Brokered + +Shared services never create implicit cross-tenant trust. + +### AD-009 — Architecture Contracts Outlive Products + +Implementations may change without changing the stable Kings Guard capability model. + +--- + +## 34. Open Questions + +1. How should trust posture dimensions be normalized across different runtime types? +2. Which response actions may be authorized autonomously at each recursive level? +3. Which evidence classes may be federated across tenants? +4. How should tenants inspect or challenge platform-level security overrides? +5. Which Security Genome fields are mandatory for initial admission? +6. How should agent autonomy be represented as a bounded capability? +7. How should memory confidence decay over time? +8. Which isolation profiles should be mandatory for untrusted code execution? +9. How should security response budgets be calculated? +10. How should business continuity requirements influence defensive posture? +11. How should the architecture integrate with the wider NetKingdom identity and policy canon? +12. Which components belong in `kings-guard`, and which should remain independent reusable repositories? + +--- + +## 35. Definition of Architectural Success + +The Kings Guard architecture is successful when the platform can demonstrate that: + +- every significant subject is identifiable; +- intended behaviour is explicitly declared; +- tenant boundaries are technically enforceable; +- security observations are attributable and contextualized; +- local disturbances can be contained locally; +- high-impact actions require proportionally stronger authority; +- compromised components can be reconstituted; +- recovery outcomes are validated; +- incidents improve future protection; +- tenant evidence remains appropriately isolated; +- collective learning does not become collective surveillance; +- defensive automation remains inspectable, reversible and governable. + +--- + +## 36. Summary + +Kings Guard Security implements the NetKingdom immune-security concept as a recursive, multi-tenant control architecture. + +Its defining sequence is: + +```text +identity +→ intent +→ observation +→ assessment +→ bounded response +→ recovery +→ validation +→ memory +``` + +Its defining structural principles are: + +- identity instead of location-based trust; +- compartmentation instead of a trusted interior; +- local autonomous response with bounded authority; +- recovery as a peer of prevention and detection; +- evidence separated from interpretation; +- adaptive memory with provenance and decay; +- tenant sovereignty constrained by platform viability; +- replaceable implementations behind stable architecture contracts. + +The result is not merely a collection of security products. It is a governed security organism designed to remain viable under continuous change, uncertainty and attack. diff --git a/workplans/KG-WP-0001-statehub-bootstrap.md b/workplans/KG-WP-0001-statehub-bootstrap.md new file mode 100644 index 0000000..a97beb1 --- /dev/null +++ b/workplans/KG-WP-0001-statehub-bootstrap.md @@ -0,0 +1,77 @@ +--- +id: KG-WP-0001 +type: workplan +title: "Bootstrap State Hub integration" +domain: infotech +repo: kings-guard +status: finished +owner: codex +topic_slug: netkingdom +created: "2026-07-23" +updated: "2026-07-23" +state_hub_workstream_id: "b7ff79b9-ae27-4a46-a782-49482392eb83" +--- + +# Bootstrap State Hub integration + +Adaptive immune security control plane for complex multi-tenant cloud environments. + +## Review Generated Integration Files + +```task +id: KG-WP-0001-T01 +status: done +priority: high +state_hub_task_id: "add34171-9f18-48b9-a88e-07ea34cb6382" +``` + +Review `INTENT.md`, `SCOPE.md`, `AGENTS.md`, and `.custodian-brief.md`. +Replace generated placeholders with repo-specific facts where needed. + +**Done 2026-07-23:** Added a repo-specific `INTENT.md`, rewrote `SCOPE.md` +from the generated placeholder into an explicit boundary for adaptive security +assessment/response, extended `AGENTS.md` with the repo's actual docs-first +workflow, and confirmed `.custodian-brief.md` is adequate as generated. +Corrected the generated `topic_slug` from `custodian` to `netkingdom` so the +repo's first workplans align with the broader security ecosystem. + +## Verify Local Developer Workflow + +```task +id: KG-WP-0001-T02 +status: done +priority: high +state_hub_task_id: "17fb3a0c-91c5-4b45-967e-962ef6c89ac5" +``` + +Identify the repo's install, test, lint, build, and run commands. Add or refine +those commands in the agent instructions so future coding sessions can verify +changes confidently. + +**Done 2026-07-23:** Documented the current repo reality in `AGENTS.md`: +there is no runtime yet, so verification is `git diff --check` plus focused +document review and `statehub fix-consistency` after workplan edits. Explicitly +noted that install/test/lint/run commands should be added only when executable +code lands. + +## Seed First Real Workplan + +```task +id: KG-WP-0001-T03 +status: done +priority: medium +state_hub_task_id: "5b5f56d9-7e89-43b6-94c3-db4461e9eed4" +``` + +Create the first implementation workplan for the repository's most important +next change. After workplan file updates, run the sync locally from this repo +checkout: + +```bash +statehub fix-consistency +``` + +**Done 2026-07-23:** Created `KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md` +to define the first substantive strand: canonical immune contracts, adjacent +security boundaries, a minimal posture loop, and a first pilot integration +lane. Sync to State Hub follows this bootstrap closeout. diff --git a/workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md b/workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md new file mode 100644 index 0000000..e28bd1d --- /dev/null +++ b/workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md @@ -0,0 +1,115 @@ +--- +id: KG-WP-0002 +type: workplan +title: "Canonical immune contracts and first posture pilot" +domain: infotech +repo: kings-guard +status: ready +owner: codex +topic_slug: netkingdom +created: "2026-07-23" +updated: "2026-07-23" +quality_dor: DoR-Ok +quality_dor_at: "2026-07-23" +quality_dor_by: "codex" +state_hub_workstream_id: "5c5c5a26-dfca-4d42-86a7-b87877677207" +--- + +# Canonical immune contracts and first posture pilot + +Establish `kings-guard` as the adaptive security layer that sits beside the +existing NetKingdom security lanes instead of competing with them. The first +strand should produce stable contracts and one narrow posture pilot before any +broader implementation or automation claims. + +This workplan deliberately keeps authority boundaries clear: + +- `key-cape` remains identity and attestation input. +- `flex-auth` remains authorization policy and final allow/deny owner. +- `railiance-platform` and `secrets-engine` remain secret-custody and delivery + owners. +- `ops-warden` remains the operational SSH certificate lane. +- `kings-guard` evaluates health/posture, emits signals, and requests bounded + response. + +## Task: Define canonical immune contracts + +```task +id: KG-WP-0002-T01 +status: todo +priority: high +state_hub_task_id: "9982a3b4-1e65-493a-9b61-322f23d4fd2d" +``` + +Write the first repo-owned canonical contract for the core vocabulary: +`security_genome`, `security_phenotype`, `immune_observation`, +`immune_signal`, `effector_request`, `tolerance`, `inflammation`, and +`immune_memory`. + +Done when: + +- each term has a concise, non-overlapping definition; +- producer/consumer expectations are named for each contract; +- the contracts are usable without requiring one particular product stack. + +## Task: Write adjacent-system boundary contract + +```task +id: KG-WP-0002-T02 +status: todo +priority: high +state_hub_task_id: "0c44035e-b1b8-4f5d-8a6c-e6514b4bc897" +``` + +Author a boundary document that shows how `kings-guard` consumes evidence from +`key-cape`, `flex-auth`, `secrets-engine`, `ops-warden`, and Railiance runtime +layers without taking over their responsibilities. + +Done when: + +- each adjacent system's primary authority is stated explicitly; +- `kings-guard` inputs, outputs, and non-goals are named per system; +- tenant-isolation and non-secret evidence rules are captured. + +## Task: Scaffold a minimal posture loop + +```task +id: KG-WP-0002-T03 +status: todo +priority: high +state_hub_task_id: "c88a7da6-a9ff-4bd9-ba47-7c199321666b" +``` + +Create the initial repository structure for a minimal posture engine or schema +package that can ingest normalized observations, compare them against declared +intent, and emit typed posture/signal results. + +Done when: + +- the repo has a clear implementation layout rather than only prose; +- one sample input/output path exists end-to-end for observation -> posture -> + signal; +- tests or fixture-driven validation prove the contract shape is stable. + +## Task: Choose and specify the first pilot lane + +```task +id: KG-WP-0002-T04 +status: todo +priority: medium +state_hub_task_id: "77e1dc69-9902-4381-8028-ce1cfac7e9d5" +``` + +Pick one narrow pilot integration lane and specify it precisely. Preferred +pilot order: + +1. `ops-warden` sign-request posture hinting +2. `secrets-engine` exec-delivery posture hinting +3. Railiance workload reconstitution signal generation + +Done when: + +- the chosen lane has a concrete request/response flow; +- the pilot can run without granting `kings-guard` secret, identity, or final + authorization authority; +- bounded-response and rollback expectations are documented.