coulomb/kings-guard

Fork 0

codex 42dfd27886 Register kings-guard with State Hub

2026-07-23 22:55:42 +02:00

53 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

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 security control system.

It continuously executes the following cycle:

declare healthy intent
→ establish and attest identity
→ observe actual behaviour
→ compare behaviour with intent and policy
→ assess risk and confidence
→ respond within bounded authority
→ restore known-good operation
→ validate the outcome
→ retain governed security memory

The system does not treat trust as a permanent property.

Trust is a temporary, scoped and continuously reassessed condition derived from:

identity;
provenance;
attestation;
integrity;
configuration;
behaviour;
requested operation;
data sensitivity;
current incident context;
tenant and platform policy.

3. Scope

3.1 In Scope

This architecture covers:

human, device, workload, service and agent identities;
authentication, authorization and continuous trust evaluation;
tenant compartmentation;
workload isolation;
network and data boundaries;
policy distribution and enforcement;
admission control;
runtime detection;
security event transport;
local and global security decisions;
automated and human-approved response;
recovery and reconstitution;
incident evidence;
adaptive security memory;
cross-tenant defensive learning;
security governance and safety controls;
security observability and assurance.

3.2 Out of Scope

This document does not prescribe:

a single cloud provider;
a single container or orchestration platform;
a single identity provider;
a single SIEM, SOAR, EDR or policy engine;
a fixed commercial product stack;
one mandatory deployment topology;
detailed legal or regulatory mappings;
application-specific business controls.

Implementations may use different products behind stable Kings Guard capability and interface contracts.

4. Core Terminology

4.1 Organism

The complete governed platform environment whose viability is to be preserved.

An organism may be:

one cloud platform;
one sovereign deployment;
one company environment;
a federation of cooperating platform environments.

4.2 Compartment

A bounded security domain with an explicit identity, authority, policy, telemetry and response scope.

Examples:

tenant;
cluster;
namespace;
application domain;
data domain;
management plane;
sovereign environment.

4.3 Subject

An entity capable of performing or requesting an action.

Examples:

person;
service;
workload;
device;
agent;
pipeline;
operator;
external organization.

4.4 Resource

An entity on which an operation may be performed.

Examples:

API;
dataset;
secret;
queue;
workload;
deployment;
infrastructure object;
identity;
policy.

4.5 Security Genome

The canonical description of intended healthy operation.

It includes:

declared purpose;
ownership;
identities;
permitted capabilities;
dependencies;
policies;
provenance requirements;
expected behaviour;
recovery requirements;
applicable risk profile.

4.6 Security Phenotype

The observable, attested state and behaviour of a subject or compartment at a point in time.

4.7 Immune Observation

A normalized statement about a security-relevant event or state, kept distinct from its interpretation.

4.8 Immune Signal

An authenticated, typed message used to coordinate security assessment or response.

4.9 Effector

A component authorized to perform a concrete defensive action.

Examples:

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

4.10 Immune Memory

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

4.11 Tolerance

The explicit permission for a known deviation, exception or variation that must not trigger an inappropriate defensive response.

4.12 Inflammation

A temporary elevated defensive posture with increased observation and restricted freedom of operation.

4.13 Reconstitution

The replacement of a compromised or uncertain component with a newly established known-good component.

5. Biological Analogy

Biological mechanism	Security interpretation	Kings Guard capability
Genome	Intended healthy state	Security Genome
Skin and mucosa	External protection	Platform Edge Membrane
Organ boundary	Compartment isolation	Tenant and Domain Membranes
Cell membrane	Workload boundary	Workload Guard
Self markers	Verifiable identity	Identity and Attestation
Innate immunity	Immediate general defence	Local Sentinels and Baseline Policies
Pattern-recognition receptors	Detection mechanisms	Sensor and Observation Mesh
Antigen presentation	Contextualized evidence	Evidence Normalization
Cytokines	Distributed coordination signals	Immune Signal Fabric
Lymph nodes	Local correlation and decision	Tenant Immune Node
Adaptive immunity	Incident-specific learning	Adaptive Decision and Policy Generation
Antibodies	Targeted countermeasures	Signatures, Rules and Revocations
Complement system	Immediate action primitives	Response Effectors
Memory cells	Retained defensive knowledge	Immune Memory
Regulatory T cells	Safety and restraint	Immune Regulation
Inflammation	Elevated defensive state	Defensive Posture Management
Tissue repair	Recovery and healing	Reconciliation and Reconstitution

