coulomb/kings-guard
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Complete KG-WP-0004-T04: propose containment, do not actuate

Browse source 
Response ladder, authority grant, effector example, and Phase 5 now
separate Staff proposals from Engine/PEP execution. Actuation stays
unowned. Origin linkage matches WP-0003-T06.

Assistant: grok
Assistant-Session: 01a05ef1-9e5a-70f2-b0ff-0b05d6b38ae9
This commit is contained in:
tegwick 2026-09-02 08:11:34 +02:00
parent ac69d96f4e
commit ac3aa1287e
3 changed files with 169 additions and 107 deletions
Download patch file Download diff file Expand all files Collapse all files

2
WORK-RECORDS.md
View file

@ -30,7 +30,7 @@
| task | KG-WP-0004-T01 | done | — | 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 | done | — | 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-T04 | done | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
| task | KG-WP-0004-T05 | todo | — | workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md |
| intake | KG-IN-0001 | closed | — | intakes/intakes.md |
| intake | KG-IN-0002 | closed | — | intakes/intakes.md |

265
specs/NetKingdomImmuneArchitecture.md
View file

@ -43,7 +43,8 @@ The system is intended to protect heterogeneous cloud environments containing:
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;
2. identify disturbances near their origin and *propose* containment
(Engine/PEP perform it, when an actuation surface exists);
3. adapt defensive measures to new evidence;
4. restore known-good operation after compromise;
5. learn without violating tenant confidentiality;
@ -225,9 +226,11 @@ An authenticated, typed message used to coordinate security assessment or respon
### 4.9 Effector
A component authorized to perform a concrete defensive action.
A **PEP-shaped** component authorized to perform a concrete defensive
action under a decision record (or a recorded stance). kings-guard does
not hold effectors. It emits an `effector_request` as a **proposal**.
Examples:
Examples of actions a PEP might perform, once actuation exists:
- reject;
- throttle;
@ -315,13 +318,17 @@ Compromise of one compartment must not automatically compromise another.
Disturbances should be handled as close to their origin as safely possible.
Local components receive bounded authority and escalate when:
Local **PEPs** apply an existing decision or a declared stance (§6.4 of
the layer model). Staff components emit bounded *proposals* and escalate
when:
- evidence is insufficient;
- impact may cross compartment boundaries;
- response exceeds local authority;
- the proposal exceeds what local PEPs may already enforce;
- platform-level coordination is required.
A Staff node does not receive a standing isolate grant.
### 6.5 Evidence Before Judgment
Observations, interpretations, decisions and actions remain distinguishable.
@ -336,17 +343,20 @@ This enables:
### 6.6 Reversible Automation Before Irreversible Action
Automated response should prefer temporary, scoped and reversible controls.
Where actuation exists, automated response should prefer temporary, scoped
and reversible controls. Irreversible or high-impact actions require
stronger evidence or approval.
Irreversible or high-impact actions require stronger evidence or approval.
kings-guard does not automate isolate. It proposes. The actuation surface
is unowned and held at zero.
### 6.7 Recovery Before Perfect Prevention
The system assumes that some controls will fail.
Every critical capability must have:
Every critical capability must have, as an **estate** property:
- containment;
- containment (Engine + PEP; unowned today);
- restoration;
- reconstitution;
- validation;
@ -423,8 +433,8 @@ Each level has:
- a declared intent;
- observable state;
- policy;
- bounded authority;
- local memory;
- bounded proposal scope (Staff) or a decision/stance (PEP);
- local memory (Staff; not a state plane);
- escalation rules;
- recovery procedures.
@ -902,32 +912,35 @@ immune_decision:
### 9.7 Response Plane
**Layer: Engine + PEP. Actuation is unowned and held at zero (§9.2).**
kings-guard proposes the rungs; it does not execute them. Execution, safety
envelope, and the isolate grant are T04 of KG-WP-0004.
kings-guard proposes the rungs; it does not execute them.
The Response Plane is where defensive *actions* would be performed, once an
actuation surface exists.
actuation surface exists. Until then the ladder is a vocabulary of
**proposals** (Staff) and of **intended PEP actions** (Engine/PEP).
#### 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 |
| Level | Kind | Staff (propose) | Engine / PEP (execute, when actuation exists) |
|---|---|---|---|
| R0 | Observe | collect additional evidence | — |
| R1 | Challenge | request step-up | require stronger authentication or attestation |
| R2 | Constrain | propose reduced permissions, destinations or rate | reduce them under a decision record |
| R3 | Degrade | propose disabling nonessential functions | disable them under a decision record |
| R4 | Isolate | propose quarantine of a subject, workload or segment | quarantine under a decision record |
| R5 | Revoke | propose session/credential/authority invalidation | invalidate under a decision record |
| R6 | Terminate | propose stopping execution | stop it under a decision record |
| R7 | Reconstitute | request replacement with known-good state | replace (runtime / Engine) |
| R8 | Restore | request validated recovery | recover (runtime / Engine) |
| R9 | Immunize | publish a tested countermeasure as evidence | distribute only via policy the PDP renders |
R0 is Staff. R1–R9 change authority or runtime state; Staff may only
propose them. No argument may assume they happen automatically.
#### Response Safety Envelope
Every automated action requires:
Every **PEP / actuation** action, when the surface exists, requires:
- authorized issuer;
- a decision record from `access-engine`, or a recorded §6.4 stance;
- permitted scope;
- maximum blast radius;
- time-to-live;
@ -938,6 +951,9 @@ Every automated action requires:
- escalation condition;
- audit record.
A Staff `effector_request` is not that action. It is the proposal that
the PDP may render.
### 9.8 Recovery and Reconstitution Plane
**Layer: Engine / runtime.** Staff may request reconstitution. It does not
@ -1118,7 +1134,7 @@ 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;
- contain platform-level incidents (Engine + PEP; not a Staff isolate);
- enforce agreed minimum security controls.
Every override must be:
@ -1241,7 +1257,9 @@ Reassessment occurs when:
### 14.1 Fast Local Loop
Purpose: immediate containment.
Purpose: immediate **PEP** enforcement of an existing decision or declared
stance. This is not kings-guard containing anything. The live example is
`qonto-assistant`'s deny-escalation lockout.
```text
sense
@ -1258,7 +1276,7 @@ Examples:
- block prohibited syscall;
- deny unapproved egress;
- throttle abusive request;
- isolate a process.
- isolate a process (PEP, under existing policy — not a Staff grant).
### 14.2 Tenant Adaptive Loop
@ -1267,20 +1285,21 @@ Purpose: contextual tenant response.
```text
correlate tenant observations
→ assess against tenant intent
→ select bounded response
→ emit a bounded proposal
→ (PDP decides; PEP acts, when actuation exists)
→ observe outcome
→ update tenant memory
```
Target latency: seconds to minutes.
Examples:
Examples of **Staff proposals** (not actions this repository performs):
- revoke a tenant session;
- restrict an application;
- rotate tenant credentials;
- isolate a tenant workload group;
- deploy a tenant-specific detection.
- request session revocation;
- request application restriction;
- request credential rotation;
- request isolation of a tenant workload group;
- publish a tenant-specific detection.
### 14.3 Platform Coordination Loop
@ -1289,9 +1308,9 @@ Purpose: protect shared infrastructure and tenants.
```text
aggregate platform signals
→ identify shared or cross-tenant impact
→ coordinate platform response
→ validate containment
→ distribute safe countermeasures
→ propose / coordinate platform response
→ validate a PEP containment outcome, when one exists
→ distribute safe countermeasures as evidence, not as extra authority
```
Target latency: seconds to hours.
@ -1335,11 +1354,14 @@ The same mapping applies recursively to:
## 16. Response Authority Model
No component receives unlimited security authority.
No component receives unlimited security authority. A **Staff** node never
receives isolate, revoke, or terminate as a power it exercises. Those are
authority-changing operations: the PDP renders them, a PEP enforces them,
and the actuation surface is unowned today.
### 16.1 Authority Dimensions
Authority is constrained by:
Bounds on a future Engine/PEP grant (not on a Staff node):
- tenant;
- compartment;
@ -1352,12 +1374,27 @@ Authority is constrained by:
- approval requirement;
- operating mode.
### 16.2 Example Authority Grant
### 16.2 Example — Staff proposal, then Engine/PEP grant
```yaml
# Staff emits this. It is not an authorization.
effector_request:
originating_observation_id: kg:obs:9876
originating_signal_id: kg:sig:9876
target_system: runtime-pep
action: isolate
authority_boundary: advisory_only
restrictive_direction: request_containment
requires_human_approval: false
stream_completeness: unknown
reason: "Genome-prohibited egress; propose workload quarantine."
# Engine/PEP grant, if and when actuation exists. Not issued to a Staff node.
response_authority:
authority_id: kg:authority:tenant-isolator
subject_id: kg:subject:tenant-immune-node-a
subject_id: kg:pep:runtime-isolator
issued_by: access-engine
decision_ref: kg:decision:123
scope:
tenant_id: tenant-a
@ -1380,12 +1417,6 @@ response_authority:
limits:
maximum_ttl: PT1H
maximum_concurrent_targets: 20
minimum_confidence: 0.85
escalation_required_for:
- terminate
- restore-data
- revoke-human-admin
```
---
@ -1735,6 +1766,9 @@ Every security component publishes:
### 23.3 Containment
Estate KPIs of the **actuation surface** (Engine + PEP), which is unowned
today. kings-guard does not discharge them.
- mean time to constrain;
- mean time to isolate;
- containment success rate;
@ -1832,7 +1866,7 @@ kings-guard/
│ ├── escalation/
│ └── response-schema/
│
├── immune-recovery/
├── immune-recovery/ # Engine / runtime; Staff may request
│ ├── reconciliation/
│ ├── reconstitution/
│ ├── secret-rotation/
@ -1888,30 +1922,33 @@ The architecture should stabilize contracts before selecting implementations.
### 25.2 Effector Contract
Staff emits a **proposal**. Origin linkage is mandatory (WP-0003-T06).
Authority is not widened. The PEP result, when actuation exists, cites the
decision that authorized it — not the Staff node.
```yaml
effector_request:
request_id: uuid
decision_ref: kg:decision:123
originating_observation_id: kg:obs:9876
originating_signal_id: kg:sig:9876
target_system: runtime-pep
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
authority_boundary: advisory_only
restrictive_direction: request_containment
requires_human_approval: false
stream_completeness: unknown
reason: "Genome-prohibited egress observed; propose workload quarantine."
```
```yaml
# PEP / Engine artifact after a decision. Not a kings-guard output.
effector_result:
request_id: uuid
effector_id: kg:effector:runtime-01
originating_observation_id: kg:obs:9876
originating_signal_id: kg:sig:9876
decision_ref: kg:decision:123
effector_id: kg:pep:runtime-01
started_at: 2026-07-23T18:00:03Z
completed_at: 2026-07-23T18:00:04Z
status: successful
@ -2047,12 +2084,13 @@ sequenceDiagram
### 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;
- the local attempt is blocked immediately by a PEP under existing policy;
- Staff publishes posture and a containment *proposal*;
- `access-engine` is the only component that may authorize isolation;
- isolation, rotation and reconstitution are Engine/PEP, and actuation is
unowned today — the hops are the intended loop, not a claim they ran;
- the tenant compartment is the *unit* of containment, not the actor;
- the incident becomes governed tenant memory, which is not a PDP input;
- a shareable attack characteristic may be submitted to platform memory without exporting tenant-private evidence.
---
@ -2218,20 +2256,24 @@ Success condition:
Common tenant incidents can be judged without central manual correlation.
Policy evaluation remains `access-engine`.
### Phase 5 — Bounded Automated Response
### Phase 5 — Bounded Proposal (actuation unowned)
Deliver:
- response authority model;
- reconstructable containment *proposals* (origin observation and signal,
explicit `authority_boundary`);
- restrictive-direction vocabulary (reduce / step-up / request containment);
- no Staff isolate/revoke/terminate grant.
This phase is complete when proposals are well-formed and reconstructable,
**not** when anything is contained. Actuation is an Engine concept held at
zero. No argument may assume selected incidents are contained automatically.
Engine/PEP follow-on (not this repository, not this phase):
- response authority model on the PDP;
- reversible effectors;
- response leases;
- rollback;
- action validation;
- response budgets.
Success condition:
Selected high-confidence incidents can be contained automatically without uncontrolled blast radius.
- response leases, rollback, action validation, response budgets.
### Phase 6 — Recovery and Reconstitution
@ -2279,22 +2321,24 @@ Multiple environments can share useful defensive knowledge without exposing tena
## 32. Initial Repository Deliverables
The initial `kings-guard` repository should contain:
The `kings-guard` repository holds Staff contracts and this architecture
map. It does not hold identity issuance, PDP, or effector-*execution* specs.
Present:
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/`
2. `specs/NetKingdomImmuneArchitecture.md` (this file)
3. `specs/ImmuneContracts.md`
4. `docs/AdjacentSystemBoundary.md`
5. `docs/pilots/QontoAssistantPosturePilot.md`
6. `src/kings_guard/` (observation → posture → advisory proposal)
Not this repository (Engine / Tooling / PEP owners):
- identity and attestation contracts (`key-cape`, `user-engine`);
- decision-record schema (`access-engine`);
- effector *execution* interface (unowned actuation surface);
- secret-custody and recovery-runtime specs.
---
@ -2310,15 +2354,20 @@ Every tenant has an explicit security boundary, policy scope, evidence scope, re
### AD-003 — Security Is Recursive
The same observation, decision, response, recovery and learning pattern applies from workload to federation level.
The same **observe → judge → propose** pattern applies from workload to
federation level. Decide and act sit in Engine/PEP at every level. Recursion
does not create a Staff decision point.
### AD-004 — Evidence Is Distinct From Interpretation
Raw evidence, observations, hypotheses, decisions and actions are separate entities.
### AD-005 — Automated Responses Are Bounded
### AD-005 — Proposals Are Bounded; Actions Are Engine/PEP
Every automated action is limited by scope, authority, duration, evidence threshold and rollback requirements.
Every Staff *proposal* is limited by scope, authority boundary, duration
and reconstructability to its origin. Every automated *action*, when
actuation exists, is limited by a decision record, duration, evidence
threshold and rollback. kings-guard does not perform the action.
### AD-006 — Recovery Is a First-Class Security Capability
@ -2341,7 +2390,9 @@ Implementations may change without changing the stable Kings Guard capability mo
## 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?
2. Which *proposals* may Staff emit at each recursive level, and which PEP
stances already exist? (Autonomy of authorization is a second decision
point and is not on the table.)
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?
@ -2363,7 +2414,9 @@ The Kings Guard architecture is successful when the platform can demonstrate tha
- intended behaviour is explicitly declared;
- tenant boundaries are technically enforceable;
- security observations are attributable and contextualized;
- local disturbances can be contained locally;
- local disturbances can be contained locally by Engine/PEP, with Staff
proposing; actuation is unowned today so this criterion is not claimed
as discharged;
- high-impact actions require proportionally stronger authority;
- compromised components can be reconstituted;
- recovery outcomes are validated;
@ -2384,18 +2437,20 @@ Its defining sequence is:
identity
→ intent
→ observation
→ assessment
→ bounded response
→ judgment (posture)
→ bounded proposal
→ decision (access-engine)
→ actuation (unowned)
→ recovery
→ validation
→ memory
→ memory (not a state plane)
```
Its defining structural principles are:
- identity instead of location-based trust;
- compartmentation instead of a trusted interior;
- local autonomous response with bounded authority;
- local PEP enforcement and Staff proposals, not Staff isolate grants;
- recovery as a peer of prevention and detection;
- evidence separated from interpretation;
- adaptive memory with provenance and decay;

9
workplans/KG-WP-0004-architecture-layer-vocabulary-sweep.md
View file

@ -179,7 +179,7 @@ the same way. Head note still cites v0.6 / KG-IN-0002 — that rewrite is T05.
```task
id: KG-WP-0004-T04
status: todo
status: done
priority: high
state_hub_task_id: "bbb4c1aa-2808-5fde-8f9b-7fb7730f13c7"
```
@ -205,6 +205,13 @@ Done when:
- Phase 5 cannot be read as "kings-guard will automatically contain";
- the effector example is a proposal, reconstructable to its origin.
**Done 2026-09-02:** §9.7 ladder is propose vs execute; safety envelope is
PEP/actuation. §16 grant is no longer issued to a Staff node. §25.2
`effector_request` carries origin observation/signal, `advisory_only`, and
`request_containment`. Phase 5 is bounded proposal; success is
reconstructability, not automatic containment. Fast local loop named as PEP
(qonto-assistant). AD-003/AD-005 and §35/§36 match propose-not-act.
## Task: Prove no Staff decision point; refresh the layer note
```task