kings-guard/specs/NetKingdomImmuneArchitecture.md

---
title: NetKingdom Immune Architecture
document_id: KG-ARCH-IMMUNE
version: 0.2.0
status: Draft
date: 2026-09-02
repo: kings-guard
brand: Kings Guard Security
ecosystem: NetKingdom
owners:
  - Kings Guard Security Architecture
classification: Public
layer_sweep: KG-WP-0004
standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
---

# NetKingdom Immune Architecture

> **Layer note (2026-09-02, KG-WP-0004).** kings-guard is a **Staff**-layer
> repository under the NetKingdom Security Layer Model
> `net-kingdom/canon/standards/security-layer-model_v0.7.md` (**accepted**;
> assented in `decisions/decisions.md` KG-DEC-2026-001 against v0.1). Catalog
> (v0.7 §4): adaptive defence and judgment; observation of Staff-reachable
> sources — identity and secret observation **pending**; **proposes**
> containment, which it does not own (§9.2). It **publishes** posture;
> `gate-house` defines authority meaning; `access-engine` renders it. Posture
> is not a privilege source. Immune memory is not a state plane (§3.4 rule 3).
> Remaining "control plane" wording in this file names a Kubernetes or
> platform API plane, never this repository. The vocabulary sweep that was
> `KG-IN-0002` is complete.

## 1. Purpose

This document is the **estate map** for NetKingdom immune security. The
`kings-guard` repository implements the **Staff** slice: observation,
judgment, posture publication, bounded proposals, and governed memory.
Identity issuance, the authorization decision, secret custody, and
actuation belong to other layers — actuation is unowned and held at zero.

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 disturbances near their origin and *propose* containment
   (Engine/PEP perform it, when an actuation surface exists);
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 defence architecture**.
`kings-guard` is the Staff repository in that architecture: it observes,
judges, and proposes. It is not an Engine-layer control plane and not a
decision point.

The estate cycle, with layer:

```text
declare healthy intent                    # owners; Staff consumes the genome
→ establish and attest identity           # Tooling (key-cape) / Engine (user-engine)
→ observe actual behaviour                # Staff (kings-guard)
→ compare behaviour with intent           # Staff
→ assess risk and confidence (posture)    # Staff publishes; gate-house defines meaning
→ propose bounded response                # Staff — never manufactures authority
→ decide                                  # Engine (access-engine), the only PDP
→ actuate                                 # Engine + PEP; surface unowned, held at zero
→ restore known-good operation            # Engine / runtime
→ validate the outcome
→ retain governed security memory         # Staff; not a state plane for other layers
```

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 document is an **estate map**. It names Staff, Engine, PEP, and Tooling
parts of the immune loop so they are not collapsed into `kings-guard`.

The `kings-guard` **repository** owns observation, judgment, posture
publication, bounded proposals, and governed immune memory. It does not own
identity issuance, authorization decisions, secret custody, or actuation.

The estate map also covers, in other layers:

- human, device, workload, service and agent identities (Tooling / Engine);
- authentication, authorization and continuous trust evaluation (Engine PDP);
- tenant compartmentation, workload isolation, network and data boundaries
  (Engine / PEP / runtime);
- policy distribution and enforcement (Engine / PEP);
- admission control (Engine / PEP);
- runtime detection and security event transport (PEP / Staff observation);
- the single authorization decision point (Engine: `access-engine`);
- automated and human-approved response (Engine + PEP; actuation unowned);
- recovery and reconstitution (Engine / runtime);
- incident evidence custody (Engine: `audit-core`);
- adaptive security memory (Staff; not a state plane);
- cross-tenant defensive learning (Staff publication);
- security governance, 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;
- platform management plane (Kubernetes/API operators; not Staff);
- 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 **PEP-shaped** component authorized to perform a concrete defensive
action under a decision record (or a recorded stance). kings-guard does
not hold effectors. It emits an `effector_request` as a **proposal**.