The analogy must never override explicit engineering, legal, safety or operational requirements.

6. Design Principles

6.1 Identity Before Location

Network position does not establish trust.

Every relevant action must be attributable to an authenticated and, where required, attested subject.

6.2 Intent Before Anomaly

Statistical anomaly alone is insufficient.

Observed behaviour should be evaluated against:

declared intent;
permitted scope;
current policy;
expected dependencies;
operational context.

6.3 Compartmentation Before Global Trust

The platform is divided into bounded security compartments.

Compromise of one compartment must not automatically compromise another.

6.4 Local Response Before Central Escalation

Disturbances should be handled as close to their origin as safely possible.

Local components receive bounded authority and escalate when:

evidence is insufficient;
impact may cross compartment boundaries;
response exceeds local authority;
platform-level coordination is required.

6.5 Evidence Before Judgment

Observations, interpretations, decisions and actions remain distinguishable.

This enables:

independent reassessment;
forensic reconstruction;
policy improvement;
explainability;
reduction of cascading false conclusions.

6.6 Reversible Automation Before Irreversible Action

Automated response should prefer temporary, scoped and reversible controls.

Irreversible or high-impact actions require stronger evidence or approval.

6.7 Recovery Before Perfect Prevention

The system assumes that some controls will fail.

Every critical capability must have:

containment;
restoration;
reconstitution;
validation;
continuity procedures.

6.8 Memory With Provenance and Decay

Security knowledge must include:

source;
confidence;
applicability;
scope;
effective date;
expiry or review date;
counter-evidence;
observed outcomes.

6.9 Tenant Sovereignty Within Platform Viability

Tenants control their own security policy within boundaries required to preserve the platform and other tenants.

6.10 Replaceable Implementations

Kings Guard defines stable capability contracts.

Specific identity, policy, runtime, network and observability products remain replaceable.

6.11 Fail Securely, Not Blindly

Loss of a security dependency must result in an explicitly defined degraded mode rather than an accidental unrestricted mode.

6.12 Minimum Necessary Observation

Telemetry collection must be proportional to:

security purpose;
legal basis;
tenant policy;
data sensitivity;
retention need.

7. Recursive Security Model

Kings Guard applies the same security logic at multiple levels.

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 CONTROL["Platform Immune Control Plane"]
        IDENTITY["Identity and Attestation Authority"]
        DECISION["Decision and Response Engine"]
        REGULATION["Safety, Tolerance and Escalation Controller"]
        MEMORY["Immune Memory and Countermeasure Graph"]
        AUDIT["Independent Audit and Validation"]
        SIGNAL["Immune Signal Fabric"]
    end

    subgraph TENANT["Tenant Immune Compartment"]
        MEMBRANE["Tenant Membrane"]
        EDUCATION["Admission and Deployment Education"]
        APPLICATIONS["Applications, Data and Workloads"]
        SENTINELS["Tenant Sentinels"]
        NODE["Tenant Immune Node"]
        EFFECTORS["Tenant Response Effectors"]
        RECOVERY["Tenant Recovery and Reconstitution"]
    end

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

    EXT --> MEMBRANE
    MEMBRANE --> APPLICATIONS

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

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

    APPLICATIONS --> SENTINELS
    INFRA --> PSENTINELS

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

    SIGNAL --> DECISION
    MEMORY --> DECISION
    RISK --> REGULATION
    DECISION --> REGULATION

    REGULATION --> EFFECTORS
    REGULATION --> PEFFECTORS

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

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

    APPLICATIONS <--> BROKER

9. Architectural Planes

The architecture is organized into nine orthogonal planes.

9.1 Security Genome Plane

The Security Genome Plane defines intended healthy operation.

Responsibilities

maintain canonical security intent;
register capabilities and dependencies;
define permitted interactions;
bind workloads to owners and tenants;
define expected software and configuration provenance;
define data sensitivity and handling requirements;
define resilience and recovery expectations;
define accepted variations and exceptions.

Minimum Genome Record

