tegwick 3493aac2ac Complete KG-WP-0004-T03: label remaining control-plane strings

Every leftover control-plane mention is now a Kubernetes or platform API
plane, or an explicit denial that kings-guard is not one. Head-note v0.7
refresh stays T05.

Assistant: grok
Assistant-Session: 01a05ef1-9e5a-70f2-b0ff-0b05d6b38ae9

2026-09-02 01:28:30 +02:00

62 KiB

Executable file

Raw Blame History

title

document_id

version

status

date

repo

brand

ecosystem

owners

classification

NetKingdom Immune Architecture

KG-ARCH-IMMUNE

0.1.0

Draft

2026-07-23

kings-guard

Kings Guard Security

NetKingdom

Kings Guard Security Architecture

Public

NetKingdom Immune Architecture

Layer note (2026-08-28). kings-guard is a Staff-layer repository under the NetKingdom Security Layer Model v0.6 (assented in decisions/decisions.md KG-DEC-2026-001). Where this document uses "control plane", read it as naming an estate-wide, Engine-layer arrangement of deterministic authorities — never as a self-description of kings-guard, which publishes posture and requests bounded response through engine APIs. The parts of this architecture that render decisions or hold state belong to engines; kings-guard owns observation, judgment, and the request. A full vocabulary sweep of this document is tracked as intake KG-IN-0002.

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:

distinguish intended from harmful behaviour;
identify and contain disturbances near their origin;
adapt defensive measures to new evidence;
restore known-good operation after compromise;
learn without violating tenant confidentiality;
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:

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

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

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

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

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.

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

platform edge membrane;
tenant membrane;
application membrane;
workload membrane;
data membrane;
management membrane (platform API/operator plane; not Staff);
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

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

# 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. Execution, safety envelope, and the isolate grant are T04 of KG-WP-0004.

The Response Plane is where defensive actions would be performed, once an actuation surface exists.

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

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

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

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.

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

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.

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.

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.

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.

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

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

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

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

NetKingdom constitutional policy
Defines non-negotiable security principles.
Kings Guard platform policy
Defines platform-wide minimum controls.
Environment policy
Defines region, cluster or sovereign-environment rules.
Tenant policy
Defines tenant-specific requirements.
Application policy
Defines application behaviour.
Workload policy
Defines concrete runtime permissions.
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

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

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/
│   ├── 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

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

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

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

INTENT.md
NetKingdomImmuneArchitecture.md
SecurityGenomeSpecification.md
IdentityAndAttestationContract.md
TenantCompartmentStandard.md
ImmuneObservationSchema.md
ImmuneSignalSchema.md
ResponseAuthorityStandard.md
EffectorInterfaceSpecification.md
ImmuneMemoryModel.md
DeploymentProfiles.md
ThreatAndFailureModeCatalog.md
ImplementationRoadmap.md
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

How should trust posture dimensions be normalized across different runtime types?
Which response actions may be authorized autonomously at each recursive level?
Which evidence classes may be federated across tenants?
How should tenants inspect or challenge platform-level security overrides?
Which Security Genome fields are mandatory for initial admission?
How should agent autonomy be represented as a bounded capability?
How should memory confidence decay over time?
Which isolation profiles should be mandatory for untrusted code execution?
How should security response budgets be calculated?
How should business continuity requirements influence defensive posture?
How should the architecture integrate with the wider NetKingdom identity and policy canon?
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 defence architecture. kings-guard observes, judges, and proposes. Engines decide. PEPs act, when an actuation surface exists.

Its defining sequence is:

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.

62 KiB Executable file Raw Blame History

NetKingdom Immune Architecture

1. Purpose

2. Architectural Proposition

3. Scope

3.1 In Scope

3.2 Out of Scope

4. Core Terminology

4.1 Organism

4.2 Compartment

4.3 Subject

4.4 Resource

4.5 Security Genome

4.6 Security Phenotype

4.7 Immune Observation

4.8 Immune Signal

4.9 Effector

4.10 Immune Memory

4.11 Tolerance

4.12 Inflammation

4.13 Reconstitution

5. Biological Analogy

6. Design Principles

6.1 Identity Before Location

6.2 Intent Before Anomaly

6.3 Compartmentation Before Global Trust

6.4 Local Response Before Central Escalation

6.5 Evidence Before Judgment

6.6 Reversible Automation Before Irreversible Action

6.7 Recovery Before Perfect Prevention

6.8 Memory With Provenance and Decay

6.9 Tenant Sovereignty Within Platform Viability

6.10 Replaceable Implementations

6.11 Fail Securely, Not Blindly

6.12 Minimum Necessary Observation

7. Recursive Security Model

8. Top-Level Architecture

9. Architectural Planes

9.1 Security Genome Plane

Responsibilities

Minimum Genome Record

9.2 Identity and Attestation Plane

Identity Classes

Required Properties

Trust Posture

9.3 Membrane and Compartment Plane

Membrane Types

Boundary Controls

9.4 Sentinel and Evidence Plane

Sentinel Classes

Observation Contract

9.5 Signal and Coordination Plane

Signal Types

Signal Properties

Signal Isolation

9.6 Decision Plane

Decision Inputs

Decision Output

9.7 Response Plane

Response Ladder

Response Safety Envelope

9.8 Recovery and Reconstitution Plane

Recovery Capabilities

Recovery States

9.9 Memory and Adaptation Plane

Memory Objects

Memory Graph

Memory Governance

10. Tenant Security Architecture

10.1 Tenant-Local Responsibilities

10.2 Platform Responsibilities

10.3 Tenant Sovereignty Boundary

11. Isolation Profiles

12. Shared Service Brokerage

13. Admission and Deployment Education

13.1 Admission Outcomes

13.2 Continuous Re-Education

14. Control Loops

14.1 Fast Local Loop

14.2 Tenant Adaptive Loop

62 KiB

Executable file

Raw Blame History