kings-guard/history/InitialExploration.md

Adaptive Immune Security Architecture

Kings Guard Security is an exploration about how to establish robust security in a continuously changing complex IT environment.

How would the architecture of an it security system for a multitenant multipurpose it cloud platfrom look like that is inspired by analogy to a biological immune system?

A recursive, identity-centred security system that continuously distinguishes intended from harmful behaviour, contains disturbances locally, restores healthy operation, and learns from every incident without weakening tenant isolation.

The objective is not an impossible state in which nothing malicious ever enters. It is to preserve the platform’s viability by enabling it to:

1. anticipate threats,
2. withstand compromise,
3. contain damage,
4. recover healthy operation,
5. adapt its future defences.

This closely matches the NIST cyber-resiliency formulation of anticipating, withstanding, recovering from and adapting to adverse conditions. (NIST Computer Security Resource Center)

Biologically, the architecture draws on barriers, innate immunity, adaptive immunity, signalling, memory, regulation and tissue repair. Innate immunity provides fast, general responses, while adaptive immunity develops specific responses and memory; both depend on regulation to avoid damaging the organism itself. (NCBI)

1. The crucial interpretation of “self”

A simplistic security analogy would classify everything as either:

• self and trusted, or
• foreign and hostile.

That would be dangerous. A legitimate workload can be compromised, an administrator account can be hijacked, and a previously permitted behaviour can become harmful.

Therefore, self must not mean “inside the network.”

In this architecture, self means:

A subject whose identity, provenance, integrity, current state, requested action and behavioural context remain consistent with explicitly declared intent.

This follows the zero-trust shift away from trusting network locations toward protecting identified users, workloads, resources and actions. NIST explicitly rejects implicit trust based solely on location or ownership and, for cloud-native systems, recommends policies based on application and service identities. (NIST Computer Security Resource Center)

A workload should therefore continuously be able to answer:

• Who am I?
• Which tenant do I belong to?
• Which software and configuration am I running?
• Who authorized this deployment?
• Which capabilities may I exercise?
• Which data may I access?
• With whom may I communicate?
• What behaviour is expected from me?
• Is my current state consistent with that declaration?

This could be called the workload’s security phenotype.

---

2. Biological concepts and architectural counterparts

Biological concept	Security counterpart	Architectural capability
Genome	Canonical intended state	Signed architecture, configuration, policies, SBOMs, identities and capability declarations
Skin and mucosa	External barriers	Edge gateway, DDoS protection, ingress validation, protocol filtering
Organ boundaries	Tenant compartments	Tenant-specific identity, network, compute, data, key and policy boundaries
Cell membrane	Workload boundary	Workload identity, sandbox, runtime policy, least privilege
Self markers	Attested identity and provenance	Cryptographic workload identity, signatures, deployment provenance
Innate immunity	Immediate general defence	Deny-by-default, validation, rate limits, runtime rules, isolation
Pattern-recognition receptors	Security sensors	Kernel, network, identity, API, data and application telemetry
Antigen presentation	Normalized security evidence	Contextual observation records presented to decision services
Cytokines	Security signalling	Typed event fabric carrying alerts, state changes and response requests
Lymph nodes	Local correlation centres	Tenant-local detection, evidence aggregation and response coordination
Adaptive immunity	Incident-specific defence	New detections, policies, playbooks and countermeasures
Antibodies	Targeted countermeasures	Signatures, deny rules, revocations, filters and compensating controls
Complement system	Automated response primitives	Block, throttle, quarantine, terminate, revoke and rotate
Memory cells	Security memory	Threat knowledge, attack paths, successful countermeasures and lessons
Regulatory T cells	Safety and governance	Response limits, approval rules, suppression, rollback and exception control
Inflammation	Elevated defensive posture	Temporary restriction, increased telemetry and reduced trust
Tissue repair	Reconciliation and recovery	Immutable redeployment, restoration, secret rotation and validation

The point is not to reproduce biology literally. The analogy provides a useful decomposition of distributed protection, signalling, regulation, learning and repair.

---

3. Top-level architecture