security_genome_record:
  id: kg:genome:example-service
  version: 1.0.0

  ownership:
    tenant_id: tenant-a
    accountable_owner: team-example
    operational_owner: platform-team

  purpose:
    intent: "Provide document conversion for authorized tenant applications."
    criticality: high

  identities:
    workload_identity: spiffe://tenant-a.example/workload/document-converter
    deployment_identity: pipeline:converter-release

  capabilities:
    provides:
      - document.convert
    consumes:
      - object-storage.read
      - object-storage.write
      - audit-event.publish

  communication:
    ingress:
      - caller: document-api
        protocol: https
    egress:
      - destination: tenant-object-storage
        protocol: https
      - destination: audit-broker
        protocol: tls

  data:
    classifications:
      - tenant-confidential
    persistence: ephemeral
    export_allowed: false

  provenance:
    signed_artifact_required: true
    approved_registry: registry.example
    sbom_required: true
    reproducible_build_preferred: true

  expected_behavior:
    max_request_rate: 100/minute
    external_network_access: false
    interactive_shell: prohibited
    privilege_escalation: prohibited

  recovery:
    redeployable: true
    maximum_recovery_time: PT15M
    maximum_data_loss: PT0S

  tolerances:
    - id: temporary-migration-egress
      expires_at: 2026-09-01T00:00:00Z

9.2 Identity and Attestation Plane

This plane establishes and reassesses subject identity.

Identity Classes

human identity;
service identity;
workload identity;
device identity;
agent identity;
infrastructure identity;
deployment identity;
organization identity.

Required Properties

globally or compartment-unique identifier;
tenant affiliation;
issuer;
authentication strength;
attestation evidence;
credential validity;
owner;
permitted capabilities;
current trust posture;
revocation state.

Trust Posture

Trust posture is computed rather than assigned permanently.

trust_posture:
  subject_id: kg:subject:example
  calculated_at: 2026-07-23T18:00:00Z
  valid_until: 2026-07-23T18:05:00Z

  dimensions:
    identity_assurance: 0.98
    runtime_integrity: 0.95
    configuration_integrity: 0.91
    behavioral_consistency: 0.72
    incident_exposure: 0.30

  status: constrained
  reasons:
    - unexpected-egress-attempt

9.3 Membrane and Compartment Plane

This plane establishes nested boundaries.

Membrane Types

platform edge membrane;
tenant membrane;
application membrane;
workload membrane;
data membrane;
management membrane;
supply-chain membrane.

Boundary Controls

authenticated ingress;
authenticated egress;
protocol validation;
policy enforcement;
segmentation;
encryption;
rate control;
content inspection where permitted;
data-loss controls;
management-path separation;
response hooks.

9.4 Sentinel and Evidence Plane

Sentinels observe security-relevant behaviour.

Sentinel Classes

edge sentinel;
identity sentinel;
admission sentinel;
workload sentinel;
kernel sentinel;
network sentinel;
API sentinel;
data-access sentinel;
secret sentinel;
control-plane sentinel;
supply-chain sentinel;
application-domain sentinel.

Observation Contract

immune_observation:
  schema_version: 1.0
  observation_id: uuid
  observed_at: 2026-07-23T18:00:00Z

  source:
    sentinel_id: kg:sentinel:runtime-01
    subject_id: kg:subject:runtime-agent
    integrity_state: attested

  scope:
    platform_id: platform-eu-1
    tenant_id: tenant-a
    compartment_id: app-documents

  actor:
    subject_id: spiffe://tenant-a.example/workload/document-converter
    trust_posture_ref: kg:trust:1234

  target:
    resource_id: kg:resource:external-network
    operation: connect

  evidence:
    - type: kernel-event
      reference: evidence://event/9876

  intent_relation:
    expected: false
    classification: prohibited

  assessment:
    confidence: 0.97
    severity: high
    novelty: known
    potential_blast_radius: application

  proposed_response:
    action: isolate
    scope: workload
    ttl: PT15M

9.5 Signal and Coordination Plane

The Immune Signal Fabric transports authenticated security messages.

Signal Types

observation;
posture change;
policy violation;
integrity failure;
attack hypothesis;
response request;
response authorization;
action result;
recovery status;
escalation;
countermeasure publication;
memory update;
audit challenge.

Signal Properties

Every signal must carry:

signal identifier;
signal type;
origin identity;
tenant and compartment scope;
issue time;
expiry time;
confidentiality class;
evidence references;
confidence;
severity;
deduplication key;
permitted consumers;
signature or equivalent integrity proof.

Signal Isolation

Signals are separated into:

tenant-private;
tenant-shareable;
platform-operational;
platform-restricted;
federated-defensive.

Raw tenant evidence must not be elevated to platform or federation scope without policy authorization.

9.6 Decision Plane

The Decision Plane evaluates observations and determines response.

Decision Inputs

security genome;
current policy;
trust posture;
identity and attestation;
observation evidence;
asset criticality;
tenant risk profile;
active incidents;
historical outcomes;
response authority;
tolerance records;
legal and operational constraints.