Examples of actions a PEP might perform, once actuation exists:

- reject;
- throttle;
- isolate;
- revoke;
- terminate;
- rotate;
- restore;
- rebuild.

### 4.10 Immune Memory

Governed knowledge derived from observations, incidents, threat intelligence, countermeasures and response outcomes.

**Layer: Staff.** Memory is not a state plane. Other layers must not depend
on it at runtime unless it is catalogued as Tooling.

### 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 judgment | Tenant posture / immune node (Staff) |
| Adaptive immunity | Incident-specific learning | Posture, proposals, and governed memory (Staff) |
| Antibodies | Targeted countermeasures | Policy rules rendered by the PDP; Staff may propose |
| Complement system | Immediate action primitives | Response effectors (PEP-shaped; not Staff) |
| 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 **PEPs** apply an existing decision or a declared stance (§6.4 of
the layer model). Staff components emit bounded *proposals* and escalate
when:

- evidence is insufficient;
- impact may cross compartment boundaries;
- the proposal exceeds what local PEPs may already enforce;
- platform-level coordination is required.

A Staff node does not receive a standing isolate grant.

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

Where actuation exists, automated response should prefer temporary, scoped
and reversible controls. Irreversible or high-impact actions require
stronger evidence or approval.

kings-guard does not automate isolate. It proposes. The actuation surface
is unowned and held at zero.

### 6.7 Recovery Before Perfect Prevention

The system assumes that some controls will fail.

Every critical capability must have, as an **estate** property:

- containment (Engine + PEP; unowned today);
- 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 proposal scope (Staff) or a decision/stance (PEP);
- local memory (Staff; not a state plane);
- 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 STAFF["Staff — observe, judge, propose"]
        JUDGE["Posture and Phenotype Judgment"]
        SIGNAL["Immune Signal Fabric"]
        MEMORY["Governed Immune Memory"]
        PROPOSE["Bounded Response Proposals"]
    end

    subgraph ENGINE["Engine — facts, evidence, the only decision"]
        IDENTITY["Identity facts — user-engine / key-cape"]
        DECISION["access-engine — the only PDP"]
        AUDIT["audit-core — evidence custody"]
        ACTUATE["Actuation surface — unowned, held at zero"]
    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 — Staff judgment"]
        EFFECTORS["Tenant Response Effectors — PEP"]
        RECOVERY["Tenant Recovery — Engine / runtime"]
    end

    subgraph SHARED["Shared Platform Compartments"]
        BROKER["Brokered Shared Services"]
        INFRA["Compute, Network, Storage and Runtime"]
        PSENTINELS["Platform Sentinels"]
        PEFFECTORS["Platform Effectors — PEP"]
    end

    EXT --> MEMBRANE
    MEMBRANE --> APPLICATIONS

    GENOME --> IDENTITY
    GENOME --> JUDGE
    GENOME --> DECISION
    GENOME --> EDUCATION

    IDENTITY --> MEMBRANE
    IDENTITY --> APPLICATIONS
    EDUCATION --> APPLICATIONS

    APPLICATIONS --> SENTINELS
    INFRA --> PSENTINELS

    SENTINELS --> NODE
    NODE --> JUDGE
    NODE --> SIGNAL
    PSENTINELS --> SIGNAL

    SIGNAL --> JUDGE
    JUDGE --> PROPOSE
    JUDGE --> MEMORY
    PROPOSE --> DECISION
    SIGNAL --> DECISION
    RISK --> DECISION
    MEMORY --> JUDGE

    DECISION --> ACTUATE
    ACTUATE --> EFFECTORS
    ACTUATE --> PEFFECTORS

    EFFECTORS --> APPLICATIONS
    EFFECTORS --> MEMBRANE
    EFFECTORS --> RECOVERY
    PEFFECTORS --> INFRA

    RECOVERY --> APPLICATIONS
    SIGNAL --> MEMORY
    AUDIT --> DECISION

    APPLICATIONS <--> BROKER