flowchart TB
    EXT["Users, Agents, Services, Devices and External Systems"]

    subgraph GOV["Security Genome and Governance"]
        INTENT["Intent and Capability Registry"]
        CANON["Security Canon and Policy Sources"]
        SUPPLY["Software and Configuration Provenance"]
        RISK["Risk Appetite and Tenant Profiles"]
    end

    subgraph ICP["Platform Immune Control Plane"]
        ID["Identity and Attestation Authority"]
        MEMORY["Immune Memory and Countermeasure Graph"]
        DECIDE["Policy and Response Decision Engine"]
        REGULATE["Tolerance, Safety and Escalation Controller"]
        AUDIT["Independent Audit and Validation"]
        BUS["Security Signal Fabric"]
    end

    subgraph TENANT["Tenant Immune Compartment — repeated per tenant"]
        MEMBRANE["Tenant Membrane"]
        THYMUS["Admission and Deployment Education"]
        APPS["Applications, Data and Workloads"]
        SENTINELS["Local Sentinels"]
        NODE["Tenant Immune Node"]
        EFFECTORS["Local Response Effectors"]
        HEAL["Recovery and Reconstitution"]
    end

    subgraph PLATFORM["Shared Platform Compartments"]
        SHARED["Brokered Shared Services"]
        INFRA["Cluster, Network, Storage and Runtime"]
        PLATFORM_SENTINELS["Platform Sentinels"]
    end

    EXT --> MEMBRANE
    GOV --> ID
    GOV --> DECIDE
    GOV --> THYMUS

    MEMBRANE --> APPS
    THYMUS --> APPS
    ID --> APPS

    APPS --> SENTINELS
    INFRA --> PLATFORM_SENTINELS

    SENTINELS --> NODE
    NODE --> BUS
    PLATFORM_SENTINELS --> BUS

    BUS --> DECIDE
    MEMORY --> DECIDE
    RISK --> REGULATE
    DECIDE --> REGULATE

    REGULATE --> EFFECTORS
    EFFECTORS --> APPS
    EFFECTORS --> MEMBRANE
    EFFECTORS --> HEAL

    HEAL --> APPS
    BUS --> MEMORY
    AUDIT --> MEMORY
    AUDIT --> DECIDE

    APPS <--> SHARED

The most important topological feature is that the architecture is recursive:

• every workload has a local protective boundary;
• every application has a security context;
• every tenant has an immune compartment;
• every cluster has a platform immune system;
• the complete cloud estate has a federated security system.

Local systems act autonomously within bounded authority, while higher levels coordinate events whose impact crosses compartments.

---

4. Seven orthogonal security planes

4.1 Security Genome Plane

The genome describes what healthy operation is supposed to look like.

For each workload or capability, it should contain:

• tenant and ownership;
• intended purpose;
• software and configuration provenance;
• permitted interfaces;
• dependencies;
• permitted callers and destinations;
• data classifications;
• expected resource consumption;
• expected execution behaviour;
• availability and recovery requirements;
• applicable policies;
• known exceptions.

This connects naturally with your distinction between stable INTENT and actual SCOPE.

The immune system does not merely ask whether behaviour is statistically unusual. It asks:

Is actual behaviour compatible with the declared intent and authorized scope?

This prevents the system from gradually learning that a persistent compromise is “normal.”

4.2 Identity and Attestation Plane

This plane establishes identity for:

• humans;
• agents;
• devices;
• workloads;
• services;
• deployment pipelines;
• infrastructure components;
• external organizations.

Human identity could remain within the KeyCape IAM profile, while workload identity is handled through a replaceable attestation contract.

SPIFFE/SPIRE is a strong implementation model because it provides cryptographically verifiable workload identities based on node and workload attestation rather than relying solely on long-lived secrets. Its trust-domain model also lends itself to tenant and platform compartmentation. (spiffe.io)

An identity is not permanently trusted. It acquires a current trust posture derived from:

• strength of attestation;
• software integrity;
• configuration integrity;
• device or node state;
• recent behaviour;
• credential age;
• active incident context;
• requested resource sensitivity.

4.3 Membrane and Compartment Plane

There should be several nested membranes:

1. platform membrane between the cloud and the outside world;
2. tenant membrane between tenants;
3. application membrane around an application domain;
4. workload membrane around each execution unit;
5. data membrane around sensitive data sets;
6. management membrane around control-plane operations.

Each tenant should have its own:

• identity namespace;
• policy bundle;
• encryption context;
• secrets domain;
• network policy;
• data partition;
• telemetry partition;
• security memory scope;
• response authority.

Kubernetes supports multiple tenancy patterns, but its documentation explicitly distinguishes softer and harder isolation and notes trade-offs among security, complexity and cost. A biological architecture should therefore support several isolation phenotypes, rather than assuming namespaces alone are sufficient. (Kubernetes)

A practical classification would be:

Isolation class	Typical realization
Shared	Namespace and policy isolation
Reinforced	Virtual control plane, dedicated nodes or sandboxed runtimes
Strong	Dedicated cluster and tenant trust domain
Sovereign	Dedicated cloud account, keys, control plane and operational authority

The risk profile of a tenant or workload determines the required isolation class.

4.4 Sentinel and Evidence Plane

Sentinels are distributed throughout the system:

• edge sentinels;
• API sentinels;
• identity sentinels;
• workload sentinels;
• kernel sentinels;
• network sentinels;
• data-access sentinels;
• control-plane sentinels;
• application-domain sentinels.

They produce normalized security observations, not immediately final conclusions.

A useful observation envelope would include:

security_observation:
  observation_id: uuid
  timestamp: datetime

  tenant_id: tenant-reference
  compartment_id: compartment-reference
  subject_id: attested-subject-reference
  resource_id: resource-reference

  operation: requested-or-observed-action
  evidence:
    - evidence-reference

  intent_relation:
    expected: true
    deviation_type: none | unknown | prohibited | anomalous

  assessment:
    confidence: 0.0-1.0
    severity: informational | low | medium | high | critical
    novelty: known | variant | unknown
    blast_radius: local | application | tenant | platform

  proposed_response:
    action: observe | challenge | restrict | isolate | revoke | rebuild
    ttl: duration

The evidence remains distinguishable from its interpretation. That allows later reassessment when new information becomes available.

4.5 Signal and Coordination Plane

Biological cytokines coordinate immune activity. The platform equivalent is a typed, authenticated security signal fabric.

It transports:

• observations;
• identity posture changes;
• integrity failures;
• policy violations;
• suspected attack chains;
• response requests;
• response outcomes;
• recovery state;
• escalation messages.

Signals require:

• tenant and compartment scope;
• origin identity;
• evidence references;
• confidence;
• severity;
• expiry time;
• deduplication identity;
• confidentiality classification;
• permitted consumers.

Raw tenant evidence should not automatically enter a global platform data lake. The architecture should distinguish:

• tenant-private evidence;
• platform-operational evidence;
• shareable threat characteristics;
• global countermeasure knowledge.

This allows collective learning without creating a cross-tenant surveillance or leakage mechanism.

4.6 Response and Recovery Plane

The response system should use a graduated ladder:

1. observe — collect more evidence;
2. challenge — require stronger authentication or attestation;
3. constrain — reduce permissions, destinations or rate;
4. degrade — disable nonessential capabilities;
5. isolate — quarantine workload, identity, node or tenant segment;
6. revoke — invalidate credentials, sessions or deployment authority;
7. terminate — stop malicious execution;
8. reconstitute — rebuild from known-good state;
9. restore — recover validated data and service;
10. immunize — distribute a tested countermeasure.

Responses should be local by default. A workload sentinel may stop its workload, but it should not be able to shut down unrelated tenants.

Every automated response should carry:

• authority source;
• reason and evidence;
• scope;
• duration or lease;
• rollback procedure;
• expected outcome;
• validation condition;
• escalation threshold.

Runtime detection and enforcement can be realized by different interchangeable effectors. Current cloud-native examples include Falco for runtime detection and Tetragon for Kubernetes-aware eBPF observation and inline enforcement. (Falco)

4.7 Memory and Adaptation Plane

Immune memory should not be just a SIEM archive. It should be an active knowledge graph connecting:

Observation
    → Evidence
    → Subject
    → Asset
    → Vulnerability
    → Attack technique
    → Intended capability
    → Countermeasure
    → Response action
    → Outcome
    → Residual risk

MITRE D3FEND is particularly suitable as an external vocabulary because it models defensive countermeasures and their relationships to offensive techniques as a knowledge graph. (d3fend.mitre.org)

Memory objects need:

• provenance;
• confidence;
• applicability conditions;
• tenant visibility;
• creation and expiry dates;
• successful and unsuccessful outcomes;
• counter-evidence;
• versioning;
• revocation.

Security memory must be allowed to decay. A rule that was useful two years ago may now be ineffective or actively harmful.

---

5. Tenant-local and platform-wide immunity

The system should distinguish three kinds of security knowledge.

Tenant-local immunity

Contains:

• tenant-specific behaviour;
• tenant-specific risks;
• local incidents;
• business-process expectations;
• local countermeasures;
• confidential evidence.

The tenant immune node owns this information and can act rapidly inside its compartment.

Platform immunity

Contains:

• infrastructure attacks;
• shared service compromise;
• cluster and control-plane conditions;
• supply-chain risks;
• cross-tenant attack patterns;
• platform countermeasures.

The platform immune system may contain or disconnect a tenant compartment, but it should not inspect tenant-private data without an explicit legal and policy basis.

Federated immune memory

Contains only information approved for broader use, such as:

• attack fingerprints;
• affected component versions;
• defensive techniques;
• anonymized behavioural patterns;
• successful containment strategies;
• externally sourced threat intelligence.

Cross-tenant learning should distribute countermeasures and abstract characteristics, not raw customer evidence.

---

6. Preventing digital autoimmune disease

A biological analogy becomes truly valuable when it includes immune failure modes.

Autoimmunity

The security system attacks legitimate activity.

Countermeasures:

• policy simulation;
• shadow mode;
• canary enforcement;
• independent evidence requirements;
• bounded response authority;
• automatic expiry;
• rollback;
• tenant-specific tolerance profiles.

Immunodeficiency

The system lacks sensors, policies or response capabilities.

