Complete KG-WP-0004-T02: re-home architecture planes onto Staff and Engine
Split the former Platform Immune Control Plane so kings-guard observes, judges, and proposes while access-engine remains the only decision point. Each of the nine planes now states its layer. immune_decision is an Engine artifact, not a posture record. Assistant: grok Assistant-Session: 01a05ef1-9e5a-70f2-b0ff-0b05d6b38ae9
This commit is contained in:
parent
d277e31ea8
commit
569def5584
3 changed files with 251 additions and 140 deletions
|
|
@ -28,7 +28,7 @@
|
|||
| task | KG-WP-0003-T07 | done | — | workplans/KG-WP-0003-evidence-completeness-and-live-observation.md |
|
||||
| task | KG-WP-0003-T08 | done | — | workplans/KG-WP-0003-evidence-completeness-and-live-observation.md |
|
||||
| task | KG-WP-0004-T01 | done | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
|
||||
| task | KG-WP-0004-T02 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
|
||||
| task | KG-WP-0004-T02 | done | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
|
||||
| task | KG-WP-0004-T03 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
|
||||
| task | KG-WP-0004-T04 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
|
||||
| task | KG-WP-0004-T05 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
|
||||
|
|
|
|||
|
|
@ -53,20 +53,24 @@ The architecture aims to preserve the platform's viability by enabling it to:
|
|||
|
||||
## 2. Architectural Proposition
|
||||
|
||||
Kings Guard Security is a **recursive adaptive security control system**.
|
||||
Kings Guard Security is a **recursive adaptive defence architecture**.
|
||||
`kings-guard` is the Staff repository in that architecture: it observes,
|
||||
judges, and proposes. It is not a control plane and not a decision point.
|
||||
|
||||
It continuously executes the following cycle:
|
||||
The estate cycle, with layer:
|
||||
|
||||
```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
|
||||
declare healthy intent # owners; Staff consumes the genome
|
||||
→ establish and attest identity # Tooling (key-cape) / Engine (user-engine)
|
||||
→ observe actual behaviour # Staff (kings-guard)
|
||||
→ compare behaviour with intent # Staff
|
||||
→ assess risk and confidence (posture) # Staff publishes; gate-house defines meaning
|
||||
→ propose bounded response # Staff — never manufactures authority
|
||||
→ decide # Engine (access-engine), the only PDP
|
||||
→ actuate # Engine + PEP; surface unowned, held at zero
|
||||
→ restore known-good operation # Engine / runtime
|
||||
→ validate the outcome
|
||||
→ retain governed security memory
|
||||
→ retain governed security memory # Staff; not a state plane for other layers
|
||||
```
|
||||
|
||||
The system does not treat trust as a permanent property.
|
||||
|
|
@ -90,25 +94,29 @@ Trust is a temporary, scoped and continuously reassessed condition derived from:
|
|||
|
||||
### 3.1 In Scope
|
||||
|
||||
This architecture covers:
|
||||
This document is an **estate map**. It names Staff, Engine, PEP, and Tooling
|
||||
parts of the immune loop so they are not collapsed into `kings-guard`.
|
||||
|
||||
- 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.
|
||||
The `kings-guard` **repository** owns observation, judgment, posture
|
||||
publication, bounded proposals, and governed immune memory. It does not own
|
||||
identity issuance, authorization decisions, secret custody, or actuation.
|
||||
|
||||
The estate map also covers, in other layers:
|
||||
|
||||
- human, device, workload, service and agent identities (Tooling / Engine);
|
||||
- authentication, authorization and continuous trust evaluation (Engine PDP);
|
||||
- tenant compartmentation, workload isolation, network and data boundaries
|
||||
(Engine / PEP / runtime);
|
||||
- policy distribution and enforcement (Engine / PEP);
|
||||
- admission control (Engine / PEP);
|
||||
- runtime detection and security event transport (PEP / Staff observation);
|
||||
- the single authorization decision point (Engine: `access-engine`);
|
||||
- automated and human-approved response (Engine + PEP; actuation unowned);
|
||||
- recovery and reconstitution (Engine / runtime);
|
||||
- incident evidence custody (Engine: `audit-core`);
|
||||
- adaptive security memory (Staff; not a state plane);
|
||||
- cross-tenant defensive learning (Staff publication);
|
||||
- security governance, observability and assurance.
|
||||
|
||||
### 3.2 Out of Scope
|
||||
|
||||
|
|
@ -233,6 +241,9 @@ Examples:
|
|||
|
||||
Governed knowledge derived from observations, incidents, threat intelligence, countermeasures and response outcomes.
|
||||
|
||||
**Layer: Staff.** Memory is not a state plane. Other layers must not depend
|
||||
on it at runtime unless it is catalogued as Tooling.
|
||||
|
||||
### 4.11 Tolerance
|
||||
|
||||
The explicit permission for a known deviation, exception or variation that must not trigger an inappropriate defensive response.
|
||||
|
|
@ -260,10 +271,10 @@ The replacement of a compromised or uncertain component with a newly established
|
|||
| 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 |
|
||||
| Lymph nodes | Local correlation and judgment | Tenant posture / immune node (Staff) |
|
||||
| Adaptive immunity | Incident-specific learning | Posture, proposals, and governed memory (Staff) |
|
||||
| Antibodies | Targeted countermeasures | Policy rules rendered by the PDP; Staff may propose |
|
||||
| Complement system | Immediate action primitives | Response effectors (PEP-shaped; not Staff) |
|
||||
| Memory cells | Retained defensive knowledge | Immune Memory |
|
||||
| Regulatory T cells | Safety and restraint | Immune Regulation |
|
||||
| Inflammation | Elevated defensive state | Defensive Posture Management |
|
||||
|
|
@ -433,13 +444,18 @@ flowchart TB
|
|||
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"]
|
||||
subgraph STAFF["Staff — observe, judge, propose"]
|
||||
JUDGE["Posture and Phenotype Judgment"]
|
||||
SIGNAL["Immune Signal Fabric"]
|
||||
MEMORY["Governed Immune Memory"]
|
||||
PROPOSE["Bounded Response Proposals"]
|
||||
end
|
||||
|
||||
subgraph ENGINE["Engine — facts, evidence, the only decision"]
|
||||
IDENTITY["Identity facts — user-engine / key-cape"]
|
||||
DECISION["access-engine — the only PDP"]
|
||||
AUDIT["audit-core — evidence custody"]
|
||||
ACTUATE["Actuation surface — unowned, held at zero"]
|
||||
end
|
||||
|
||||
subgraph TENANT["Tenant Immune Compartment"]
|
||||
|
|
@ -447,22 +463,23 @@ flowchart TB
|
|||
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"]
|
||||
NODE["Tenant Immune Node — Staff judgment"]
|
||||
EFFECTORS["Tenant Response Effectors — PEP"]
|
||||
RECOVERY["Tenant Recovery — Engine / runtime"]
|
||||
end
|
||||
|
||||
subgraph SHARED["Shared Platform Compartments"]
|
||||
BROKER["Brokered Shared Services"]
|
||||
INFRA["Compute, Network, Storage and Runtime"]
|
||||
PSENTINELS["Platform Sentinels"]
|
||||
PEFFECTORS["Platform Effectors"]
|
||||
PEFFECTORS["Platform Effectors — PEP"]
|
||||
end
|
||||
|
||||
EXT --> MEMBRANE
|
||||
MEMBRANE --> APPLICATIONS
|
||||
|
||||
GENOME --> IDENTITY
|
||||
GENOME --> JUDGE
|
||||
GENOME --> DECISION
|
||||
GENOME --> EDUCATION
|
||||
|
||||
|
|
@ -474,16 +491,21 @@ flowchart TB
|
|||
INFRA --> PSENTINELS
|
||||
|
||||
SENTINELS --> NODE
|
||||
NODE --> JUDGE
|
||||
NODE --> SIGNAL
|
||||
PSENTINELS --> SIGNAL
|
||||
|
||||
SIGNAL --> JUDGE
|
||||
JUDGE --> PROPOSE
|
||||
JUDGE --> MEMORY
|
||||
PROPOSE --> DECISION
|
||||
SIGNAL --> DECISION
|
||||
MEMORY --> DECISION
|
||||
RISK --> REGULATION
|
||||
DECISION --> REGULATION
|
||||
RISK --> DECISION
|
||||
MEMORY --> JUDGE
|
||||
|
||||
REGULATION --> EFFECTORS
|
||||
REGULATION --> PEFFECTORS
|
||||
DECISION --> ACTUATE
|
||||
ACTUATE --> EFFECTORS
|
||||
ACTUATE --> PEFFECTORS
|
||||
|
||||
EFFECTORS --> APPLICATIONS
|
||||
EFFECTORS --> MEMBRANE
|
||||
|
|
@ -492,20 +514,45 @@ flowchart TB
|
|||
|
||||
RECOVERY --> APPLICATIONS
|
||||
SIGNAL --> MEMORY
|
||||
AUDIT --> MEMORY
|
||||
AUDIT --> DECISION
|
||||
|
||||
APPLICATIONS <--> BROKER
|
||||
```
|
||||
|
||||
Staff memory informs kings-guard's own later judgment and may be published as
|
||||
evidence. It is not a runtime input to `access-engine` or to a PEP (§3.4 rule 3).
|
||||
Actuation is drawn because the loop requires it; the surface is unowned and
|
||||
held at zero (§9.2). No argument may assume isolation happens automatically.
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## 9. Architectural Planes
|
||||
|
||||
The architecture is organized into nine orthogonal planes.
|
||||
The architecture is organized into nine orthogonal planes. Each plane states
|
||||
its layer. Staff planes observe, judge, and propose. Engine planes decide,
|
||||
hold facts, or custody evidence. Tooling holds identity and secrets. PEP is
|
||||
a shape, not a plane: anything that causes a protected side effect. Actuation
|
||||
is an Engine concept held at zero (§9.2).
|
||||
|
||||
| Plane | Layer |
|
||||
| --- | --- |
|
||||
| 9.1 Security Genome | Staff consumes; owners produce |
|
||||
| 9.2 Identity and Attestation | Tooling (`key-cape`) + Engine (`user-engine`) |
|
||||
| 9.3 Membrane and Compartment | Engine / PEP / runtime |
|
||||
| 9.4 Sentinel and Evidence | Staff observes Staff-reachable sources; many sentinels are PEP/runtime |
|
||||
| 9.5 Signal and Coordination | Staff |
|
||||
| 9.6 Decision | Engine (`access-engine`) — the only PDP |
|
||||
| 9.7 Response | Engine + PEP; actuation unowned |
|
||||
| 9.8 Recovery | Engine / runtime |
|
||||
| 9.9 Memory and Adaptation | Staff; not a state plane |
|
||||
|
||||
### 9.1 Security Genome Plane
|
||||
|
||||
**Layer: Staff consumes; workload and service owners produce.** kings-guard
|
||||
does not run the intent registry.
|
||||
|
||||
The Security Genome Plane defines intended healthy operation.
|
||||
|
||||
#### Responsibilities
|
||||
|
|
@ -587,6 +634,10 @@ security_genome_record:
|
|||
|
||||
### 9.2 Identity and Attestation Plane
|
||||
|
||||
**Layer: Tooling (`key-cape`) + Engine (`user-engine`).** Issuance is not
|
||||
Staff. Trust-posture *publication* is Staff; a lifetime other layers consume
|
||||
is an input claim to the PDP, not a Staff verdict.
|
||||
|
||||
This plane establishes and reassesses subject identity.
|
||||
|
||||
#### Identity Classes
|
||||
|
|
@ -637,6 +688,9 @@ trust_posture:
|
|||
|
||||
### 9.3 Membrane and Compartment Plane
|
||||
|
||||
**Layer: Engine / PEP / runtime.** Policy enforcement at a membrane is
|
||||
PEP-shaped. kings-guard does not hold the boundary.
|
||||
|
||||
This plane establishes nested boundaries.
|
||||
|
||||
#### Membrane Types
|
||||
|
|
@ -665,7 +719,14 @@ This plane establishes nested boundaries.
|
|||
|
||||
### 9.4 Sentinel and Evidence Plane
|
||||
|
||||
Sentinels observe security-relevant behaviour.
|
||||
**Layer: Staff observes Staff-reachable sources.** Many sentinels run in
|
||||
PEP/runtime. Identity and secret observation stay pending (blocked-clean):
|
||||
no Tooling client is opened to fill them. A "control-plane sentinel" watches
|
||||
a Kubernetes or platform control plane; it does not make kings-guard one.
|
||||
|
||||
Sentinels observe security-relevant behaviour. An observation is not an
|
||||
interpretation: assessment and proposed response belong on phenotype,
|
||||
posture, and signal, not on this record.
|
||||
|
||||
#### Sentinel Classes
|
||||
|
||||
|
|
@ -715,21 +776,16 @@ immune_observation:
|
|||
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
|
||||
```
|
||||
|
||||
Phenotype, posture, and a bounded `effector_request` are derived later.
|
||||
They are not fields of the observation.
|
||||
|
||||
### 9.5 Signal and Coordination Plane
|
||||
|
||||
**Layer: Staff.** Signals coordinate judgment and proposals. They are not
|
||||
authorization.
|
||||
|
||||
The Immune Signal Fabric transports authenticated security messages.
|
||||
|
||||
#### Signal Types
|
||||
|
|
@ -739,15 +795,17 @@ The Immune Signal Fabric transports authenticated security messages.
|
|||
- policy violation;
|
||||
- integrity failure;
|
||||
- attack hypothesis;
|
||||
- response request;
|
||||
- response authorization;
|
||||
- action result;
|
||||
- response request (Staff proposal);
|
||||
- action result (PEP / Engine, when actuation exists);
|
||||
- recovery status;
|
||||
- escalation;
|
||||
- countermeasure publication;
|
||||
- memory update;
|
||||
- audit challenge.
|
||||
|
||||
Authorization is not a signal type. The PDP renders a decision record. A
|
||||
Staff signal may *request* a restrictive direction; it must not authorize.
|
||||
|
||||
#### Signal Properties
|
||||
|
||||
Every signal must carry:
|
||||
|
|
@ -780,7 +838,16 @@ Raw tenant evidence must not be elevated to platform or federation scope without
|
|||
|
||||
### 9.6 Decision Plane
|
||||
|
||||
The Decision Plane evaluates observations and determines response.
|
||||
**Layer: Engine (`access-engine`).** This is the estate's only policy
|
||||
decision point (layer model §6). It is not a kings-guard output. Posture
|
||||
is an input claim; it is not a verdict.
|
||||
|
||||
The Decision Plane renders authorization from authoritative inputs. Staff
|
||||
does not determine response here.
|
||||
|
||||
`immune_decision` below is an **Engine artifact** — the `access-engine`
|
||||
decision record — not a posture assessment. A Staff node is not the
|
||||
`authority` that isolates.
|
||||
|
||||
#### Decision Inputs
|
||||
|
||||
|
|
@ -800,41 +867,45 @@ The Decision Plane evaluates observations and determines response.
|
|||
#### Decision Output
|
||||
|
||||
```yaml
|
||||
# Engine artifact (access-engine). Not a kings-guard posture record.
|
||||
immune_decision:
|
||||
decision_id: uuid
|
||||
decided_at: 2026-07-23T18:00:02Z
|
||||
pdp: access-engine
|
||||
|
||||
scope:
|
||||
tenant_id: tenant-a
|
||||
compartment_id: app-documents
|
||||
|
||||
hypothesis:
|
||||
type: compromised-workload
|
||||
confidence: 0.91
|
||||
inputs:
|
||||
posture_ref: kg:posture:…
|
||||
genome_ref: kg:genome:…
|
||||
evidence_refs:
|
||||
- evidence://event/9876
|
||||
|
||||
authorized_response:
|
||||
action: isolate
|
||||
target: spiffe://tenant-a.example/workload/document-converter
|
||||
ttl: PT15M
|
||||
authority: tenant-immune-node
|
||||
authority: access-engine
|
||||
enforcement: pep
|
||||
# Actuation surface unowned and held at zero (§9.2). This field is the
|
||||
# intended Engine output, not a claim that isolation already happens.
|
||||
rollback: automatic
|
||||
|
||||
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.
|
||||
**Layer: Engine + PEP. Actuation is unowned and held at zero (§9.2).**
|
||||
kings-guard proposes the rungs; it does not execute them. Execution, safety
|
||||
envelope, and the isolate grant are T04 of KG-WP-0004.
|
||||
|
||||
The Response Plane is where defensive *actions* would be performed, once an
|
||||
actuation surface exists.
|
||||
|
||||
#### Response Ladder
|
||||
|
||||
|
|
@ -868,6 +939,9 @@ Every automated action requires:
|
|||
|
||||
### 9.8 Recovery and Reconstitution Plane
|
||||
|
||||
**Layer: Engine / runtime.** Staff may request reconstitution. It does not
|
||||
redeploy, rotate, or evacuate.
|
||||
|
||||
Recovery is an architectural peer of detection and response.
|
||||
|
||||
#### Recovery Capabilities
|
||||
|
|
@ -902,6 +976,11 @@ A component must not return directly from `isolated` to `healthy` without valida
|
|||
|
||||
### 9.9 Memory and Adaptation Plane
|
||||
|
||||
**Layer: Staff.** Immune memory informs kings-guard's own later judgment and
|
||||
may be published as evidence. No engine, PEP, or workload may read it as a
|
||||
runtime input. Making it one is a §4 Tooling catalog change, not a quiet
|
||||
edge from this plane into §9.6.
|
||||
|
||||
The Memory Plane retains and evaluates security knowledge.
|
||||
|
||||
#### Memory Objects
|
||||
|
|
@ -971,10 +1050,10 @@ flowchart TB
|
|||
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"]
|
||||
TN["Tenant Immune Node — Staff"]
|
||||
TR["Tenant Response Effectors — PEP"]
|
||||
TMEM["Tenant Immune Memory — Staff"]
|
||||
TREC["Tenant Recovery Controller — Engine"]
|
||||
|
||||
TM --> TW
|
||||
TI --> TM
|
||||
|
|
@ -995,19 +1074,27 @@ flowchart TB
|
|||
end
|
||||
```
|
||||
|
||||
The Staff node judges and proposes. Effectors fire only on a decision
|
||||
record from `access-engine`, or on a recorded PEP stance (§6.4). The arrow
|
||||
`TN --> TR` is coordination, not a second PDP.
|
||||
|
||||
### 10.1 Tenant-Local Responsibilities
|
||||
|
||||
The tenant immune system owns:
|
||||
The tenant immune **Staff** surface owns:
|
||||
|
||||
- tenant-specific security intent;
|
||||
- application and data policies;
|
||||
- tenant identities and delegated roles;
|
||||
- tenant-specific security intent (genome consumption);
|
||||
- tenant-specific anomaly baselines;
|
||||
- local incident correlation;
|
||||
- local response decisions;
|
||||
- tenant-private evidence;
|
||||
- tenant-specific countermeasures;
|
||||
- tenant recovery procedures.
|
||||
- local incident correlation and judgment;
|
||||
- bounded response *proposals*;
|
||||
- tenant-private evidence references;
|
||||
- tenant-specific countermeasures as published memory.
|
||||
|
||||
It does not own local response *decisions*. Those remain the one PDP.
|
||||
A local PEP applying a prior decision, or a declared stance, is §6.4 — not
|
||||
a second decision point.
|
||||
|
||||
Tenant identities, application policy administration, and recovery
|
||||
procedures belong to Engine / Tooling / runtime, not to the Staff node.
|
||||
|
||||
### 10.2 Platform Responsibilities
|
||||
|
||||
|
|
@ -1228,12 +1315,12 @@ Target latency: days to quarters.
|
|||
|
||||
| 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 |
|
||||
| System 1 — Operations | Workload, application and tenant sentinels (observe) and PEP-shaped effectors (act, when actuation exists) |
|
||||
| System 2 — Coordination | Signal routing, deduplication, suppression and incident coordination (Staff) |
|
||||
| System 3 — Control | `access-engine` as PDP; PEP stance maps; not a Staff response controller |
|
||||
| System 3* — Audit | Independent validation, forensic inspection and adversarial testing (`audit-core`, whitehat-security) |
|
||||
| System 4 — Intelligence | Threat research, simulation, and governed immune memory (Staff; not a state plane) |
|
||||
| System 5 — Policy | Doctrine (gate-house) compiled into the versioned policy package the PDP applies |
|
||||
|
||||
The same mapping applies recursively to:
|
||||
|
||||
|
|
@ -1304,6 +1391,15 @@ response_authority:
|
|||
|
||||
## 17. Defensive Posture Model
|
||||
|
||||
**Layer: Staff publishes; gate-house defines authority meaning;
|
||||
`access-engine` renders.** Posture is not a privilege source. It may reduce
|
||||
authority, require step-up, or request containment; it MUST NOT
|
||||
probabilistically manufacture additional authority.
|
||||
|
||||
The executable scaffold uses `healthy`, `elevated`, `inflamed`,
|
||||
`compromised`. The colours below are a reading aid, not a second grading
|
||||
scale and not a second decision point.
|
||||
|
||||
The system maintains explicit defensive posture.
|
||||
|
||||
| Posture | Meaning | Typical controls |
|
||||
|
|
@ -1469,7 +1565,9 @@ erDiagram
|
|||
SUBJECT ||--o{ OBSERVATION : produces
|
||||
RESOURCE ||--o{ OBSERVATION : concerns
|
||||
OBSERVATION }o--o{ EVIDENCE : references
|
||||
OBSERVATION ||--o{ DECISION : informs
|
||||
OBSERVATION ||--o{ POSTURE : informs
|
||||
POSTURE ||--o{ SIGNAL : emits
|
||||
SIGNAL ||--o{ DECISION : inputs
|
||||
DECISION ||--o{ RESPONSE_ACTION : authorizes
|
||||
RESPONSE_ACTION ||--o{ RESPONSE_OUTCOME : produces
|
||||
RESPONSE_OUTCOME ||--o{ MEMORY_OBJECT : informs
|
||||
|
|
@ -1485,14 +1583,18 @@ The data model must preserve separation among:
|
|||
|
||||
- raw evidence;
|
||||
- normalized observation;
|
||||
- phenotype and posture (Staff judgment);
|
||||
- attack hypothesis;
|
||||
- decision;
|
||||
- response authorization;
|
||||
- action execution;
|
||||
- decision (`access-engine` only);
|
||||
- response authorization (the same decision record);
|
||||
- action execution (PEP / actuation surface, unowned today);
|
||||
- outcome;
|
||||
- lesson;
|
||||
- policy change.
|
||||
|
||||
Immune memory may be derived from outcome and lesson. It MUST NOT appear as
|
||||
an input arrow into DECISION.
|
||||
|
||||
---
|
||||
|
||||
## 20. Policy Architecture
|
||||
|
|
@ -1526,13 +1628,14 @@ Policies are layered.
|
|||
|
||||
A lower layer may strengthen a higher-layer requirement but may weaken it only through an authorized exception.
|
||||
|
||||
Policy decisions must expose:
|
||||
**Policy decisions are rendered by `access-engine`.** Reconstructability is
|
||||
a PDP obligation, not a Staff API. A decision record must expose:
|
||||
|
||||
- effective policies;
|
||||
- precedence;
|
||||
- exceptions;
|
||||
- reason;
|
||||
- decision inputs;
|
||||
- decision inputs (including posture as a claim, not as a verdict);
|
||||
- resulting constraints.
|
||||
|
||||
---
|
||||
|
|
@ -1584,8 +1687,9 @@ Security observability includes both threat state and immune-system health.
|
|||
|
||||
- sentinel coverage;
|
||||
- signal delivery latency;
|
||||
- decision latency;
|
||||
- response latency;
|
||||
- judgment latency (Staff);
|
||||
- decision latency (PDP);
|
||||
- response latency (PEP / actuation, when the surface exists);
|
||||
- failed effectors;
|
||||
- stale trust posture;
|
||||
- policy distribution lag;
|
||||
|
|
@ -1708,22 +1812,22 @@ kings-guard/
|
|||
│
|
||||
├── immune-coordination/
|
||||
│ ├── signal-fabric/
|
||||
│ ├── tenant-immune-node/
|
||||
│ ├── tenant-immune-node/ # Staff judgment, not a PDP
|
||||
│ ├── platform-immune-node/
|
||||
│ ├── federation/
|
||||
│ └── signal-schema/
|
||||
│
|
||||
├── immune-decision/
|
||||
│ ├── policy-evaluation/
|
||||
│ ├── risk-evaluation/
|
||||
├── immune-judgment/ # Staff — not a second decision point
|
||||
│ ├── phenotype/
|
||||
│ ├── posture/
|
||||
│ ├── attack-hypothesis/
|
||||
│ ├── response-selection/
|
||||
│ └── decision-schema/
|
||||
│ ├── response-proposal/
|
||||
│ └── posture-schema/
|
||||
│
|
||||
├── immune-response/
|
||||
│ ├── response-orchestrator/
|
||||
│ ├── effectors/
|
||||
│ ├── authority-control/
|
||||
├── immune-response/ # Engine + PEP; not a kings-guard tree
|
||||
│ ├── proposal-contract/ # Staff emits; see ImmuneContracts.md
|
||||
│ ├── effectors/ # PEP-shaped; actuation unowned
|
||||
│ ├── authority-control/ # access-engine
|
||||
│ ├── escalation/
|
||||
│ └── response-schema/
|
||||
│
|
||||
|
|
@ -1772,9 +1876,9 @@ The architecture should stabilize contracts before selecting implementations.
|
|||
- Security Genome Contract;
|
||||
- Immune Observation Contract;
|
||||
- Immune Signal Contract;
|
||||
- Decision Contract;
|
||||
- Decision Contract (owned by `access-engine`; statute §17);
|
||||
- Response Authority Contract;
|
||||
- Effector Contract;
|
||||
- Effector Contract (Staff proposal shape; execution is PEP);
|
||||
- Response Outcome Contract;
|
||||
- Recovery Contract;
|
||||
- Memory Object Contract;
|
||||
|
|
@ -1917,29 +2021,27 @@ A tenant workload attempts an external connection that is not declared in its Se
|
|||
```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
|
||||
participant S as Runtime Sentinel (PEP-shaped)
|
||||
participant N as Tenant Immune Node (Staff)
|
||||
participant D as access-engine (PDP)
|
||||
participant E as Network Effector (PEP)
|
||||
participant M as Immune Memory (Staff)
|
||||
participant H as Recovery (Engine / runtime)
|
||||
|
||||
W->>S: Attempt prohibited external connection
|
||||
S->>S: Block attempt using local rule
|
||||
S->>S: Block attempt under existing policy (local PEP)
|
||||
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
|
||||
N->>N: Derive phenotype and posture
|
||||
N->>D: Publish posture as an input claim plus a containment proposal
|
||||
D->>D: Render the only authorization decision
|
||||
D->>E: Decision record (actuation unowned today — intended hop)
|
||||
E->>W: Isolate workload if and when actuation exists
|
||||
E->>N: Return action outcome
|
||||
N->>H: Request credential rotation and reconstitution
|
||||
H->>W: Replace with known-good workload
|
||||
H->>N: Return validation result
|
||||
N->>M: Store evidence, action and outcome
|
||||
M->>D: Update future decision context
|
||||
N->>M: Store evidence, proposal, decision ref and outcome
|
||||
Note over M,D: Memory is not a runtime input to the PDP
|
||||
```
|
||||
|
||||
### Result
|
||||
|
|
@ -2106,14 +2208,14 @@ Security-relevant behaviour is attributable, normalized and routed to the correc
|
|||
Deliver:
|
||||
|
||||
- tenant-local correlation;
|
||||
- policy evaluation;
|
||||
- trust posture integration;
|
||||
- response recommendations;
|
||||
- tenant-private memory.
|
||||
- response *recommendations* (proposals, not PDP evaluation);
|
||||
- tenant-private memory that is not a runtime input to other layers.
|
||||
|
||||
Success condition:
|
||||
|
||||
Common tenant incidents can be assessed without central manual correlation.
|
||||
Common tenant incidents can be judged without central manual correlation.
|
||||
Policy evaluation remains `access-engine`.
|
||||
|
||||
### Phase 5 — Bounded Automated Response
|
||||
|
||||
|
|
@ -2273,7 +2375,7 @@ The Kings Guard architecture is successful when the platform can demonstrate tha
|
|||
|
||||
## 36. Summary
|
||||
|
||||
Kings Guard Security implements the NetKingdom immune-security concept as a recursive, multi-tenant control architecture.
|
||||
Kings Guard Security implements the NetKingdom immune-security concept as a recursive, multi-tenant defence architecture. `kings-guard` observes, judges, and proposes. Engines decide. PEPs act, when an actuation surface exists.
|
||||
|
||||
Its defining sequence is:
|
||||
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ frontmatter through §36. T02–T04 slices are listed in §4 of that file.
|
|||
|
||||
```task
|
||||
id: KG-WP-0004-T02
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "2f7b3303-d87c-5c29-9249-98afd746631f"
|
||||
```
|
||||
|
|
@ -137,6 +137,15 @@ Done when:
|
|||
- `immune_decision` is explicitly an Engine artifact, not a kings-guard
|
||||
posture record.
|
||||
|
||||
**Done 2026-09-02:** §8 subgraph is Staff (observe/judge/propose) vs Engine
|
||||
(PDP, facts, evidence, unowned actuation) — no kings-guard control plane.
|
||||
Each of the nine planes states its layer. `immune_decision` is labelled an
|
||||
`access-engine` artifact. Observation no longer carries assessment/proposed
|
||||
response. Related T02 slices: §2 cycle, §3.1 estate-vs-repo, §5 analogy,
|
||||
§10 node, §15 VSM, §17 posture publisher, §19 data model, §20.2, §22.2,
|
||||
§24 `immune-judgment/`, §25.1, §27 decision hops, §31 Phase 4. T03/T04
|
||||
strings and actuation copy left in place.
|
||||
|
||||
## Task: Disambiguate remaining "control plane" strings
|
||||
|
||||
```task
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue