2292 lines
53 KiB
Markdown
Executable file
2292 lines
53 KiB
Markdown
Executable file
---
|
|
title: NetKingdom Immune Architecture
|
|
document_id: KG-ARCH-IMMUNE
|
|
version: 0.1.0
|
|
status: Draft
|
|
date: 2026-07-23
|
|
repo: kings-guard
|
|
brand: Kings Guard Security
|
|
ecosystem: NetKingdom
|
|
owners:
|
|
- Kings Guard Security Architecture
|
|
classification: Public
|
|
---
|
|
|
|
# NetKingdom Immune Architecture
|
|
|
|
## 1. Purpose
|
|
|
|
This document defines the reference architecture for **Kings Guard Security**, implemented in the `kings-guard` repository and positioned within the wider **NetKingdom** ecosystem.
|
|
|
|
The architecture applies principles observed in biological immune systems to the design of a secure, resilient, multi-tenant and multi-purpose cloud platform. The biological analogy is used as an architectural reasoning model, not as a literal implementation prescription.
|
|
|
|
The system is intended to protect heterogeneous cloud environments containing:
|
|
|
|
- multiple independent tenants;
|
|
- multiple vendors and operators;
|
|
- human users, machine identities and autonomous agents;
|
|
- shared and tenant-dedicated infrastructure;
|
|
- applications with different criticality and trust requirements;
|
|
- data with different confidentiality, integrity and availability requirements;
|
|
- changing workloads, dependencies and threat conditions.
|
|
|
|
The architecture aims to preserve the platform's viability by enabling it to:
|
|
|
|
1. distinguish intended from harmful behaviour;
|
|
2. identify and contain disturbances near their origin;
|
|
3. adapt defensive measures to new evidence;
|
|
4. restore known-good operation after compromise;
|
|
5. learn without violating tenant confidentiality;
|
|
6. avoid damaging legitimate activity through uncontrolled defensive action.
|
|
|
|
---
|
|
|
|
## 2. Architectural Proposition
|
|
|
|
Kings Guard Security is a **recursive adaptive security control system**.
|
|
|
|
It continuously executes the following cycle:
|
|
|
|
```text
|
|
declare healthy intent
|
|
→ establish and attest identity
|
|
→ observe actual behaviour
|
|
→ compare behaviour with intent and policy
|
|
→ assess risk and confidence
|
|
→ respond within bounded authority
|
|
→ restore known-good operation
|
|
→ validate the outcome
|
|
→ retain governed security memory
|
|
```
|
|
|
|
The system does not treat trust as a permanent property.
|
|
|
|
Trust is a temporary, scoped and continuously reassessed condition derived from:
|
|
|
|
- identity;
|
|
- provenance;
|
|
- attestation;
|
|
- integrity;
|
|
- configuration;
|
|
- behaviour;
|
|
- requested operation;
|
|
- data sensitivity;
|
|
- current incident context;
|
|
- tenant and platform policy.
|
|
|
|
---
|
|
|
|
## 3. Scope
|
|
|
|
### 3.1 In Scope
|
|
|
|
This architecture covers:
|
|
|
|
- human, device, workload, service and agent identities;
|
|
- authentication, authorization and continuous trust evaluation;
|
|
- tenant compartmentation;
|
|
- workload isolation;
|
|
- network and data boundaries;
|
|
- policy distribution and enforcement;
|
|
- admission control;
|
|
- runtime detection;
|
|
- security event transport;
|
|
- local and global security decisions;
|
|
- automated and human-approved response;
|
|
- recovery and reconstitution;
|
|
- incident evidence;
|
|
- adaptive security memory;
|
|
- cross-tenant defensive learning;
|
|
- security governance and safety controls;
|
|
- security observability and assurance.
|
|
|
|
### 3.2 Out of Scope
|
|
|
|
This document does not prescribe:
|
|
|
|
- a single cloud provider;
|
|
- a single container or orchestration platform;
|
|
- a single identity provider;
|
|
- a single SIEM, SOAR, EDR or policy engine;
|
|
- a fixed commercial product stack;
|
|
- one mandatory deployment topology;
|
|
- detailed legal or regulatory mappings;
|
|
- application-specific business controls.
|
|
|
|
Implementations may use different products behind stable Kings Guard capability and interface contracts.
|
|
|
|
---
|
|
|
|
## 4. Core Terminology
|
|
|
|
### 4.1 Organism
|
|
|
|
The complete governed platform environment whose viability is to be preserved.
|
|
|
|
An organism may be:
|
|
|
|
- one cloud platform;
|
|
- one sovereign deployment;
|
|
- one company environment;
|
|
- a federation of cooperating platform environments.
|
|
|
|
### 4.2 Compartment
|
|
|
|
A bounded security domain with an explicit identity, authority, policy, telemetry and response scope.
|
|
|
|
Examples:
|
|
|
|
- tenant;
|
|
- cluster;
|
|
- namespace;
|
|
- application domain;
|
|
- data domain;
|
|
- management plane;
|
|
- sovereign environment.
|
|
|
|
### 4.3 Subject
|
|
|
|
An entity capable of performing or requesting an action.
|
|
|
|
Examples:
|
|
|
|
- person;
|
|
- service;
|
|
- workload;
|
|
- device;
|
|
- agent;
|
|
- pipeline;
|
|
- operator;
|
|
- external organization.
|
|
|
|
### 4.4 Resource
|
|
|
|
An entity on which an operation may be performed.
|
|
|
|
Examples:
|
|
|
|
- API;
|
|
- dataset;
|
|
- secret;
|
|
- queue;
|
|
- workload;
|
|
- deployment;
|
|
- infrastructure object;
|
|
- identity;
|
|
- policy.
|
|
|
|
### 4.5 Security Genome
|
|
|
|
The canonical description of intended healthy operation.
|
|
|
|
It includes:
|
|
|
|
- declared purpose;
|
|
- ownership;
|
|
- identities;
|
|
- permitted capabilities;
|
|
- dependencies;
|
|
- policies;
|
|
- provenance requirements;
|
|
- expected behaviour;
|
|
- recovery requirements;
|
|
- applicable risk profile.
|
|
|
|
### 4.6 Security Phenotype
|
|
|
|
The observable, attested state and behaviour of a subject or compartment at a point in time.
|
|
|
|
### 4.7 Immune Observation
|
|
|
|
A normalized statement about a security-relevant event or state, kept distinct from its interpretation.
|
|
|
|
### 4.8 Immune Signal
|
|
|
|
An authenticated, typed message used to coordinate security assessment or response.
|
|
|
|
### 4.9 Effector
|
|
|
|
A component authorized to perform a concrete defensive action.
|
|
|
|
Examples:
|
|
|
|
- reject;
|
|
- throttle;
|
|
- isolate;
|
|
- revoke;
|
|
- terminate;
|
|
- rotate;
|
|
- restore;
|
|
- rebuild.
|
|
|
|
### 4.10 Immune Memory
|
|
|
|
Governed knowledge derived from observations, incidents, threat intelligence, countermeasures and response outcomes.
|
|
|
|
### 4.11 Tolerance
|
|
|
|
The explicit permission for a known deviation, exception or variation that must not trigger an inappropriate defensive response.
|
|
|
|
### 4.12 Inflammation
|
|
|
|
A temporary elevated defensive posture with increased observation and restricted freedom of operation.
|
|
|
|
### 4.13 Reconstitution
|
|
|
|
The replacement of a compromised or uncertain component with a newly established known-good component.
|
|
|
|
---
|
|
|
|
## 5. Biological Analogy
|
|
|
|
| Biological mechanism | Security interpretation | Kings Guard capability |
|
|
|---|---|---|
|
|
| Genome | Intended healthy state | Security Genome |
|
|
| Skin and mucosa | External protection | Platform Edge Membrane |
|
|
| Organ boundary | Compartment isolation | Tenant and Domain Membranes |
|
|
| Cell membrane | Workload boundary | Workload Guard |
|
|
| Self markers | Verifiable identity | Identity and Attestation |
|
|
| Innate immunity | Immediate general defence | Local Sentinels and Baseline Policies |
|
|
| Pattern-recognition receptors | Detection mechanisms | Sensor and Observation Mesh |
|
|
| Antigen presentation | Contextualized evidence | Evidence Normalization |
|
|
| Cytokines | Distributed coordination signals | Immune Signal Fabric |
|
|
| Lymph nodes | Local correlation and decision | Tenant Immune Node |
|
|
| Adaptive immunity | Incident-specific learning | Adaptive Decision and Policy Generation |
|
|
| Antibodies | Targeted countermeasures | Signatures, Rules and Revocations |
|
|
| Complement system | Immediate action primitives | Response Effectors |
|
|
| Memory cells | Retained defensive knowledge | Immune Memory |
|
|
| Regulatory T cells | Safety and restraint | Immune Regulation |
|
|
| Inflammation | Elevated defensive state | Defensive Posture Management |
|
|
| Tissue repair | Recovery and healing | Reconciliation and Reconstitution |
|
|
|
|
The analogy must never override explicit engineering, legal, safety or operational requirements.
|
|
|
|
---
|
|
|
|
## 6. Design Principles
|
|
|
|
### 6.1 Identity Before Location
|
|
|
|
Network position does not establish trust.
|
|
|
|
Every relevant action must be attributable to an authenticated and, where required, attested subject.
|
|
|
|
### 6.2 Intent Before Anomaly
|
|
|
|
Statistical anomaly alone is insufficient.
|
|
|
|
Observed behaviour should be evaluated against:
|
|
|
|
- declared intent;
|
|
- permitted scope;
|
|
- current policy;
|
|
- expected dependencies;
|
|
- operational context.
|
|
|
|
### 6.3 Compartmentation Before Global Trust
|
|
|
|
The platform is divided into bounded security compartments.
|
|
|
|
Compromise of one compartment must not automatically compromise another.
|
|
|
|
### 6.4 Local Response Before Central Escalation
|
|
|
|
Disturbances should be handled as close to their origin as safely possible.
|
|
|
|
Local components receive bounded authority and escalate when:
|
|
|
|
- evidence is insufficient;
|
|
- impact may cross compartment boundaries;
|
|
- response exceeds local authority;
|
|
- platform-level coordination is required.
|
|
|
|
### 6.5 Evidence Before Judgment
|
|
|
|
Observations, interpretations, decisions and actions remain distinguishable.
|
|
|
|
This enables:
|
|
|
|
- independent reassessment;
|
|
- forensic reconstruction;
|
|
- policy improvement;
|
|
- explainability;
|
|
- reduction of cascading false conclusions.
|
|
|
|
### 6.6 Reversible Automation Before Irreversible Action
|
|
|
|
Automated response should prefer temporary, scoped and reversible controls.
|
|
|
|
Irreversible or high-impact actions require stronger evidence or approval.
|
|
|
|
### 6.7 Recovery Before Perfect Prevention
|
|
|
|
The system assumes that some controls will fail.
|
|
|
|
Every critical capability must have:
|
|
|
|
- containment;
|
|
- restoration;
|
|
- reconstitution;
|
|
- validation;
|
|
- continuity procedures.
|
|
|
|
### 6.8 Memory With Provenance and Decay
|
|
|
|
Security knowledge must include:
|
|
|
|
- source;
|
|
- confidence;
|
|
- applicability;
|
|
- scope;
|
|
- effective date;
|
|
- expiry or review date;
|
|
- counter-evidence;
|
|
- observed outcomes.
|
|
|
|
### 6.9 Tenant Sovereignty Within Platform Viability
|
|
|
|
Tenants control their own security policy within boundaries required to preserve the platform and other tenants.
|
|
|
|
### 6.10 Replaceable Implementations
|
|
|
|
Kings Guard defines stable capability contracts.
|
|
|
|
Specific identity, policy, runtime, network and observability products remain replaceable.
|
|
|
|
### 6.11 Fail Securely, Not Blindly
|
|
|
|
Loss of a security dependency must result in an explicitly defined degraded mode rather than an accidental unrestricted mode.
|
|
|
|
### 6.12 Minimum Necessary Observation
|
|
|
|
Telemetry collection must be proportional to:
|
|
|
|
- security purpose;
|
|
- legal basis;
|
|
- tenant policy;
|
|
- data sensitivity;
|
|
- retention need.
|
|
|
|
---
|
|
|
|
## 7. Recursive Security Model
|
|
|
|
Kings Guard applies the same security logic at multiple levels.
|
|
|
|
```mermaid
|
|
flowchart TB
|
|
GLOBAL["Federated NetKingdom Security"]
|
|
PLATFORM["Platform Immune System"]
|
|
TENANT["Tenant Immune System"]
|
|
APP["Application Immune System"]
|
|
WORKLOAD["Workload Guard"]
|
|
OPERATION["Protected Operation"]
|
|
|
|
GLOBAL --> PLATFORM
|
|
PLATFORM --> TENANT
|
|
TENANT --> APP
|
|
APP --> WORKLOAD
|
|
WORKLOAD --> OPERATION
|
|
|
|
OPERATION --> WORKLOAD
|
|
WORKLOAD --> APP
|
|
APP --> TENANT
|
|
TENANT --> PLATFORM
|
|
PLATFORM --> GLOBAL
|
|
```
|
|
|
|
Each level has:
|
|
|
|
- an identity;
|
|
- a declared intent;
|
|
- observable state;
|
|
- policy;
|
|
- bounded authority;
|
|
- local memory;
|
|
- escalation rules;
|
|
- recovery procedures.
|
|
|
|
Higher levels coordinate lower levels without erasing their autonomy.
|
|
|
|
---
|
|
|
|
## 8. Top-Level Architecture
|
|
|
|
```mermaid
|
|
flowchart TB
|
|
EXT["Users, Agents, Devices, Services and External Systems"]
|
|
|
|
subgraph GENOME["Security Genome and Governance"]
|
|
INTENT["Intent and Capability Registry"]
|
|
POLICY["Policy Canon"]
|
|
PROVENANCE["Artifact and Configuration Provenance"]
|
|
RISK["Risk Profiles and Security Objectives"]
|
|
end
|
|
|
|
subgraph CONTROL["Platform Immune Control Plane"]
|
|
IDENTITY["Identity and Attestation Authority"]
|
|
DECISION["Decision and Response Engine"]
|
|
REGULATION["Safety, Tolerance and Escalation Controller"]
|
|
MEMORY["Immune Memory and Countermeasure Graph"]
|
|
AUDIT["Independent Audit and Validation"]
|
|
SIGNAL["Immune Signal Fabric"]
|
|
end
|
|
|
|
subgraph TENANT["Tenant Immune Compartment"]
|
|
MEMBRANE["Tenant Membrane"]
|
|
EDUCATION["Admission and Deployment Education"]
|
|
APPLICATIONS["Applications, Data and Workloads"]
|
|
SENTINELS["Tenant Sentinels"]
|
|
NODE["Tenant Immune Node"]
|
|
EFFECTORS["Tenant Response Effectors"]
|
|
RECOVERY["Tenant Recovery and Reconstitution"]
|
|
end
|
|
|
|
subgraph SHARED["Shared Platform Compartments"]
|
|
BROKER["Brokered Shared Services"]
|
|
INFRA["Compute, Network, Storage and Runtime"]
|
|
PSENTINELS["Platform Sentinels"]
|
|
PEFFECTORS["Platform Effectors"]
|
|
end
|
|
|
|
EXT --> MEMBRANE
|
|
MEMBRANE --> APPLICATIONS
|
|
|
|
GENOME --> IDENTITY
|
|
GENOME --> DECISION
|
|
GENOME --> EDUCATION
|
|
|
|
IDENTITY --> MEMBRANE
|
|
IDENTITY --> APPLICATIONS
|
|
EDUCATION --> APPLICATIONS
|
|
|
|
APPLICATIONS --> SENTINELS
|
|
INFRA --> PSENTINELS
|
|
|
|
SENTINELS --> NODE
|
|
NODE --> SIGNAL
|
|
PSENTINELS --> SIGNAL
|
|
|
|
SIGNAL --> DECISION
|
|
MEMORY --> DECISION
|
|
RISK --> REGULATION
|
|
DECISION --> REGULATION
|
|
|
|
REGULATION --> EFFECTORS
|
|
REGULATION --> PEFFECTORS
|
|
|
|
EFFECTORS --> APPLICATIONS
|
|
EFFECTORS --> MEMBRANE
|
|
EFFECTORS --> RECOVERY
|
|
PEFFECTORS --> INFRA
|
|
|
|
RECOVERY --> APPLICATIONS
|
|
SIGNAL --> MEMORY
|
|
AUDIT --> MEMORY
|
|
AUDIT --> DECISION
|
|
|
|
APPLICATIONS <--> BROKER
|
|
```
|
|
|
|
---
|
|
|
|
## 9. Architectural Planes
|
|
|
|
The architecture is organized into nine orthogonal planes.
|
|
|
|
### 9.1 Security Genome Plane
|
|
|
|
The Security Genome Plane defines intended healthy operation.
|
|
|
|
#### Responsibilities
|
|
|
|
- maintain canonical security intent;
|
|
- register capabilities and dependencies;
|
|
- define permitted interactions;
|
|
- bind workloads to owners and tenants;
|
|
- define expected software and configuration provenance;
|
|
- define data sensitivity and handling requirements;
|
|
- define resilience and recovery expectations;
|
|
- define accepted variations and exceptions.
|
|
|
|
#### Minimum Genome Record
|
|
|
|
```yaml
|
|
security_genome_record:
|
|
id: kg:genome:example-service
|
|
version: 1.0.0
|
|
|
|
ownership:
|
|
tenant_id: tenant-a
|
|
accountable_owner: team-example
|
|
operational_owner: platform-team
|
|
|
|
purpose:
|
|
intent: "Provide document conversion for authorized tenant applications."
|
|
criticality: high
|
|
|
|
identities:
|
|
workload_identity: spiffe://tenant-a.example/workload/document-converter
|
|
deployment_identity: pipeline:converter-release
|
|
|
|
capabilities:
|
|
provides:
|
|
- document.convert
|
|
consumes:
|
|
- object-storage.read
|
|
- object-storage.write
|
|
- audit-event.publish
|
|
|
|
communication:
|
|
ingress:
|
|
- caller: document-api
|
|
protocol: https
|
|
egress:
|
|
- destination: tenant-object-storage
|
|
protocol: https
|
|
- destination: audit-broker
|
|
protocol: tls
|
|
|
|
data:
|
|
classifications:
|
|
- tenant-confidential
|
|
persistence: ephemeral
|
|
export_allowed: false
|
|
|
|
provenance:
|
|
signed_artifact_required: true
|
|
approved_registry: registry.example
|
|
sbom_required: true
|
|
reproducible_build_preferred: true
|
|
|
|
expected_behavior:
|
|
max_request_rate: 100/minute
|
|
external_network_access: false
|
|
interactive_shell: prohibited
|
|
privilege_escalation: prohibited
|
|
|
|
recovery:
|
|
redeployable: true
|
|
maximum_recovery_time: PT15M
|
|
maximum_data_loss: PT0S
|
|
|
|
tolerances:
|
|
- id: temporary-migration-egress
|
|
expires_at: 2026-09-01T00:00:00Z
|
|
```
|
|
|
|
### 9.2 Identity and Attestation Plane
|
|
|
|
This plane establishes and reassesses subject identity.
|
|
|
|
#### Identity Classes
|
|
|
|
- human identity;
|
|
- service identity;
|
|
- workload identity;
|
|
- device identity;
|
|
- agent identity;
|
|
- infrastructure identity;
|
|
- deployment identity;
|
|
- organization identity.
|
|
|
|
#### Required Properties
|
|
|
|
- globally or compartment-unique identifier;
|
|
- tenant affiliation;
|
|
- issuer;
|
|
- authentication strength;
|
|
- attestation evidence;
|
|
- credential validity;
|
|
- owner;
|
|
- permitted capabilities;
|
|
- current trust posture;
|
|
- revocation state.
|
|
|
|
#### Trust Posture
|
|
|
|
Trust posture is computed rather than assigned permanently.
|
|
|
|
```yaml
|
|
trust_posture:
|
|
subject_id: kg:subject:example
|
|
calculated_at: 2026-07-23T18:00:00Z
|
|
valid_until: 2026-07-23T18:05:00Z
|
|
|
|
dimensions:
|
|
identity_assurance: 0.98
|
|
runtime_integrity: 0.95
|
|
configuration_integrity: 0.91
|
|
behavioral_consistency: 0.72
|
|
incident_exposure: 0.30
|
|
|
|
status: constrained
|
|
reasons:
|
|
- unexpected-egress-attempt
|
|
```
|
|
|
|
### 9.3 Membrane and Compartment Plane
|
|
|
|
This plane establishes nested boundaries.
|
|
|
|
#### Membrane Types
|
|
|
|
1. platform edge membrane;
|
|
2. tenant membrane;
|
|
3. application membrane;
|
|
4. workload membrane;
|
|
5. data membrane;
|
|
6. management membrane;
|
|
7. supply-chain membrane.
|
|
|
|
#### Boundary Controls
|
|
|
|
- authenticated ingress;
|
|
- authenticated egress;
|
|
- protocol validation;
|
|
- policy enforcement;
|
|
- segmentation;
|
|
- encryption;
|
|
- rate control;
|
|
- content inspection where permitted;
|
|
- data-loss controls;
|
|
- management-path separation;
|
|
- response hooks.
|
|
|
|
### 9.4 Sentinel and Evidence Plane
|
|
|
|
Sentinels observe security-relevant behaviour.
|
|
|
|
#### Sentinel Classes
|
|
|
|
- edge sentinel;
|
|
- identity sentinel;
|
|
- admission sentinel;
|
|
- workload sentinel;
|
|
- kernel sentinel;
|
|
- network sentinel;
|
|
- API sentinel;
|
|
- data-access sentinel;
|
|
- secret sentinel;
|
|
- control-plane sentinel;
|
|
- supply-chain sentinel;
|
|
- application-domain sentinel.
|
|
|
|
#### Observation Contract
|
|
|
|
```yaml
|
|
immune_observation:
|
|
schema_version: 1.0
|
|
observation_id: uuid
|
|
observed_at: 2026-07-23T18:00:00Z
|
|
|
|
source:
|
|
sentinel_id: kg:sentinel:runtime-01
|
|
subject_id: kg:subject:runtime-agent
|
|
integrity_state: attested
|
|
|
|
scope:
|
|
platform_id: platform-eu-1
|
|
tenant_id: tenant-a
|
|
compartment_id: app-documents
|
|
|
|
actor:
|
|
subject_id: spiffe://tenant-a.example/workload/document-converter
|
|
trust_posture_ref: kg:trust:1234
|
|
|
|
target:
|
|
resource_id: kg:resource:external-network
|
|
operation: connect
|
|
|
|
evidence:
|
|
- type: kernel-event
|
|
reference: evidence://event/9876
|
|
|
|
intent_relation:
|
|
expected: false
|
|
classification: prohibited
|
|
|
|
assessment:
|
|
confidence: 0.97
|
|
severity: high
|
|
novelty: known
|
|
potential_blast_radius: application
|
|
|
|
proposed_response:
|
|
action: isolate
|
|
scope: workload
|
|
ttl: PT15M
|
|
```
|
|
|
|
### 9.5 Signal and Coordination Plane
|
|
|
|
The Immune Signal Fabric transports authenticated security messages.
|
|
|
|
#### Signal Types
|
|
|
|
- observation;
|
|
- posture change;
|
|
- policy violation;
|
|
- integrity failure;
|
|
- attack hypothesis;
|
|
- response request;
|
|
- response authorization;
|
|
- action result;
|
|
- recovery status;
|
|
- escalation;
|
|
- countermeasure publication;
|
|
- memory update;
|
|
- audit challenge.
|
|
|
|
#### Signal Properties
|
|
|
|
Every signal must carry:
|
|
|
|
- signal identifier;
|
|
- signal type;
|
|
- origin identity;
|
|
- tenant and compartment scope;
|
|
- issue time;
|
|
- expiry time;
|
|
- confidentiality class;
|
|
- evidence references;
|
|
- confidence;
|
|
- severity;
|
|
- deduplication key;
|
|
- permitted consumers;
|
|
- signature or equivalent integrity proof.
|
|
|
|
#### Signal Isolation
|
|
|
|
Signals are separated into:
|
|
|
|
- tenant-private;
|
|
- tenant-shareable;
|
|
- platform-operational;
|
|
- platform-restricted;
|
|
- federated-defensive.
|
|
|
|
Raw tenant evidence must not be elevated to platform or federation scope without policy authorization.
|
|
|
|
### 9.6 Decision Plane
|
|
|
|
The Decision Plane evaluates observations and determines response.
|
|
|
|
#### Decision Inputs
|
|
|
|
- security genome;
|
|
- current policy;
|
|
- trust posture;
|
|
- identity and attestation;
|
|
- observation evidence;
|
|
- asset criticality;
|
|
- tenant risk profile;
|
|
- active incidents;
|
|
- historical outcomes;
|
|
- response authority;
|
|
- tolerance records;
|
|
- legal and operational constraints.
|
|
|
|
#### Decision Output
|
|
|
|
```yaml
|
|
immune_decision:
|
|
decision_id: uuid
|
|
decided_at: 2026-07-23T18:00:02Z
|
|
|
|
scope:
|
|
tenant_id: tenant-a
|
|
compartment_id: app-documents
|
|
|
|
hypothesis:
|
|
type: compromised-workload
|
|
confidence: 0.91
|
|
|
|
authorized_response:
|
|
action: isolate
|
|
target: spiffe://tenant-a.example/workload/document-converter
|
|
ttl: PT15M
|
|
authority: tenant-immune-node
|
|
rollback: automatic
|
|
|
|
required_follow_up:
|
|
- collect-memory-image
|
|
- rotate-workload-credentials
|
|
- reconstitute-workload
|
|
- validate-service-health
|
|
|
|
explanation:
|
|
policy_refs:
|
|
- kg:policy:no-external-egress
|
|
evidence_refs:
|
|
- evidence://event/9876
|
|
```
|
|
|
|
### 9.7 Response Plane
|
|
|
|
The Response Plane executes defensive actions.
|
|
|
|
#### Response Ladder
|
|
|
|
| Level | Response | Typical effect |
|
|
|---|---|---|
|
|
| R0 | Observe | Collect additional evidence |
|
|
| R1 | Challenge | Require stronger authentication or attestation |
|
|
| R2 | Constrain | Reduce permissions, destinations or rate |
|
|
| R3 | Degrade | Disable nonessential functions |
|
|
| R4 | Isolate | Quarantine a subject, workload or segment |
|
|
| R5 | Revoke | Invalidate sessions, credentials or authority |
|
|
| R6 | Terminate | Stop malicious or uncertain execution |
|
|
| R7 | Reconstitute | Replace with known-good state |
|
|
| R8 | Restore | Recover validated service and data |
|
|
| R9 | Immunize | Distribute tested countermeasures |
|
|
|
|
#### Response Safety Envelope
|
|
|
|
Every automated action requires:
|
|
|
|
- authorized issuer;
|
|
- permitted scope;
|
|
- maximum blast radius;
|
|
- time-to-live;
|
|
- rollback procedure;
|
|
- evidence threshold;
|
|
- expected outcome;
|
|
- validation condition;
|
|
- escalation condition;
|
|
- audit record.
|
|
|
|
### 9.8 Recovery and Reconstitution Plane
|
|
|
|
Recovery is an architectural peer of detection and response.
|
|
|
|
#### Recovery Capabilities
|
|
|
|
- immutable redeployment;
|
|
- secret rotation;
|
|
- session invalidation;
|
|
- data restoration;
|
|
- configuration reconciliation;
|
|
- dependency substitution;
|
|
- tenant evacuation;
|
|
- cluster evacuation;
|
|
- continuity mode;
|
|
- post-recovery validation.
|
|
|
|
#### Recovery States
|
|
|
|
```text
|
|
healthy
|
|
→ suspected
|
|
→ constrained
|
|
→ isolated
|
|
→ eradication
|
|
→ reconstitution
|
|
→ validation
|
|
→ restored
|
|
→ monitored
|
|
→ healthy
|
|
```
|
|
|
|
A component must not return directly from `isolated` to `healthy` without validation.
|
|
|
|
### 9.9 Memory and Adaptation Plane
|
|
|
|
The Memory Plane retains and evaluates security knowledge.
|
|
|
|
#### Memory Objects
|
|
|
|
- observation pattern;
|
|
- incident;
|
|
- attack hypothesis;
|
|
- attack path;
|
|
- affected asset;
|
|
- vulnerability;
|
|
- defensive technique;
|
|
- policy;
|
|
- countermeasure;
|
|
- response action;
|
|
- response outcome;
|
|
- residual risk;
|
|
- exception;
|
|
- lesson;
|
|
- invalidated conclusion.
|
|
|
|
#### Memory Graph
|
|
|
|
```mermaid
|
|
flowchart LR
|
|
O["Observation"] --> E["Evidence"]
|
|
E --> H["Attack Hypothesis"]
|
|
H --> A["Affected Asset"]
|
|
H --> T["Attack Technique"]
|
|
T --> C["Countermeasure"]
|
|
C --> R["Response Action"]
|
|
R --> OUT["Outcome"]
|
|
OUT --> L["Lesson"]
|
|
L --> P["Policy or Playbook Update"]
|
|
P --> C
|
|
OUT --> RR["Residual Risk"]
|
|
```
|
|
|
|
#### Memory Governance
|
|
|
|
Every memory object includes:
|
|
|
|
- provenance;
|
|
- confidence;
|
|
- scope;
|
|
- tenant visibility;
|
|
- applicability;
|
|
- effective date;
|
|
- review date;
|
|
- expiry date;
|
|
- success evidence;
|
|
- counter-evidence;
|
|
- version;
|
|
- revocation state.
|
|
|
|
---
|
|
|
|
## 10. Tenant Security Architecture
|
|
|
|
Each tenant is represented as an immune compartment.
|
|
|
|
```mermaid
|
|
flowchart TB
|
|
subgraph TENANT["Tenant Immune Compartment"]
|
|
TM["Tenant Membrane"]
|
|
TI["Tenant Identity Domain"]
|
|
TP["Tenant Policy Bundle"]
|
|
TW["Tenant Workloads"]
|
|
TD["Tenant Data Domains"]
|
|
TS["Tenant Sentinel Mesh"]
|
|
TN["Tenant Immune Node"]
|
|
TR["Tenant Response Effectors"]
|
|
TMEM["Tenant Immune Memory"]
|
|
TREC["Tenant Recovery Controller"]
|
|
|
|
TM --> TW
|
|
TI --> TM
|
|
TI --> TW
|
|
TP --> TM
|
|
TP --> TN
|
|
TW --> TD
|
|
TW --> TS
|
|
TD --> TS
|
|
TS --> TN
|
|
TMEM --> TN
|
|
TN --> TR
|
|
TR --> TW
|
|
TR --> TM
|
|
TR --> TREC
|
|
TREC --> TW
|
|
TN --> TMEM
|
|
end
|
|
```
|
|
|
|
### 10.1 Tenant-Local Responsibilities
|
|
|
|
The tenant immune system owns:
|
|
|
|
- tenant-specific security intent;
|
|
- application and data policies;
|
|
- tenant identities and delegated roles;
|
|
- tenant-specific anomaly baselines;
|
|
- local incident correlation;
|
|
- local response decisions;
|
|
- tenant-private evidence;
|
|
- tenant-specific countermeasures;
|
|
- tenant recovery procedures.
|
|
|
|
### 10.2 Platform Responsibilities
|
|
|
|
The platform immune system owns:
|
|
|
|
- platform availability and integrity;
|
|
- shared infrastructure;
|
|
- cluster and control-plane security;
|
|
- common identity and attestation services;
|
|
- baseline security controls;
|
|
- supply-chain controls;
|
|
- prevention of cross-tenant impact;
|
|
- platform incident coordination;
|
|
- federated countermeasure distribution.
|
|
|
|
### 10.3 Tenant Sovereignty Boundary
|
|
|
|
The platform may override tenant policy only when required to:
|
|
|
|
- prevent cross-tenant compromise;
|
|
- preserve platform integrity;
|
|
- satisfy mandatory legal obligations;
|
|
- contain platform-level incidents;
|
|
- enforce agreed minimum security controls.
|
|
|
|
Every override must be:
|
|
|
|
- attributable;
|
|
- explainable;
|
|
- time-bounded where possible;
|
|
- auditable;
|
|
- visible to the tenant unless prohibited by law or active investigation constraints.
|
|
|
|
---
|
|
|
|
## 11. Isolation Profiles
|
|
|
|
Different workloads require different strengths of isolation.
|
|
|
|
| Profile | Description | Typical realization |
|
|
|---|---|---|
|
|
| I0 Shared | Logical isolation for low-risk workloads | Namespace, identity and policy boundaries |
|
|
| I1 Reinforced | Stronger runtime and node separation | Sandboxed runtime, dedicated node pools |
|
|
| I2 Dedicated | Tenant-specific control and compute plane | Dedicated cluster or virtual cluster |
|
|
| I3 Sovereign | Independent authority and infrastructure boundary | Dedicated account, keys, control plane and operations |
|
|
| I4 Air-Gapped | Deliberately disconnected or highly mediated environment | Offline or broker-only exchange |
|
|
|
|
Isolation profile selection considers:
|
|
|
|
- data sensitivity;
|
|
- workload privilege;
|
|
- tenant risk;
|
|
- regulatory requirements;
|
|
- blast radius;
|
|
- recovery expectations;
|
|
- supply-chain trust;
|
|
- exposure to untrusted code;
|
|
- autonomous agent capabilities.
|
|
|
|
---
|
|
|
|
## 12. Shared Service Brokerage
|
|
|
|
Shared services must not become implicit trust bridges between tenants.
|
|
|
|
Every shared service is accessed through a **brokered contract** containing:
|
|
|
|
- authenticated subject;
|
|
- tenant context;
|
|
- declared purpose;
|
|
- permitted operations;
|
|
- rate and resource limits;
|
|
- data classification;
|
|
- isolation requirements;
|
|
- audit requirements;
|
|
- response integration;
|
|
- failure mode.
|
|
|
|
Examples include:
|
|
|
|
- object storage;
|
|
- message brokers;
|
|
- model inference;
|
|
- logging;
|
|
- email delivery;
|
|
- document conversion;
|
|
- secrets management;
|
|
- identity services.
|
|
|
|
Shared service operators must not infer permission merely from network reachability.
|
|
|
|
---
|
|
|
|
## 13. Admission and Deployment Education
|
|
|
|
Biological immune systems distinguish tolerated self through developmental processes. Kings Guard applies an analogous admission process.
|
|
|
|
Before a workload is admitted, the system verifies:
|
|
|
|
- declared owner;
|
|
- tenant affiliation;
|
|
- signed artifact;
|
|
- approved provenance;
|
|
- dependency declarations;
|
|
- software bill of materials where required;
|
|
- known vulnerabilities against policy;
|
|
- requested privileges;
|
|
- intended communication;
|
|
- secrets requirements;
|
|
- data classifications;
|
|
- resource limits;
|
|
- recovery capability;
|
|
- observability hooks;
|
|
- response compatibility.
|
|
|
|
### 13.1 Admission Outcomes
|
|
|
|
- admitted;
|
|
- admitted with restrictions;
|
|
- admitted to observation-only environment;
|
|
- admitted temporarily;
|
|
- quarantined for analysis;
|
|
- rejected.
|
|
|
|
### 13.2 Continuous Re-Education
|
|
|
|
Admission is not permanent.
|
|
|
|
Reassessment occurs when:
|
|
|
|
- artifact changes;
|
|
- configuration changes;
|
|
- dependency changes;
|
|
- policy changes;
|
|
- ownership changes;
|
|
- risk classification changes;
|
|
- new vulnerability intelligence appears;
|
|
- behaviour diverges from intent.
|
|
|
|
---
|
|
|
|
## 14. Control Loops
|
|
|
|
### 14.1 Fast Local Loop
|
|
|
|
Purpose: immediate containment.
|
|
|
|
```text
|
|
sense
|
|
→ match local rule
|
|
→ apply reversible constraint
|
|
→ report observation and outcome
|
|
```
|
|
|
|
Target latency: milliseconds to seconds.
|
|
|
|
Examples:
|
|
|
|
- reject malformed input;
|
|
- block prohibited syscall;
|
|
- deny unapproved egress;
|
|
- throttle abusive request;
|
|
- isolate a process.
|
|
|
|
### 14.2 Tenant Adaptive Loop
|
|
|
|
Purpose: contextual tenant response.
|
|
|
|
```text
|
|
correlate tenant observations
|
|
→ assess against tenant intent
|
|
→ select bounded response
|
|
→ observe outcome
|
|
→ update tenant memory
|
|
```
|
|
|
|
Target latency: seconds to minutes.
|
|
|
|
Examples:
|
|
|
|
- revoke a tenant session;
|
|
- restrict an application;
|
|
- rotate tenant credentials;
|
|
- isolate a tenant workload group;
|
|
- deploy a tenant-specific detection.
|
|
|
|
### 14.3 Platform Coordination Loop
|
|
|
|
Purpose: protect shared infrastructure and tenants.
|
|
|
|
```text
|
|
aggregate platform signals
|
|
→ identify shared or cross-tenant impact
|
|
→ coordinate platform response
|
|
→ validate containment
|
|
→ distribute safe countermeasures
|
|
```
|
|
|
|
Target latency: seconds to hours.
|
|
|
|
### 14.4 Strategic Learning Loop
|
|
|
|
Purpose: improve future architecture and policy.
|
|
|
|
```text
|
|
review incidents and outcomes
|
|
→ identify structural weaknesses
|
|
→ test improved controls
|
|
→ update genome, standards or architecture
|
|
→ measure long-term effectiveness
|
|
```
|
|
|
|
Target latency: days to quarters.
|
|
|
|
---
|
|
|
|
## 15. Viable System Model Mapping
|
|
|
|
| VSM function | Kings Guard responsibility |
|
|
|---|---|
|
|
| System 1 — Operations | Workload, application and tenant sentinels and effectors |
|
|
| System 2 — Coordination | Signal routing, deduplication, suppression and incident coordination |
|
|
| System 3 — Control | Tenant and platform response controllers |
|
|
| System 3* — Audit | Independent validation, forensic inspection and adversarial testing |
|
|
| System 4 — Intelligence | Threat research, simulation, adaptive policies and immune memory |
|
|
| System 5 — Policy | Security identity, principles, risk appetite and response authority |
|
|
|
|
The same mapping applies recursively to:
|
|
|
|
- workloads;
|
|
- applications;
|
|
- tenants;
|
|
- platforms;
|
|
- federated environments.
|
|
|
|
---
|
|
|
|
## 16. Response Authority Model
|
|
|
|
No component receives unlimited security authority.
|
|
|
|
### 16.1 Authority Dimensions
|
|
|
|
Authority is constrained by:
|
|
|
|
- tenant;
|
|
- compartment;
|
|
- resource type;
|
|
- action type;
|
|
- maximum severity;
|
|
- maximum blast radius;
|
|
- time-to-live;
|
|
- evidence threshold;
|
|
- approval requirement;
|
|
- operating mode.
|
|
|
|
### 16.2 Example Authority Grant
|
|
|
|
```yaml
|
|
response_authority:
|
|
authority_id: kg:authority:tenant-isolator
|
|
subject_id: kg:subject:tenant-immune-node-a
|
|
|
|
scope:
|
|
tenant_id: tenant-a
|
|
compartments:
|
|
- app-*
|
|
resource_types:
|
|
- workload
|
|
- service-identity
|
|
|
|
permitted_actions:
|
|
- constrain
|
|
- isolate
|
|
- revoke-ephemeral-credential
|
|
|
|
prohibited_actions:
|
|
- delete-persistent-data
|
|
- modify-platform-policy
|
|
- affect-other-tenant
|
|
|
|
limits:
|
|
maximum_ttl: PT1H
|
|
maximum_concurrent_targets: 20
|
|
minimum_confidence: 0.85
|
|
|
|
escalation_required_for:
|
|
- terminate
|
|
- restore-data
|
|
- revoke-human-admin
|
|
```
|
|
|
|
---
|
|
|
|
## 17. Defensive Posture Model
|
|
|
|
The system maintains explicit defensive posture.
|
|
|
|
| Posture | Meaning | Typical controls |
|
|
|---|---|---|
|
|
| Green | Normal healthy operation | Baseline observation and policy |
|
|
| Blue | Increased awareness | Additional telemetry and shorter trust leases |
|
|
| Amber | Credible local threat | Restricted capabilities and active investigation |
|
|
| Red | Active compromise | Isolation, revocation and reconstitution |
|
|
| Black | Platform viability threatened | Emergency segmentation and continuity mode |
|
|
|
|
Posture may be set at:
|
|
|
|
- workload;
|
|
- application;
|
|
- tenant;
|
|
- cluster;
|
|
- region;
|
|
- platform;
|
|
- federation.
|
|
|
|
A higher-level posture does not automatically require every lower-level compartment to take identical action. Policies translate posture into context-specific controls.
|
|
|
|
---
|
|
|
|
## 18. Failure Modes and Immune Pathologies
|
|
|
|
### 18.1 Autoimmunity
|
|
|
|
The system attacks legitimate behaviour.
|
|
|
|
#### Causes
|
|
|
|
- incorrect policy;
|
|
- incomplete intent;
|
|
- biased anomaly models;
|
|
- stale memory;
|
|
- excessive automation;
|
|
- missing tolerance records.
|
|
|
|
#### Controls
|
|
|
|
- shadow evaluation;
|
|
- simulation;
|
|
- canary enforcement;
|
|
- bounded authority;
|
|
- response leases;
|
|
- independent evidence;
|
|
- rollback;
|
|
- tenant appeal and override workflows.
|
|
|
|
### 18.2 Immunodeficiency
|
|
|
|
The system lacks sufficient coverage or response capability.
|
|
|
|
#### Causes
|
|
|
|
- missing sensors;
|
|
- unmonitored assets;
|
|
- broken signal paths;
|
|
- disabled effectors;
|
|
- expired policy;
|
|
- insufficient identity assurance.
|
|
|
|
#### Controls
|
|
|
|
- coverage measurement;
|
|
- mandatory minimum controls;
|
|
- sentinel health checks;
|
|
- control conformance tests;
|
|
- adversarial simulation;
|
|
- maturity assessments.
|
|
|
|
### 18.3 Chronic Inflammation
|
|
|
|
The environment remains permanently in elevated defensive mode.
|
|
|
|
#### Consequences
|
|
|
|
- alert fatigue;
|
|
- excessive cost;
|
|
- operational friction;
|
|
- degraded service;
|
|
- normalization of emergency access.
|
|
|
|
#### Controls
|
|
|
|
- posture expiry;
|
|
- response budgets;
|
|
- signal suppression;
|
|
- closure criteria;
|
|
- de-escalation validation;
|
|
- periodic review.
|
|
|
|
### 18.4 Immune Evasion
|
|
|
|
An attacker suppresses or imitates legitimate security signals.
|
|
|
|
#### Controls
|
|
|
|
- independent observation paths;
|
|
- remote attestation;
|
|
- missing-signal detection;
|
|
- immutable evidence;
|
|
- cross-sensor correlation;
|
|
- periodic re-attestation;
|
|
- protected time sources.
|
|
|
|
### 18.5 Malignant Growth
|
|
|
|
A legitimate capability expands beyond its intended purpose.
|
|
|
|
Examples:
|
|
|
|
- privilege accumulation;
|
|
- data hoarding;
|
|
- unauthorized dependency growth;
|
|
- uncontrolled agent autonomy;
|
|
- resource monopolization;
|
|
- hidden external communication.
|
|
|
|
Controls compare actual scope with intended scope and trigger review when expansion is unexplained.
|
|
|
|
### 18.6 Memory Poisoning
|
|
|
|
False or adversarial evidence corrupts defensive learning.
|
|
|
|
#### Controls
|
|
|
|
- provenance;
|
|
- confidence scoring;
|
|
- source reputation;
|
|
- independent confirmation;
|
|
- quarantined learning;
|
|
- reversible policy rollout;
|
|
- counter-evidence;
|
|
- memory revocation.
|
|
|
|
### 18.7 Cytokine Storm
|
|
|
|
Security responses amplify one another and cause disproportionate damage.
|
|
|
|
#### Controls
|
|
|
|
- global response budgets;
|
|
- action deduplication;
|
|
- rate limits;
|
|
- circuit breakers;
|
|
- hierarchical coordination;
|
|
- maximum blast radius;
|
|
- emergency human control.
|
|
|
|
---
|
|
|
|
## 19. Security Data Model
|
|
|
|
### 19.1 Core Entities
|
|
|
|
```mermaid
|
|
erDiagram
|
|
TENANT ||--o{ COMPARTMENT : contains
|
|
COMPARTMENT ||--o{ SUBJECT : hosts
|
|
COMPARTMENT ||--o{ RESOURCE : protects
|
|
SUBJECT ||--o{ OBSERVATION : produces
|
|
RESOURCE ||--o{ OBSERVATION : concerns
|
|
OBSERVATION }o--o{ EVIDENCE : references
|
|
OBSERVATION ||--o{ DECISION : informs
|
|
DECISION ||--o{ RESPONSE_ACTION : authorizes
|
|
RESPONSE_ACTION ||--o{ RESPONSE_OUTCOME : produces
|
|
RESPONSE_OUTCOME ||--o{ MEMORY_OBJECT : informs
|
|
SECURITY_GENOME ||--o{ SUBJECT : defines
|
|
SECURITY_GENOME ||--o{ RESOURCE : defines
|
|
POLICY ||--o{ DECISION : constrains
|
|
TRUST_POSTURE ||--o{ DECISION : informs
|
|
```
|
|
|
|
### 19.2 Separation Requirements
|
|
|
|
The data model must preserve separation among:
|
|
|
|
- raw evidence;
|
|
- normalized observation;
|
|
- attack hypothesis;
|
|
- decision;
|
|
- response authorization;
|
|
- action execution;
|
|
- outcome;
|
|
- lesson;
|
|
- policy change.
|
|
|
|
---
|
|
|
|
## 20. Policy Architecture
|
|
|
|
Policies are layered.
|
|
|
|
### 20.1 Policy Layers
|
|
|
|
1. **NetKingdom constitutional policy**
|
|
Defines non-negotiable security principles.
|
|
|
|
2. **Kings Guard platform policy**
|
|
Defines platform-wide minimum controls.
|
|
|
|
3. **Environment policy**
|
|
Defines region, cluster or sovereign-environment rules.
|
|
|
|
4. **Tenant policy**
|
|
Defines tenant-specific requirements.
|
|
|
|
5. **Application policy**
|
|
Defines application behaviour.
|
|
|
|
6. **Workload policy**
|
|
Defines concrete runtime permissions.
|
|
|
|
7. **Temporary incident policy**
|
|
Defines time-bounded emergency controls.
|
|
|
|
### 20.2 Policy Resolution
|
|
|
|
A lower layer may strengthen a higher-layer requirement but may weaken it only through an authorized exception.
|
|
|
|
Policy decisions must expose:
|
|
|
|
- effective policies;
|
|
- precedence;
|
|
- exceptions;
|
|
- reason;
|
|
- decision inputs;
|
|
- resulting constraints.
|
|
|
|
---
|
|
|
|
## 21. Evidence Architecture
|
|
|
|
Evidence is treated as a protected asset.
|
|
|
|
### 21.1 Evidence Requirements
|
|
|
|
- immutable or tamper-evident storage;
|
|
- accurate time reference;
|
|
- source identity;
|
|
- integrity proof;
|
|
- tenant classification;
|
|
- access control;
|
|
- retention policy;
|
|
- legal hold capability;
|
|
- minimization;
|
|
- chain of custody where required.
|
|
|
|
### 21.2 Evidence Zones
|
|
|
|
- ephemeral local evidence;
|
|
- tenant incident evidence;
|
|
- platform incident evidence;
|
|
- audit evidence;
|
|
- forensic archive;
|
|
- shareable defensive intelligence.
|
|
|
|
---
|
|
|
|
## 22. Observability
|
|
|
|
Security observability includes both threat state and immune-system health.
|
|
|
|
### 22.1 Threat Observability
|
|
|
|
- unauthorized attempts;
|
|
- policy violations;
|
|
- anomalous behaviour;
|
|
- integrity failures;
|
|
- attack-path progression;
|
|
- credential abuse;
|
|
- data access deviations;
|
|
- cross-compartment interaction.
|
|
|
|
### 22.2 Immune-System Observability
|
|
|
|
- sentinel coverage;
|
|
- signal delivery latency;
|
|
- decision latency;
|
|
- response latency;
|
|
- failed effectors;
|
|
- stale trust posture;
|
|
- policy distribution lag;
|
|
- memory freshness;
|
|
- recovery readiness;
|
|
- false-positive rate;
|
|
- rollback success;
|
|
- response amplification.
|
|
|
|
### 22.3 Mandatory Health Signals
|
|
|
|
Every security component publishes:
|
|
|
|
- liveness;
|
|
- readiness;
|
|
- identity;
|
|
- software version;
|
|
- policy version;
|
|
- attestation state;
|
|
- last successful observation or action;
|
|
- degraded-mode state.
|
|
|
|
---
|
|
|
|
## 23. Key Performance Indicators
|
|
|
|
### 23.1 Protection
|
|
|
|
- percentage of assets with current genome records;
|
|
- percentage of subjects with attested identity;
|
|
- policy coverage by compartment;
|
|
- sentinel coverage;
|
|
- percentage of prohibited paths technically blocked.
|
|
|
|
### 23.2 Detection
|
|
|
|
- mean time to observe;
|
|
- mean time to correlate;
|
|
- proportion of incidents detected locally;
|
|
- evidence completeness;
|
|
- detection confidence calibration.
|
|
|
|
### 23.3 Containment
|
|
|
|
- mean time to constrain;
|
|
- mean time to isolate;
|
|
- containment success rate;
|
|
- average containment blast radius;
|
|
- cross-tenant incident count.
|
|
|
|
### 23.4 Recovery
|
|
|
|
- mean time to reconstitute;
|
|
- mean time to validate;
|
|
- percentage of workloads reproducibly redeployable;
|
|
- recovery test success rate;
|
|
- restoration integrity failure rate.
|
|
|
|
### 23.5 Regulation
|
|
|
|
- false-positive response rate;
|
|
- rollback success rate;
|
|
- number of expired temporary controls;
|
|
- number of chronic elevated-posture compartments;
|
|
- automated action override rate;
|
|
- response budget violations.
|
|
|
|
### 23.6 Learning
|
|
|
|
- countermeasure effectiveness;
|
|
- memory objects with valid provenance;
|
|
- stale-memory percentage;
|
|
- time from incident to tested policy improvement;
|
|
- repeated-incident rate.
|
|
|
|
---
|
|
|
|
## 24. Capability Decomposition
|
|
|
|
```text
|
|
kings-guard/
|
|
├── architecture/
|
|
│ ├── NetKingdomImmuneArchitecture.md
|
|
│ ├── TrustArchitecture.md
|
|
│ ├── TenantCompartmentArchitecture.md
|
|
│ ├── ImmuneControlLoops.md
|
|
│ └── DeploymentProfiles.md
|
|
│
|
|
├── security-genome/
|
|
│ ├── intent-registry/
|
|
│ ├── capability-registry/
|
|
│ ├── policy-canon/
|
|
│ ├── provenance-registry/
|
|
│ └── schemas/
|
|
│
|
|
├── identity-immunity/
|
|
│ ├── human-identity/
|
|
│ ├── workload-identity/
|
|
│ ├── agent-identity/
|
|
│ ├── attestation/
|
|
│ ├── trust-posture/
|
|
│ └── contracts/
|
|
│
|
|
├── compartment-control/
|
|
│ ├── tenant-isolation/
|
|
│ ├── application-boundaries/
|
|
│ ├── workload-boundaries/
|
|
│ ├── data-boundaries/
|
|
│ ├── shared-service-brokers/
|
|
│ └── isolation-profiles/
|
|
│
|
|
├── sentinel-mesh/
|
|
│ ├── edge-sentinel/
|
|
│ ├── identity-sentinel/
|
|
│ ├── admission-sentinel/
|
|
│ ├── runtime-sentinel/
|
|
│ ├── network-sentinel/
|
|
│ ├── data-sentinel/
|
|
│ └── observation-schema/
|
|
│
|
|
├── immune-coordination/
|
|
│ ├── signal-fabric/
|
|
│ ├── tenant-immune-node/
|
|
│ ├── platform-immune-node/
|
|
│ ├── federation/
|
|
│ └── signal-schema/
|
|
│
|
|
├── immune-decision/
|
|
│ ├── policy-evaluation/
|
|
│ ├── risk-evaluation/
|
|
│ ├── attack-hypothesis/
|
|
│ ├── response-selection/
|
|
│ └── decision-schema/
|
|
│
|
|
├── immune-response/
|
|
│ ├── response-orchestrator/
|
|
│ ├── effectors/
|
|
│ ├── authority-control/
|
|
│ ├── escalation/
|
|
│ └── response-schema/
|
|
│
|
|
├── immune-recovery/
|
|
│ ├── reconciliation/
|
|
│ ├── reconstitution/
|
|
│ ├── secret-rotation/
|
|
│ ├── data-restoration/
|
|
│ └── validation/
|
|
│
|
|
├── immune-memory/
|
|
│ ├── evidence-store/
|
|
│ ├── incident-graph/
|
|
│ ├── countermeasure-graph/
|
|
│ ├── outcome-learning/
|
|
│ ├── memory-federation/
|
|
│ └── memory-governance/
|
|
│
|
|
├── immune-regulation/
|
|
│ ├── tolerance-control/
|
|
│ ├── safety-envelopes/
|
|
│ ├── response-budgets/
|
|
│ ├── simulation/
|
|
│ ├── audit/
|
|
│ └── emergency-control/
|
|
│
|
|
└── reference-implementations/
|
|
├── kubernetes/
|
|
├── vm-platform/
|
|
├── serverless/
|
|
├── edge/
|
|
└── sovereign/
|
|
```
|
|
|
|
---
|
|
|
|
## 25. Stable Architecture Contracts
|
|
|
|
The architecture should stabilize contracts before selecting implementations.
|
|
|
|
### 25.1 Required Contracts
|
|
|
|
- Identity Contract;
|
|
- Attestation Contract;
|
|
- Trust Posture Contract;
|
|
- Security Genome Contract;
|
|
- Immune Observation Contract;
|
|
- Immune Signal Contract;
|
|
- Decision Contract;
|
|
- Response Authority Contract;
|
|
- Effector Contract;
|
|
- Response Outcome Contract;
|
|
- Recovery Contract;
|
|
- Memory Object Contract;
|
|
- Tenant Federation Contract;
|
|
- Audit Challenge Contract.
|
|
|
|
### 25.2 Effector Contract
|
|
|
|
```yaml
|
|
effector_request:
|
|
request_id: uuid
|
|
decision_ref: kg:decision:123
|
|
target_ref: kg:subject:456
|
|
action: isolate
|
|
scope: workload
|
|
ttl: PT15M
|
|
authority_ref: kg:authority:tenant-isolator
|
|
expected_outcome: "No network or workload execution outside forensic channel."
|
|
rollback:
|
|
mode: automatic
|
|
condition: "ttl-expired or explicit-release"
|
|
validation:
|
|
required: true
|
|
checks:
|
|
- network-isolation-confirmed
|
|
- execution-suspended
|
|
```
|
|
|
|
```yaml
|
|
effector_result:
|
|
request_id: uuid
|
|
effector_id: kg:effector:runtime-01
|
|
started_at: 2026-07-23T18:00:03Z
|
|
completed_at: 2026-07-23T18:00:04Z
|
|
status: successful
|
|
observed_outcome:
|
|
network_isolated: true
|
|
execution_suspended: true
|
|
evidence_refs:
|
|
- evidence://action/123
|
|
```
|
|
|
|
---
|
|
|
|
## 26. Deployment Profiles
|
|
|
|
### 26.1 Shared Kubernetes Profile
|
|
|
|
Suitable for:
|
|
|
|
- moderate-risk tenants;
|
|
- standard SaaS applications;
|
|
- stateless services.
|
|
|
|
Typical characteristics:
|
|
|
|
- shared cluster;
|
|
- tenant namespaces;
|
|
- workload identities;
|
|
- network policies;
|
|
- admission control;
|
|
- runtime sentinels;
|
|
- tenant-specific policy bundles;
|
|
- shared platform immune node;
|
|
- logical tenant memory separation.
|
|
|
|
### 26.2 Reinforced Kubernetes Profile
|
|
|
|
Suitable for:
|
|
|
|
- sensitive workloads;
|
|
- untrusted code;
|
|
- autonomous agents.
|
|
|
|
Typical characteristics:
|
|
|
|
- virtual clusters or dedicated node pools;
|
|
- sandboxed runtimes;
|
|
- tenant-specific trust domains;
|
|
- stronger egress mediation;
|
|
- dedicated tenant immune node;
|
|
- isolated evidence stores.
|
|
|
|
### 26.3 Dedicated Tenant Profile
|
|
|
|
Suitable for:
|
|
|
|
- high-value tenants;
|
|
- strict regulatory environments;
|
|
- large blast-radius concerns.
|
|
|
|
Typical characteristics:
|
|
|
|
- dedicated cluster;
|
|
- dedicated keys;
|
|
- dedicated tenant control plane;
|
|
- tenant-specific recovery environment;
|
|
- platform federation through signed defensive signals.
|
|
|
|
### 26.4 Sovereign Profile
|
|
|
|
Suitable for:
|
|
|
|
- national, critical-infrastructure or highly regulated contexts.
|
|
|
|
Typical characteristics:
|
|
|
|
- independent cloud account or physical environment;
|
|
- tenant-controlled roots of trust;
|
|
- local operations;
|
|
- restricted federation;
|
|
- explicit intelligence exchange;
|
|
- independent audit.
|
|
|
|
### 26.5 Edge Profile
|
|
|
|
Suitable for:
|
|
|
|
- intermittently connected environments;
|
|
- remote installations;
|
|
- industrial or physical systems.
|
|
|
|
Typical characteristics:
|
|
|
|
- strong local innate loop;
|
|
- cached policy;
|
|
- bounded autonomous response;
|
|
- delayed evidence synchronization;
|
|
- local recovery;
|
|
- federation after reconnection.
|
|
|
|
---
|
|
|
|
## 27. Example Incident Flow
|
|
|
|
### Scenario
|
|
|
|
A tenant workload attempts an external connection that is not declared in its Security Genome.
|
|
|
|
```mermaid
|
|
sequenceDiagram
|
|
participant W as Workload
|
|
participant S as Runtime Sentinel
|
|
participant N as Tenant Immune Node
|
|
participant D as Decision Engine
|
|
participant R as Regulation Controller
|
|
participant E as Network Effector
|
|
participant M as Immune Memory
|
|
participant H as Recovery Controller
|
|
|
|
W->>S: Attempt prohibited external connection
|
|
S->>S: Block attempt using local rule
|
|
S->>N: Publish observation and evidence
|
|
N->>D: Request contextual assessment
|
|
D->>D: Compare identity, intent, posture and history
|
|
D->>R: Propose temporary workload isolation
|
|
R->>R: Validate authority, blast radius and TTL
|
|
R->>E: Authorize isolation
|
|
E->>W: Isolate workload
|
|
E->>N: Return action outcome
|
|
N->>H: Request credential rotation and reconstitution
|
|
H->>W: Replace with known-good workload
|
|
H->>N: Return validation result
|
|
N->>M: Store evidence, action and outcome
|
|
M->>D: Update future decision context
|
|
```
|
|
|
|
### Result
|
|
|
|
- the local attempt is blocked immediately;
|
|
- the tenant compartment contains the possible compromise;
|
|
- credentials are rotated;
|
|
- the workload is replaced rather than merely restarted;
|
|
- the restored workload is validated;
|
|
- the incident becomes governed tenant memory;
|
|
- a shareable attack characteristic may be submitted to platform memory without exporting tenant-private evidence.
|
|
|
|
---
|
|
|
|
## 28. Federation and Collective Immunity
|
|
|
|
Federated environments may share defensive knowledge without sharing unrestricted telemetry.
|
|
|
|
### 28.1 Shareable Objects
|
|
|
|
- component vulnerability;
|
|
- attack technique;
|
|
- malicious artifact digest;
|
|
- defensive rule;
|
|
- mitigation guidance;
|
|
- response outcome summary;
|
|
- anonymized behaviour characteristic.
|
|
|
|
### 28.2 Non-Shareable by Default
|
|
|
|
- raw tenant logs;
|
|
- tenant data content;
|
|
- user identifiers;
|
|
- business process details;
|
|
- tenant-specific topology;
|
|
- unrestricted forensic images;
|
|
- confidential incident narrative.
|
|
|
|
### 28.3 Federation Requirements
|
|
|
|
- signed objects;
|
|
- source identity;
|
|
- confidence;
|
|
- scope;
|
|
- handling classification;
|
|
- expiry;
|
|
- revocation;
|
|
- compatibility information;
|
|
- policy-controlled import;
|
|
- quarantine before automatic enforcement.
|
|
|
|
---
|
|
|
|
## 29. Implementation Independence
|
|
|
|
Potential implementations may include:
|
|
|
|
- human identity providers;
|
|
- workload identity and attestation systems;
|
|
- policy engines;
|
|
- admission controllers;
|
|
- eBPF runtime sensors;
|
|
- service meshes;
|
|
- network policy engines;
|
|
- message brokers;
|
|
- evidence stores;
|
|
- graph databases;
|
|
- SIEM and SOAR systems;
|
|
- backup and restore systems;
|
|
- infrastructure reconciliation systems.
|
|
|
|
No implementation becomes part of the constitutional architecture merely because it is selected for an initial deployment.
|
|
|
|
Each implementation must map to one or more Kings Guard capabilities and conform to the corresponding contracts.
|
|
|
|
---
|
|
|
|
## 30. Security Assurance
|
|
|
|
### 30.1 Continuous Assurance
|
|
|
|
The architecture requires continuous validation of:
|
|
|
|
- identity issuance;
|
|
- attestation;
|
|
- policy enforcement;
|
|
- network boundaries;
|
|
- workload restrictions;
|
|
- response authority;
|
|
- recovery capability;
|
|
- evidence integrity;
|
|
- signal isolation;
|
|
- federation controls.
|
|
|
|
### 30.2 Adversarial Validation
|
|
|
|
The system should support:
|
|
|
|
- policy unit tests;
|
|
- architecture conformance tests;
|
|
- attack simulations;
|
|
- chaos-security experiments;
|
|
- credential compromise exercises;
|
|
- tenant-isolation tests;
|
|
- recovery exercises;
|
|
- memory-poisoning tests;
|
|
- response-amplification tests.
|
|
|
|
### 30.3 Independent Audit Path
|
|
|
|
Audit components must be able to challenge operational security conclusions.
|
|
|
|
The audit path should be organizationally and technically separated from the components it validates where practical.
|
|
|
|
---
|
|
|
|
## 31. Incremental Realization Roadmap
|
|
|
|
### Phase 1 — Security Genome and Identity Foundation
|
|
|
|
Deliver:
|
|
|
|
- tenant, subject and resource identifiers;
|
|
- workload identity;
|
|
- Security Genome schema;
|
|
- baseline policy hierarchy;
|
|
- signed deployment provenance;
|
|
- initial trust posture model.
|
|
|
|
Success condition:
|
|
|
|
Every protected workload has an attributable identity and declared intended behaviour.
|
|
|
|
### Phase 2 — Compartment and Membrane Foundation
|
|
|
|
Deliver:
|
|
|
|
- tenant isolation profiles;
|
|
- ingress and egress policy;
|
|
- shared-service brokerage;
|
|
- management-plane separation;
|
|
- tenant-specific encryption and secret boundaries.
|
|
|
|
Success condition:
|
|
|
|
A tenant compromise cannot trivially cross into another tenant.
|
|
|
|
### Phase 3 — Sentinel and Signal Mesh
|
|
|
|
Deliver:
|
|
|
|
- observation schema;
|
|
- edge, identity, runtime and network sentinels;
|
|
- tenant-scoped signal transport;
|
|
- evidence references;
|
|
- sentinel health monitoring.
|
|
|
|
Success condition:
|
|
|
|
Security-relevant behaviour is attributable, normalized and routed to the correct compartment.
|
|
|
|
### Phase 4 — Tenant Immune Nodes
|
|
|
|
Deliver:
|
|
|
|
- tenant-local correlation;
|
|
- policy evaluation;
|
|
- trust posture integration;
|
|
- response recommendations;
|
|
- tenant-private memory.
|
|
|
|
Success condition:
|
|
|
|
Common tenant incidents can be assessed without central manual correlation.
|
|
|
|
### Phase 5 — Bounded Automated Response
|
|
|
|
Deliver:
|
|
|
|
- response authority model;
|
|
- reversible effectors;
|
|
- response leases;
|
|
- rollback;
|
|
- action validation;
|
|
- response budgets.
|
|
|
|
Success condition:
|
|
|
|
Selected high-confidence incidents can be contained automatically without uncontrolled blast radius.
|
|
|
|
### Phase 6 — Recovery and Reconstitution
|
|
|
|
Deliver:
|
|
|
|
- immutable workload replacement;
|
|
- secret rotation;
|
|
- recovery workflows;
|
|
- restoration validation;
|
|
- recovery readiness metrics.
|
|
|
|
Success condition:
|
|
|
|
Compromised workloads can be replaced and validated predictably.
|
|
|
|
### Phase 7 — Adaptive Memory
|
|
|
|
Deliver:
|
|
|
|
- incident graph;
|
|
- countermeasure graph;
|
|
- response outcome learning;
|
|
- policy improvement workflow;
|
|
- memory review and decay.
|
|
|
|
Success condition:
|
|
|
|
Past incidents measurably improve future detection, containment and recovery.
|
|
|
|
### Phase 8 — Federated Collective Immunity
|
|
|
|
Deliver:
|
|
|
|
- shareable intelligence schema;
|
|
- signed federation;
|
|
- import quarantine;
|
|
- tenant privacy controls;
|
|
- countermeasure distribution.
|
|
|
|
Success condition:
|
|
|
|
Multiple environments can share useful defensive knowledge without exposing tenant-private evidence.
|
|
|
|
---
|
|
|
|
## 32. Initial Repository Deliverables
|
|
|
|
The initial `kings-guard` repository should contain:
|
|
|
|
1. `INTENT.md`
|
|
2. `NetKingdomImmuneArchitecture.md`
|
|
3. `SecurityGenomeSpecification.md`
|
|
4. `IdentityAndAttestationContract.md`
|
|
5. `TenantCompartmentStandard.md`
|
|
6. `ImmuneObservationSchema.md`
|
|
7. `ImmuneSignalSchema.md`
|
|
8. `ResponseAuthorityStandard.md`
|
|
9. `EffectorInterfaceSpecification.md`
|
|
10. `ImmuneMemoryModel.md`
|
|
11. `DeploymentProfiles.md`
|
|
12. `ThreatAndFailureModeCatalog.md`
|
|
13. `ImplementationRoadmap.md`
|
|
14. `ArchitectureDecisionRecords/`
|
|
|
|
---
|
|
|
|
## 33. Architectural Decisions
|
|
|
|
### AD-001 — Self Is Attested Intent-Conformant Identity
|
|
|
|
A subject is not trusted because it is internal. It is treated as self only while its identity, state and behaviour remain consistent with declared intent and policy.
|
|
|
|
### AD-002 — Tenants Are Immune Compartments
|
|
|
|
Every tenant has an explicit security boundary, policy scope, evidence scope, response authority and memory scope.
|
|
|
|
### AD-003 — Security Is Recursive
|
|
|
|
The same observation, decision, response, recovery and learning pattern applies from workload to federation level.
|
|
|
|
### AD-004 — Evidence Is Distinct From Interpretation
|
|
|
|
Raw evidence, observations, hypotheses, decisions and actions are separate entities.
|
|
|
|
### AD-005 — Automated Responses Are Bounded
|
|
|
|
Every automated action is limited by scope, authority, duration, evidence threshold and rollback requirements.
|
|
|
|
### AD-006 — Recovery Is a First-Class Security Capability
|
|
|
|
A security architecture is incomplete without tested restoration and reconstitution.
|
|
|
|
### AD-007 — Memory Is Governed and Reversible
|
|
|
|
Learned security knowledge requires provenance, confidence, scope, review, expiry and revocation.
|
|
|
|
### AD-008 — Shared Services Are Brokered
|
|
|
|
Shared services never create implicit cross-tenant trust.
|
|
|
|
### AD-009 — Architecture Contracts Outlive Products
|
|
|
|
Implementations may change without changing the stable Kings Guard capability model.
|
|
|
|
---
|
|
|
|
## 34. Open Questions
|
|
|
|
1. How should trust posture dimensions be normalized across different runtime types?
|
|
2. Which response actions may be authorized autonomously at each recursive level?
|
|
3. Which evidence classes may be federated across tenants?
|
|
4. How should tenants inspect or challenge platform-level security overrides?
|
|
5. Which Security Genome fields are mandatory for initial admission?
|
|
6. How should agent autonomy be represented as a bounded capability?
|
|
7. How should memory confidence decay over time?
|
|
8. Which isolation profiles should be mandatory for untrusted code execution?
|
|
9. How should security response budgets be calculated?
|
|
10. How should business continuity requirements influence defensive posture?
|
|
11. How should the architecture integrate with the wider NetKingdom identity and policy canon?
|
|
12. Which components belong in `kings-guard`, and which should remain independent reusable repositories?
|
|
|
|
---
|
|
|
|
## 35. Definition of Architectural Success
|
|
|
|
The Kings Guard architecture is successful when the platform can demonstrate that:
|
|
|
|
- every significant subject is identifiable;
|
|
- intended behaviour is explicitly declared;
|
|
- tenant boundaries are technically enforceable;
|
|
- security observations are attributable and contextualized;
|
|
- local disturbances can be contained locally;
|
|
- high-impact actions require proportionally stronger authority;
|
|
- compromised components can be reconstituted;
|
|
- recovery outcomes are validated;
|
|
- incidents improve future protection;
|
|
- tenant evidence remains appropriately isolated;
|
|
- collective learning does not become collective surveillance;
|
|
- defensive automation remains inspectable, reversible and governable.
|
|
|
|
---
|
|
|
|
## 36. Summary
|
|
|
|
Kings Guard Security implements the NetKingdom immune-security concept as a recursive, multi-tenant control architecture.
|
|
|
|
Its defining sequence is:
|
|
|
|
```text
|
|
identity
|
|
→ intent
|
|
→ observation
|
|
→ assessment
|
|
→ bounded response
|
|
→ recovery
|
|
→ validation
|
|
→ memory
|
|
```
|
|
|
|
Its defining structural principles are:
|
|
|
|
- identity instead of location-based trust;
|
|
- compartmentation instead of a trusted interior;
|
|
- local autonomous response with bounded authority;
|
|
- recovery as a peer of prevention and detection;
|
|
- evidence separated from interpretation;
|
|
- adaptive memory with provenance and decay;
|
|
- tenant sovereignty constrained by platform viability;
|
|
- replaceable implementations behind stable architecture contracts.
|
|
|
|
The result is not merely a collection of security products. It is a governed security organism designed to remain viable under continuous change, uncertainty and attack.
|