Decision Output

immune_decision:
  decision_id: uuid
  decided_at: 2026-07-23T18:00:02Z

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

  hypothesis:
    type: compromised-workload
    confidence: 0.91

  authorized_response:
    action: isolate
    target: spiffe://tenant-a.example/workload/document-converter
    ttl: PT15M
    authority: tenant-immune-node
    rollback: automatic

  required_follow_up:
    - collect-memory-image
    - rotate-workload-credentials
    - reconstitute-workload
    - validate-service-health

  explanation:
    policy_refs:
      - kg:policy:no-external-egress
    evidence_refs:
      - evidence://event/9876

9.7 Response Plane

The Response Plane executes defensive actions.

Response Ladder

Level	Response	Typical effect
R0	Observe	Collect additional evidence
R1	Challenge	Require stronger authentication or attestation
R2	Constrain	Reduce permissions, destinations or rate
R3	Degrade	Disable nonessential functions
R4	Isolate	Quarantine a subject, workload or segment
R5	Revoke	Invalidate sessions, credentials or authority
R6	Terminate	Stop malicious or uncertain execution
R7	Reconstitute	Replace with known-good state
R8	Restore	Recover validated service and data
R9	Immunize	Distribute tested countermeasures

Response Safety Envelope

Every automated action requires:

authorized issuer;
permitted scope;
maximum blast radius;
time-to-live;
rollback procedure;
evidence threshold;
expected outcome;
validation condition;
escalation condition;
audit record.

9.8 Recovery and Reconstitution Plane

Recovery is an architectural peer of detection and response.

Recovery Capabilities

immutable redeployment;
secret rotation;
session invalidation;
data restoration;
configuration reconciliation;
dependency substitution;
tenant evacuation;
cluster evacuation;
continuity mode;
post-recovery validation.

Recovery States

healthy
→ suspected
→ constrained
→ isolated
→ eradication
→ reconstitution
→ validation
→ restored
→ monitored
→ healthy

A component must not return directly from isolated to healthy without validation.

9.9 Memory and Adaptation Plane

The Memory Plane retains and evaluates security knowledge.

Memory Objects

observation pattern;
incident;
attack hypothesis;
attack path;
affected asset;
vulnerability;
defensive technique;
policy;
countermeasure;
response action;
response outcome;
residual risk;
exception;
lesson;
invalidated conclusion.

Memory Graph

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

        TM --> TW
        TI --> TM
        TI --> TW
        TP --> TM
        TP --> TN
        TW --> TD
        TW --> TS
        TD --> TS
        TS --> TN
        TMEM --> TN
        TN --> TR
        TR --> TW
        TR --> TM
        TR --> TREC
        TREC --> TW
        TN --> TMEM
    end

10.1 Tenant-Local Responsibilities

The tenant immune system owns:

tenant-specific security intent;
application and data policies;
tenant identities and delegated roles;
tenant-specific anomaly baselines;
local incident correlation;
local response decisions;
tenant-private evidence;
tenant-specific countermeasures;
tenant recovery procedures.

10.2 Platform Responsibilities

The platform immune system owns:

platform availability and integrity;
shared infrastructure;
cluster and control-plane security;
common identity and attestation services;
baseline security controls;
supply-chain controls;
prevention of cross-tenant impact;
platform incident coordination;
federated countermeasure distribution.

10.3 Tenant Sovereignty Boundary

The platform may override tenant policy only when required to:

prevent cross-tenant compromise;
preserve platform integrity;
satisfy mandatory legal obligations;
contain platform-level incidents;
enforce agreed minimum security controls.

Every override must be:

attributable;
explainable;
time-bounded where possible;
auditable;
visible to the tenant unless prohibited by law or active investigation constraints.

11. Isolation Profiles

Different workloads require different strengths of isolation.

Profile	Description	Typical realization
I0 Shared	Logical isolation for low-risk workloads	Namespace, identity and policy boundaries
I1 Reinforced	Stronger runtime and node separation	Sandboxed runtime, dedicated node pools
I2 Dedicated	Tenant-specific control and compute plane	Dedicated cluster or virtual cluster
I3 Sovereign	Independent authority and infrastructure boundary	Dedicated account, keys, control plane and operations
I4 Air-Gapped	Deliberately disconnected or highly mediated environment	Offline or broker-only exchange

Isolation profile selection considers:

data sensitivity;
workload privilege;
tenant risk;
regulatory requirements;
blast radius;
recovery expectations;
supply-chain trust;
exposure to untrusted code;
autonomous agent capabilities.

12. Shared Service Brokerage

Shared services must not become implicit trust bridges between tenants.

Every shared service is accessed through a brokered contract containing:

authenticated subject;
tenant context;
declared purpose;
permitted operations;
rate and resource limits;
data classification;
isolation requirements;
audit requirements;
response integration;
failure mode.

Examples include:

object storage;
message brokers;
model inference;
logging;
email delivery;
document conversion;
secrets management;
identity services.

Shared service operators must not infer permission merely from network reachability.

13. Admission and Deployment Education

Biological immune systems distinguish tolerated self through developmental processes. Kings Guard applies an analogous admission process.

Before a workload is admitted, the system verifies:

declared owner;
tenant affiliation;
signed artifact;
approved provenance;
dependency declarations;
software bill of materials where required;
known vulnerabilities against policy;
requested privileges;
intended communication;
secrets requirements;
data classifications;
resource limits;
recovery capability;
observability hooks;
response compatibility.

13.1 Admission Outcomes

admitted;
admitted with restrictions;
admitted to observation-only environment;
admitted temporarily;
quarantined for analysis;
rejected.

13.2 Continuous Re-Education

Admission is not permanent.

Reassessment occurs when:

artifact changes;
configuration changes;
dependency changes;
policy changes;
ownership changes;
risk classification changes;
new vulnerability intelligence appears;
behaviour diverges from intent.

14. Control Loops

14.1 Fast Local Loop

Purpose: immediate containment.

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 and effectors
System 2 — Coordination	Signal routing, deduplication, suppression and incident coordination
System 3 — Control	Tenant and platform response controllers
System 3* — Audit	Independent validation, forensic inspection and adversarial testing
System 4 — Intelligence	Threat research, simulation, adaptive policies and immune memory
System 5 — Policy	Security identity, principles, risk appetite and response authority

The same mapping applies recursively to:

workloads;
applications;
tenants;
platforms;
federated environments.

16. Response Authority Model

No component receives unlimited security authority.

16.1 Authority Dimensions

Authority is constrained by:

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

16.2 Example Authority Grant

response_authority:
  authority_id: kg:authority:tenant-isolator
  subject_id: kg:subject:tenant-immune-node-a

  scope:
    tenant_id: tenant-a
    compartments:
      - app-*
    resource_types:
      - workload
      - service-identity

  permitted_actions:
    - constrain
    - isolate
    - revoke-ephemeral-credential

  prohibited_actions:
    - delete-persistent-data
    - modify-platform-policy
    - affect-other-tenant

  limits:
    maximum_ttl: PT1H
    maximum_concurrent_targets: 20
    minimum_confidence: 0.85

  escalation_required_for:
    - terminate
    - restore-data
    - revoke-human-admin

17. Defensive Posture Model

The system maintains explicit defensive posture.

Posture	Meaning	Typical controls
Green	Normal healthy operation	Baseline observation and policy
Blue	Increased awareness	Additional telemetry and shorter trust leases
Amber	Credible local threat	Restricted capabilities and active investigation
Red	Active compromise	Isolation, revocation and reconstitution
Black	Platform viability threatened	Emergency segmentation and continuity mode

Posture may be set at:

workload;
application;
tenant;
cluster;
region;
platform;
federation.

A higher-level posture does not automatically require every lower-level compartment to take identical action. Policies translate posture into context-specific controls.

18. Failure Modes and Immune Pathologies

18.1 Autoimmunity

The system attacks legitimate behaviour.

Causes

incorrect policy;
incomplete intent;
biased anomaly models;
stale memory;
excessive automation;
missing tolerance records.

Controls

shadow evaluation;
simulation;
canary enforcement;
bounded authority;
response leases;
independent evidence;
rollback;
tenant appeal and override workflows.

18.2 Immunodeficiency

The system lacks sufficient coverage or response capability.

Causes

missing sensors;
unmonitored assets;
broken signal paths;
disabled effectors;
expired policy;
insufficient identity assurance.

Controls

coverage measurement;
mandatory minimum controls;
sentinel health checks;
control conformance tests;
adversarial simulation;
maturity assessments.

18.3 Chronic Inflammation

The environment remains permanently in elevated defensive mode.

Consequences

alert fatigue;
excessive cost;
operational friction;
degraded service;
normalization of emergency access.

Controls

posture expiry;
response budgets;
signal suppression;
closure criteria;
de-escalation validation;
periodic review.

18.4 Immune Evasion