Countermeasures:

• coverage measurement;
• mandatory baseline controls;
• sentinel health monitoring;
• capability maturity assessment;
• periodic attack simulation.

Chronic inflammation

The platform remains permanently in a high-alert state.

Consequences include:

• alert fatigue;
• excessive logging;
• degraded performance;
• blocked delivery;
• permanently elevated privileges for security tooling.

Controls should include response budgets, signal suppression, incident closure criteria and automatic return to baseline.

Immune evasion

An attacker appears legitimate or disables sensors.

Countermeasures:

• independent telemetry paths;
• remote attestation;
• immutable evidence;
• separation of control and observation;
• detection of missing signals;
• periodic re-attestation.

Malignant growth

A legitimate component expands beyond its intended role.

This includes:

• privilege accumulation;
• uncontrolled agent autonomy;
• data hoarding;
• hidden dependencies;
• excessive resource consumption.

The response is not signature detection, but comparison of actual growth against declared purpose, resource limits and capability boundaries.

---

7. Cybernetic control loops

The architecture should operate at three timescales.

Fast local loop — innate immunity

Sense → match local rule → constrain → report

Examples:

• reject an invalid request;
• block an unauthorized syscall;
• rate-limit abnormal traffic;
• quarantine a workload.

Tenant loop — adaptive response

Correlate → assess tenant context → select response
→ observe outcome → update tenant memory

Examples:

• revoke a tenant user session;
• restrict an application;
• rotate tenant credentials;
• deploy a tenant-specific rule.

Platform learning loop

Aggregate abstract findings → analyze attack pattern
→ validate countermeasure → publish policy update
→ measure effectiveness

Examples:

• revise a platform baseline;
• block a vulnerable artifact;
• introduce a new supply-chain requirement;
• change default isolation for a workload class.

---

8. VSM mapping

The architecture maps neatly onto the Viable System Model.

VSM system	Immune-security responsibility
System 1 – Operation	Workload, application and tenant-local sentinels and effectors
System 2 – Coordination	Security signal fabric, deduplication, suppression and incident coordination
System 3 – Control	Tenant and platform response controllers
System 3 – Audit*	Independent validation, red teaming, forensic evidence and control verification
System 4 – Intelligence	Threat research, attack simulation, adaptive policies and immune memory
System 5 – Policy	Security identity, risk appetite, legal constraints and response authority

This supports recursion: each tenant is a viable security system while remaining part of the larger platform security system.

---

9. Suggested NetKingdom capability structure

For NetKingdom, I would organize the architecture into these stable capabilities rather than tightly coupling it to individual products:

netkingdom
├── security-genome
│   ├── intent-registry
│   ├── capability-registry
│   ├── policy-canon
│   └── provenance-registry
│
├── identity-immunity
│   ├── human-identity
│   ├── workload-identity
│   ├── attestation
│   └── trust-posture
│
├── compartment-control
│   ├── tenant-isolation
│   ├── workload-boundaries
│   ├── data-boundaries
│   └── shared-service-brokers
│
├── sentinel-mesh
│   ├── edge-sentinel
│   ├── identity-sentinel
│   ├── runtime-sentinel
│   ├── network-sentinel
│   └── data-sentinel
│
├── immune-coordination
│   ├── observation-model
│   ├── signal-fabric
│   ├── tenant-immune-node
│   └── platform-immune-node
│
├── immune-response
│   ├── decision-engine
│   ├── response-orchestrator
│   ├── effectors
│   └── escalation
│
├── immune-memory
│   ├── evidence-store
│   ├── countermeasure-graph
│   ├── outcome-learning
│   └── memory-federation
│
└── immune-regulation
    ├── tolerance-control
    ├── simulation
    ├── response-budgets
    ├── audit
    └── recovery-validation

The stable core would consist of the contracts between these capabilities. KeyCape, SPIRE, OPA, Tetragon, Falco, network-policy engines, evidence stores and other implementations would remain replaceable components behind those contracts. OPA/Gatekeeper, for example, can serve as one admission-policy implementation rather than becoming the architecture itself. (openpolicyagent.org)

Central architectural proposition

The resulting NetKingdom system would not primarily be a collection of scanners, dashboards and blocking products. It would be a recursive security control system that:

declares healthy intent
→ establishes cryptographic identity
→ observes actual behaviour
→ detects meaningful divergence
→ responds within bounded authority
→ restores known-good operation
→ validates the outcome
→ retains governed memory

Its most distinctive property would be the combination of:

• zero-trust identity,
• tenant compartmentation,
• distributed innate protection,
• adaptive countermeasure generation,
• cybernetic response loops,
• regulated autonomy,
• continuous repair.

A logical next artifact is an OAS-formatted NetKingdomImmuneArchitecture.md with context, capability, control-loop, deployment, data, trust-boundary and failure-mode views.