```

Staff memory informs kings-guard's own later judgment and may be published as
evidence. It is not a runtime input to `access-engine` or to a PEP (§3.4 rule 3).
Actuation is drawn because the loop requires it; the surface is unowned and
held at zero (§9.2). No argument may assume isolation happens automatically.

---

---

## 9. Architectural Planes

The architecture is organized into nine orthogonal planes. Each plane states
its layer. Staff planes observe, judge, and propose. Engine planes decide,
hold facts, or custody evidence. Tooling holds identity and secrets. PEP is
a shape, not a plane: anything that causes a protected side effect. Actuation
is an Engine concept held at zero (§9.2).

| Plane | Layer |
| --- | --- |
| 9.1 Security Genome | Staff consumes; owners produce |
| 9.2 Identity and Attestation | Tooling (`key-cape`) + Engine (`user-engine`) |
| 9.3 Membrane and Compartment | Engine / PEP / runtime |
| 9.4 Sentinel and Evidence | Staff observes Staff-reachable sources; many sentinels are PEP/runtime |
| 9.5 Signal and Coordination | Staff |
| 9.6 Decision | Engine (`access-engine`) — the only PDP |
| 9.7 Response | Engine + PEP; actuation unowned |
| 9.8 Recovery | Engine / runtime |
| 9.9 Memory and Adaptation | Staff; not a state plane |

### 9.1 Security Genome Plane

**Layer: Staff consumes; workload and service owners produce.** kings-guard
does not run the intent registry.

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

**Layer: Tooling (`key-cape`) + Engine (`user-engine`).** Issuance is not
Staff. Trust-posture *publication* is Staff; a lifetime other layers consume
is an input claim to the PDP, not a Staff verdict.

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

**Layer: Engine / PEP / runtime.** Policy enforcement at a membrane is
PEP-shaped. kings-guard does not hold the boundary.

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 (platform API/operator plane; not Staff);
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

**Layer: Staff observes Staff-reachable sources.** Many sentinels run in
PEP/runtime. Identity and secret observation stay pending (blocked-clean):
no Tooling client is opened to fill them. A "control-plane sentinel" watches
a Kubernetes or platform control plane; it does not make kings-guard one.

Sentinels observe security-relevant behaviour. An observation is not an
interpretation: assessment and proposed response belong on phenotype,
posture, and signal, not on this record.

#### Sentinel Classes

- edge sentinel;
- identity sentinel;
- admission sentinel;
- workload sentinel;
- kernel sentinel;
- network sentinel;
- API sentinel;
- data-access sentinel;
- secret sentinel;
- control-plane sentinel (observes the Kubernetes/platform API plane; does not make kings-guard a control plane);
- 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
```

Phenotype, posture, and a bounded `effector_request` are derived later.
They are not fields of the observation.

### 9.5 Signal and Coordination Plane

**Layer: Staff.** Signals coordinate judgment and proposals. They are not
authorization.

The Immune Signal Fabric transports authenticated security messages.

#### Signal Types

- observation;
- posture change;
- policy violation;
- integrity failure;
- attack hypothesis;
- response request (Staff proposal);
- action result (PEP / Engine, when actuation exists);
- recovery status;
- escalation;
- countermeasure publication;
- memory update;
- audit challenge.

Authorization is not a signal type. The PDP renders a decision record. A
Staff signal may *request* a restrictive direction; it must not authorize.

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

**Layer: Engine (`access-engine`).** This is the estate's only policy
decision point (layer model §6). It is not a kings-guard output. Posture
is an input claim; it is not a verdict.

The Decision Plane renders authorization from authoritative inputs. Staff
does not determine response here.

`immune_decision` below is an **Engine artifact** — the `access-engine`
decision record — not a posture assessment. A Staff node is not the
`authority` that isolates.

#### 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
# Engine artifact (access-engine). Not a kings-guard posture record.
immune_decision:
  decision_id: uuid
  decided_at: 2026-07-23T18:00:02Z
  pdp: access-engine

  scope:
    tenant_id: tenant-a
    compartment_id: app-documents

  inputs:
    posture_ref: kg:posture:…
    genome_ref: kg:genome:…
    evidence_refs:
      - evidence://event/9876

  authorized_response:
    action: isolate
    target: spiffe://tenant-a.example/workload/document-converter
    ttl: PT15M
    authority: access-engine
    enforcement: pep
    # Actuation surface unowned and held at zero (§9.2). This field is the
    # intended Engine output, not a claim that isolation already happens.
    rollback: automatic

  explanation:
    policy_refs:
      - kg:policy:no-external-egress
```

### 9.7 Response Plane

**Layer: Engine + PEP. Actuation is unowned and held at zero (§9.2).**
kings-guard proposes the rungs; it does not execute them.

The Response Plane is where defensive *actions* would be performed, once an
actuation surface exists. Until then the ladder is a vocabulary of
**proposals** (Staff) and of **intended PEP actions** (Engine/PEP).

#### Response Ladder

| Level | Kind | Staff (propose) | Engine / PEP (execute, when actuation exists) |
|---|---|---|---|
| R0 | Observe | collect additional evidence | — |
| R1 | Challenge | request step-up | require stronger authentication or attestation |
| R2 | Constrain | propose reduced permissions, destinations or rate | reduce them under a decision record |
| R3 | Degrade | propose disabling nonessential functions | disable them under a decision record |
| R4 | Isolate | propose quarantine of a subject, workload or segment | quarantine under a decision record |
| R5 | Revoke | propose session/credential/authority invalidation | invalidate under a decision record |
| R6 | Terminate | propose stopping execution | stop it under a decision record |
| R7 | Reconstitute | request replacement with known-good state | replace (runtime / Engine) |
| R8 | Restore | request validated recovery | recover (runtime / Engine) |
| R9 | Immunize | publish a tested countermeasure as evidence | distribute only via policy the PDP renders |

R0 is Staff. R1–R9 change authority or runtime state; Staff may only
propose them. No argument may assume they happen automatically.

#### Response Safety Envelope

Every **PEP / actuation** action, when the surface exists, requires:

- a decision record from `access-engine`, or a recorded §6.4 stance;
- permitted scope;
- maximum blast radius;
- time-to-live;
- rollback procedure;
- evidence threshold;
- expected outcome;
- validation condition;
- escalation condition;
- audit record.

A Staff `effector_request` is not that action. It is the proposal that
the PDP may render.

### 9.8 Recovery and Reconstitution Plane

**Layer: Engine / runtime.** Staff may request reconstitution. It does not
redeploy, rotate, or evacuate.

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

**Layer: Staff.** Immune memory informs kings-guard's own later judgment and
may be published as evidence. No engine, PEP, or workload may read it as a
runtime input. Making it one is a §4 Tooling catalog change, not a quiet
edge from this plane into §9.6.

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 — Staff"]
        TR["Tenant Response Effectors — PEP"]
        TMEM["Tenant Immune Memory — Staff"]
        TREC["Tenant Recovery Controller — Engine"]

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

The Staff node judges and proposes. Effectors fire only on a decision
record from `access-engine`, or on a recorded PEP stance (§6.4). The arrow
`TN --> TR` is coordination, not a second PDP.

### 10.1 Tenant-Local Responsibilities

The tenant immune **Staff** surface owns:

- tenant-specific security intent (genome consumption);
- tenant-specific anomaly baselines;
- local incident correlation and judgment;
- bounded response *proposals*;
- tenant-private evidence references;
- tenant-specific countermeasures as published memory.

It does not own local response *decisions*. Those remain the one PDP.
A local PEP applying a prior decision, or a declared stance, is §6.4 — not
a second decision point.

Tenant identities, application policy administration, and recovery
procedures belong to Engine / Tooling / runtime, not to the Staff node.

### 10.2 Platform Responsibilities

The platform immune system owns:

- platform availability and integrity;
- shared infrastructure;
- cluster and Kubernetes-control-plane security (the platform API plane, not Staff);
- 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 (Engine + PEP; not a Staff isolate);
- 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 Kubernetes control and compute planes (cluster API, not Staff) | Dedicated cluster or virtual cluster |
| I3 Sovereign | Independent authority and infrastructure boundary | Dedicated account, keys, cloud/Kubernetes control plane and operations (tenant's own Engine/platform plane, not kings-guard) |
| 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 **PEP** enforcement of an existing decision or declared
stance. This is not kings-guard containing anything. The live example is
`qonto-assistant`'s deny-escalation lockout.

```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 (PEP, under existing policy — not a Staff grant).

### 14.2 Tenant Adaptive Loop

Purpose: contextual tenant response.

```text
correlate tenant observations
→ assess against tenant intent
→ emit a bounded proposal
→ (PDP decides; PEP acts, when actuation exists)
→ observe outcome
→ update tenant memory
```

Target latency: seconds to minutes.

Examples of **Staff proposals** (not actions this repository performs):

- request session revocation;
- request application restriction;
- request credential rotation;
- request isolation of a tenant workload group;
- publish 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
→ propose / coordinate platform response
→ validate a PEP containment outcome, when one exists
→ distribute safe countermeasures as evidence, not as extra authority
```

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 (observe) and PEP-shaped effectors (act, when actuation exists) |
| System 2 — Coordination | Signal routing, deduplication, suppression and incident coordination (Staff) |
| System 3 — Control | `access-engine` as PDP; PEP stance maps; not a Staff response controller |
| System 3* — Audit | Independent validation, forensic inspection and adversarial testing (`audit-core`, whitehat-security) |
| System 4 — Intelligence | Threat research, simulation, and governed immune memory (Staff; not a state plane) |
| System 5 — Policy | Doctrine (gate-house) compiled into the versioned policy package the PDP applies |

The same mapping applies recursively to:

- workloads;
- applications;
- tenants;
- platforms;
- federated environments.

---

## 16. Response Authority Model

No component receives unlimited security authority. A **Staff** node never
receives isolate, revoke, or terminate as a power it exercises. Those are
authority-changing operations: the PDP renders them, a PEP enforces them,
and the actuation surface is unowned today.

### 16.1 Authority Dimensions

Bounds on a future Engine/PEP grant (not on a Staff node):

- tenant;
- compartment;
- resource type;
- action type;
- maximum severity;
- maximum blast radius;
- time-to-live;
- evidence threshold;
- approval requirement;
- operating mode.

### 16.2 Example — Staff proposal, then Engine/PEP grant

```yaml
# Staff emits this. It is not an authorization.
effector_request:
  originating_observation_id: kg:obs:9876
  originating_signal_id: kg:sig:9876
  target_system: runtime-pep
  action: isolate
  authority_boundary: advisory_only
  restrictive_direction: request_containment
  requires_human_approval: false
  stream_completeness: unknown
  reason: "Genome-prohibited egress; propose workload quarantine."

# Engine/PEP grant, if and when actuation exists. Not issued to a Staff node.
response_authority:
  authority_id: kg:authority:tenant-isolator
  subject_id: kg:pep:runtime-isolator
  issued_by: access-engine
  decision_ref: kg:decision:123

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

---

## 17. Defensive Posture Model

**Layer: Staff publishes; gate-house defines authority meaning;
`access-engine` renders.** Posture is not a privilege source. It may reduce
authority, require step-up, or request containment; it MUST NOT
probabilistically manufacture additional authority.

The executable scaffold uses `healthy`, `elevated`, `inflamed`,
`compromised`. The colours below are a reading aid, not a second grading
scale and not a second decision point.

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{ POSTURE : informs
    POSTURE ||--o{ SIGNAL : emits
    SIGNAL ||--o{ DECISION : inputs
    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;
- phenotype and posture (Staff judgment);
- attack hypothesis;
- decision (`access-engine` only);
- response authorization (the same decision record);
- action execution (PEP / actuation surface, unowned today);
- outcome;
- lesson;
- policy change.

Immune memory may be derived from outcome and lesson. It MUST NOT appear as
an input arrow into DECISION.

---

## 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 are rendered by `access-engine`.** Reconstructability is
a PDP obligation, not a Staff API. A decision record must expose:

- effective policies;
- precedence;
- exceptions;
- reason;
- decision inputs (including posture as a claim, not as a verdict);
- 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;
- judgment latency (Staff);
- decision latency (PDP);
- response latency (PEP / actuation, when the surface exists);
- 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

Estate KPIs of the **actuation surface** (Engine + PEP), which is unowned
today. kings-guard does not discharge them.

- 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/          # Staff judgment, not a PDP
│   ├── platform-immune-node/
│   ├── federation/
│   └── signal-schema/
│
├── immune-judgment/                 # Staff — not a second decision point
│   ├── phenotype/
│   ├── posture/
│   ├── attack-hypothesis/
│   ├── response-proposal/
│   └── posture-schema/
│
├── immune-response/                 # Engine + PEP; not a kings-guard tree
│   ├── proposal-contract/           # Staff emits; see ImmuneContracts.md
│   ├── effectors/                   # PEP-shaped; actuation unowned
│   ├── authority-control/           # access-engine
│   ├── escalation/
│   └── response-schema/
│
├── immune-recovery/                 # Engine / runtime; Staff may request
│   ├── 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 (owned by `access-engine`; statute §17);
- Response Authority Contract;
- Effector Contract (Staff proposal shape; execution is PEP);
- Response Outcome Contract;
- Recovery Contract;
- Memory Object Contract;
- Tenant Federation Contract;
- Audit Challenge Contract.

### 25.2 Effector Contract

Staff emits a **proposal**. Origin linkage is mandatory (WP-0003-T06).
Authority is not widened. The PEP result, when actuation exists, cites the
decision that authorized it — not the Staff node.

```yaml
effector_request:
  request_id: uuid
  originating_observation_id: kg:obs:9876
  originating_signal_id: kg:sig:9876
  target_system: runtime-pep
  target_ref: kg:subject:456
  action: isolate
  authority_boundary: advisory_only
  restrictive_direction: request_containment
  requires_human_approval: false
  stream_completeness: unknown
  reason: "Genome-prohibited egress observed; propose workload quarantine."
```

```yaml
# PEP / Engine artifact after a decision. Not a kings-guard output.
effector_result:
  request_id: uuid
  originating_observation_id: kg:obs:9876
  originating_signal_id: kg:sig:9876
  decision_ref: kg:decision:123
  effector_id: kg:pep: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 Kubernetes/cloud control plane (the tenant's platform API plane, not Staff);
- 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 (PEP-shaped)
    participant N as Tenant Immune Node (Staff)
    participant D as access-engine (PDP)
    participant E as Network Effector (PEP)
    participant M as Immune Memory (Staff)
    participant H as Recovery (Engine / runtime)

    W->>S: Attempt prohibited external connection
    S->>S: Block attempt under existing policy (local PEP)
    S->>N: Publish observation and evidence
    N->>N: Derive phenotype and posture
    N->>D: Publish posture as an input claim plus a containment proposal
    D->>D: Render the only authorization decision
    D->>E: Decision record (actuation unowned today — intended hop)
    E->>W: Isolate workload if and when actuation exists
    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, proposal, decision ref and outcome
    Note over M,D: Memory is not a runtime input to the PDP
```

### Result

- the local attempt is blocked immediately by a PEP under existing policy;
- Staff publishes posture and a containment *proposal*;
- `access-engine` is the only component that may authorize isolation;
- isolation, rotation and reconstitution are Engine/PEP, and actuation is
  unowned today — the hops are the intended loop, not a claim they ran;
- the tenant compartment is the *unit* of containment, not the actor;
- the incident becomes governed tenant memory, which is not a PDP input;
- 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;
- platform management-plane separation (API/operator plane, not Staff);
- 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;
- trust posture integration;
- response *recommendations* (proposals, not PDP evaluation);
- tenant-private memory that is not a runtime input to other layers.

Success condition:

Common tenant incidents can be judged without central manual correlation.
Policy evaluation remains `access-engine`.

### Phase 5 — Bounded Proposal (actuation unowned)

Deliver:

- reconstructable containment *proposals* (origin observation and signal,
  explicit `authority_boundary`);
- restrictive-direction vocabulary (reduce / step-up / request containment);
- no Staff isolate/revoke/terminate grant.

This phase is complete when proposals are well-formed and reconstructable,
**not** when anything is contained. Actuation is an Engine concept held at
zero. No argument may assume selected incidents are contained automatically.

Engine/PEP follow-on (not this repository, not this phase):

- response authority model on the PDP;
- reversible effectors;
- response leases, rollback, action validation, response budgets.

### 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 `kings-guard` repository holds Staff contracts and this architecture
map. It does not hold identity issuance, PDP, or effector-*execution* specs.

Present:

1. `INTENT.md`
2. `specs/NetKingdomImmuneArchitecture.md` (this file)
3. `specs/ImmuneContracts.md`
4. `docs/AdjacentSystemBoundary.md`
5. `docs/pilots/QontoAssistantPosturePilot.md`
6. `src/kings_guard/` (observation → posture → advisory proposal)

Not this repository (Engine / Tooling / PEP owners):

- identity and attestation contracts (`key-cape`, `user-engine`);
- decision-record schema (`access-engine`);
- effector *execution* interface (unowned actuation surface);
- secret-custody and recovery-runtime specs.

---

## 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 **observe → judge → propose** pattern applies from workload to
federation level. Decide and act sit in Engine/PEP at every level. Recursion
does not create a Staff decision point.

### AD-004 — Evidence Is Distinct From Interpretation

Raw evidence, observations, hypotheses, decisions and actions are separate entities.

### AD-005 — Proposals Are Bounded; Actions Are Engine/PEP

Every Staff *proposal* is limited by scope, authority boundary, duration
and reconstructability to its origin. Every automated *action*, when
actuation exists, is limited by a decision record, duration, evidence
threshold and rollback. kings-guard does not perform the action.

### 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 *proposals* may Staff emit at each recursive level, and which PEP
   stances already exist? (Autonomy of authorization is a second decision
   point and is not on the table.)
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?
    **Answered 2026-09-02 (KG-WP-0004-T05):** `kings-guard` owns observation,
    judgment, posture publication, bounded proposals, and governed memory
    that is not a state plane. Identity issuance (`key-cape` / `user-engine`),
    the PDP (`access-engine`), secret custody (`secrets-engine` / OpenBao),
    and actuation (unowned Engine/PEP surface) do not belong here.

---

## 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 by Engine/PEP, with Staff
  proposing; actuation is unowned today so this criterion is not claimed
  as discharged;
- 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 defence architecture. `kings-guard` observes, judges, and proposes. Engines decide. PEPs act, when an actuation surface exists.

Its defining sequence is:

```text
identity
→ intent
→ observation
→ judgment (posture)
→ bounded proposal
→ decision (access-engine)
→ actuation (unowned)
→ recovery
→ validation
→ memory (not a state plane)
```

Its defining structural principles are:

- identity instead of location-based trust;
- compartmentation instead of a trusted interior;
- local PEP enforcement and Staff proposals, not Staff isolate grants;
- 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.