An attacker suppresses or imitates legitimate security signals.

Controls

independent observation paths;
remote attestation;
missing-signal detection;
immutable evidence;
cross-sensor correlation;
periodic re-attestation;
protected time sources.

18.5 Malignant Growth

A legitimate capability expands beyond its intended purpose.

Examples:

privilege accumulation;
data hoarding;
unauthorized dependency growth;
uncontrolled agent autonomy;
resource monopolization;
hidden external communication.

Controls compare actual scope with intended scope and trigger review when expansion is unexplained.

18.6 Memory Poisoning

False or adversarial evidence corrupts defensive learning.

Controls

provenance;
confidence scoring;
source reputation;
independent confirmation;
quarantined learning;
reversible policy rollout;
counter-evidence;
memory revocation.

18.7 Cytokine Storm

Security responses amplify one another and cause disproportionate damage.

Controls

global response budgets;
action deduplication;
rate limits;
circuit breakers;
hierarchical coordination;
maximum blast radius;
emergency human control.

19. Security Data Model

19.1 Core Entities

erDiagram
    TENANT ||--o{ COMPARTMENT : contains
    COMPARTMENT ||--o{ SUBJECT : hosts
    COMPARTMENT ||--o{ RESOURCE : protects
    SUBJECT ||--o{ OBSERVATION : produces
    RESOURCE ||--o{ OBSERVATION : concerns
    OBSERVATION }o--o{ EVIDENCE : references
    OBSERVATION ||--o{ DECISION : informs
    DECISION ||--o{ RESPONSE_ACTION : authorizes
    RESPONSE_ACTION ||--o{ RESPONSE_OUTCOME : produces
    RESPONSE_OUTCOME ||--o{ MEMORY_OBJECT : informs
    SECURITY_GENOME ||--o{ SUBJECT : defines
    SECURITY_GENOME ||--o{ RESOURCE : defines
    POLICY ||--o{ DECISION : constrains
    TRUST_POSTURE ||--o{ DECISION : informs

19.2 Separation Requirements

The data model must preserve separation among:

raw evidence;
normalized observation;
attack hypothesis;
decision;
response authorization;
action execution;
outcome;
lesson;
policy change.

20. Policy Architecture

Policies are layered.

20.1 Policy Layers

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 must expose:

effective policies;
precedence;
exceptions;
reason;
decision inputs;
resulting constraints.

21. Evidence Architecture

Evidence is treated as a protected asset.

21.1 Evidence Requirements

immutable or tamper-evident storage;
accurate time reference;
source identity;
integrity proof;
tenant classification;
access control;
retention policy;
legal hold capability;
minimization;
chain of custody where required.

21.2 Evidence Zones

ephemeral local evidence;
tenant incident evidence;
platform incident evidence;
audit evidence;
forensic archive;
shareable defensive intelligence.

22. Observability

Security observability includes both threat state and immune-system health.

22.1 Threat Observability

unauthorized attempts;
policy violations;
anomalous behaviour;
integrity failures;
attack-path progression;
credential abuse;
data access deviations;
cross-compartment interaction.

22.2 Immune-System Observability

sentinel coverage;
signal delivery latency;
decision latency;
response latency;
failed effectors;
stale trust posture;
policy distribution lag;
memory freshness;
recovery readiness;
false-positive rate;
rollback success;
response amplification.

22.3 Mandatory Health Signals

Every security component publishes:

liveness;
readiness;
identity;
software version;
policy version;
attestation state;
last successful observation or action;
degraded-mode state.

23. Key Performance Indicators

23.1 Protection

percentage of assets with current genome records;
percentage of subjects with attested identity;
policy coverage by compartment;
sentinel coverage;
percentage of prohibited paths technically blocked.

23.2 Detection

mean time to observe;
mean time to correlate;
proportion of incidents detected locally;
evidence completeness;
detection confidence calibration.

23.3 Containment

mean time to constrain;
mean time to isolate;
containment success rate;
average containment blast radius;
cross-tenant incident count.

23.4 Recovery

mean time to reconstitute;
mean time to validate;
percentage of workloads reproducibly redeployable;
recovery test success rate;
restoration integrity failure rate.

23.5 Regulation

false-positive response rate;
rollback success rate;
number of expired temporary controls;
number of chronic elevated-posture compartments;
automated action override rate;
response budget violations.

23.6 Learning

countermeasure effectiveness;
memory objects with valid provenance;
stale-memory percentage;
time from incident to tested policy improvement;
repeated-incident rate.

24. Capability Decomposition

kings-guard/
├── architecture/
│   ├── NetKingdomImmuneArchitecture.md
│   ├── TrustArchitecture.md
│   ├── TenantCompartmentArchitecture.md
│   ├── ImmuneControlLoops.md
│   └── DeploymentProfiles.md
│
├── security-genome/
│   ├── intent-registry/
│   ├── capability-registry/
│   ├── policy-canon/
│   ├── provenance-registry/
│   └── schemas/
│
├── identity-immunity/
│   ├── human-identity/
│   ├── workload-identity/
│   ├── agent-identity/
│   ├── attestation/
│   ├── trust-posture/
│   └── contracts/
│
├── compartment-control/
│   ├── tenant-isolation/
│   ├── application-boundaries/
│   ├── workload-boundaries/
│   ├── data-boundaries/
│   ├── shared-service-brokers/
│   └── isolation-profiles/
│
├── sentinel-mesh/
│   ├── edge-sentinel/
│   ├── identity-sentinel/
│   ├── admission-sentinel/
│   ├── runtime-sentinel/
│   ├── network-sentinel/
│   ├── data-sentinel/
│   └── observation-schema/
│
├── immune-coordination/
│   ├── signal-fabric/
│   ├── tenant-immune-node/
│   ├── platform-immune-node/
│   ├── federation/
│   └── signal-schema/
│
├── immune-decision/
│   ├── policy-evaluation/
│   ├── risk-evaluation/
│   ├── attack-hypothesis/
│   ├── response-selection/
│   └── decision-schema/
│
├── immune-response/
│   ├── response-orchestrator/
│   ├── effectors/
│   ├── authority-control/
│   ├── escalation/
│   └── response-schema/
│
├── immune-recovery/
│   ├── reconciliation/
│   ├── reconstitution/
│   ├── secret-rotation/
│   ├── data-restoration/
│   └── validation/
│
├── immune-memory/
│   ├── evidence-store/
│   ├── incident-graph/
│   ├── countermeasure-graph/
│   ├── outcome-learning/
│   ├── memory-federation/
│   └── memory-governance/
│
├── immune-regulation/
│   ├── tolerance-control/
│   ├── safety-envelopes/
│   ├── response-budgets/
│   ├── simulation/
│   ├── audit/
│   └── emergency-control/
│
└── reference-implementations/
    ├── kubernetes/
    ├── vm-platform/
    ├── serverless/
    ├── edge/
    └── sovereign/

25. Stable Architecture Contracts

The architecture should stabilize contracts before selecting implementations.

25.1 Required Contracts

Identity Contract;
Attestation Contract;
Trust Posture Contract;
Security Genome Contract;
Immune Observation Contract;
Immune Signal Contract;
Decision Contract;
Response Authority Contract;
Effector Contract;
Response Outcome Contract;
Recovery Contract;
Memory Object Contract;
Tenant Federation Contract;
Audit Challenge Contract.

25.2 Effector Contract

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 control plane;
tenant-specific recovery environment;
platform federation through signed defensive signals.

26.4 Sovereign Profile

Suitable for:

national, critical-infrastructure or highly regulated contexts.

Typical characteristics:

independent cloud account or physical environment;
tenant-controlled roots of trust;
local operations;
restricted federation;
explicit intelligence exchange;
independent audit.

26.5 Edge Profile

Suitable for:

intermittently connected environments;
remote installations;
industrial or physical systems.

Typical characteristics:

strong local innate loop;
cached policy;
bounded autonomous response;
delayed evidence synchronization;
local recovery;
federation after reconnection.

27. Example Incident Flow

Scenario

A tenant workload attempts an external connection that is not declared in its Security Genome.

sequenceDiagram
    participant W as Workload
    participant S as Runtime Sentinel
    participant N as Tenant Immune Node
    participant D as Decision Engine
    participant R as Regulation Controller
    participant E as Network Effector
    participant M as Immune Memory
    participant H as Recovery Controller

    W->>S: Attempt prohibited external connection
    S->>S: Block attempt using local rule
    S->>N: Publish observation and evidence
    N->>D: Request contextual assessment
    D->>D: Compare identity, intent, posture and history
    D->>R: Propose temporary workload isolation
    R->>R: Validate authority, blast radius and TTL
    R->>E: Authorize isolation
    E->>W: Isolate workload
    E->>N: Return action outcome
    N->>H: Request credential rotation and reconstitution
    H->>W: Replace with known-good workload
    H->>N: Return validation result
    N->>M: Store evidence, action and outcome
    M->>D: Update future decision context

Result

the local attempt is blocked immediately;
the tenant compartment contains the possible compromise;
credentials are rotated;
the workload is replaced rather than merely restarted;
the restored workload is validated;
the incident becomes governed tenant memory;
a shareable attack characteristic may be submitted to platform memory without exporting tenant-private evidence.

28. Federation and Collective Immunity

Federated environments may share defensive knowledge without sharing unrestricted telemetry.

28.1 Shareable Objects

component vulnerability;
attack technique;
malicious artifact digest;
defensive rule;
mitigation guidance;
response outcome summary;
anonymized behaviour characteristic.

28.2 Non-Shareable by Default

raw tenant logs;
tenant data content;
user identifiers;
business process details;
tenant-specific topology;
unrestricted forensic images;
confidential incident narrative.

28.3 Federation Requirements

signed objects;
source identity;
confidence;
scope;
handling classification;
expiry;
revocation;
compatibility information;
policy-controlled import;
quarantine before automatic enforcement.

29. Implementation Independence

Potential implementations may include:

human identity providers;
workload identity and attestation systems;
policy engines;
admission controllers;
eBPF runtime sensors;
service meshes;
network policy engines;
message brokers;
evidence stores;
graph databases;
SIEM and SOAR systems;
backup and restore systems;
infrastructure reconciliation systems.

No implementation becomes part of the constitutional architecture merely because it is selected for an initial deployment.

Each implementation must map to one or more Kings Guard capabilities and conform to the corresponding contracts.

30. Security Assurance

30.1 Continuous Assurance

The architecture requires continuous validation of:

identity issuance;
attestation;
policy enforcement;
network boundaries;
workload restrictions;
response authority;
recovery capability;
evidence integrity;
signal isolation;
federation controls.

30.2 Adversarial Validation

The system should support:

policy unit tests;
architecture conformance tests;
attack simulations;
chaos-security experiments;
credential compromise exercises;
tenant-isolation tests;
recovery exercises;
memory-poisoning tests;
response-amplification tests.

30.3 Independent Audit Path

Audit components must be able to challenge operational security conclusions.

The audit path should be organizationally and technically separated from the components it validates where practical.

31. Incremental Realization Roadmap

Phase 1 — Security Genome and Identity Foundation

Deliver:

tenant, subject and resource identifiers;
workload identity;
Security Genome schema;
baseline policy hierarchy;
signed deployment provenance;
initial trust posture model.

Success condition:

Every protected workload has an attributable identity and declared intended behaviour.

Phase 2 — Compartment and Membrane Foundation

Deliver:

tenant isolation profiles;
ingress and egress policy;
shared-service brokerage;
management-plane separation;
tenant-specific encryption and secret boundaries.

Success condition:

A tenant compromise cannot trivially cross into another tenant.

Phase 3 — Sentinel and Signal Mesh

Deliver:

observation schema;
edge, identity, runtime and network sentinels;
tenant-scoped signal transport;
evidence references;
sentinel health monitoring.

Success condition:

Security-relevant behaviour is attributable, normalized and routed to the correct compartment.

Phase 4 — Tenant Immune Nodes

Deliver:

tenant-local correlation;
policy evaluation;
trust posture integration;
response recommendations;
tenant-private memory.

Success condition:

Common tenant incidents can be assessed without central manual correlation.

Phase 5 — Bounded Automated Response

Deliver:

response authority model;
reversible effectors;
response leases;
rollback;
action validation;
response budgets.

Success condition:

Selected high-confidence incidents can be contained automatically without uncontrolled blast radius.

Phase 6 — Recovery and Reconstitution

Deliver:

immutable workload replacement;
secret rotation;
recovery workflows;
restoration validation;
recovery readiness metrics.

Success condition:

Compromised workloads can be replaced and validated predictably.

Phase 7 — Adaptive Memory

Deliver:

incident graph;
countermeasure graph;
response outcome learning;
policy improvement workflow;
memory review and decay.

Success condition:

Past incidents measurably improve future detection, containment and recovery.

Phase 8 — Federated Collective Immunity

Deliver:

shareable intelligence schema;
signed federation;
import quarantine;
tenant privacy controls;
countermeasure distribution.

Success condition:

Multiple environments can share useful defensive knowledge without exposing tenant-private evidence.

32. Initial Repository Deliverables

The initial kings-guard repository should contain:

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

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.

53 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

53 KiB

Executable file

Raw Blame History