202 lines
7.4 KiB
Markdown
202 lines
7.4 KiB
Markdown
# INTENT
|
|
|
|
> This file captures **why this repository exists**, the **direction it is
|
|
> moving toward**, and the **kind of system it is meant to become**.
|
|
> It is intentionally **aspirational and stable**, not a description of
|
|
> current implementation.
|
|
|
|
---
|
|
|
|
## One-liner
|
|
|
|
**Recursive adaptive security control plane for complex cloud environments: it
|
|
declares healthy intent, detects harmful deviation, contains damage locally,
|
|
restores known-good operation, and retains governed defensive memory.**
|
|
|
|
---
|
|
|
|
## Why This Exists
|
|
|
|
Modern cloud environments are too dynamic to protect through identity, policy,
|
|
and perimeter rules alone.
|
|
|
|
Even when authentication, authorization, and secret custody are well designed,
|
|
the environment still changes continuously:
|
|
|
|
- workloads are rebuilt and redeployed;
|
|
- dependencies shift;
|
|
- operators, agents, and automations act with real authority;
|
|
- tenants share substrates while requiring strong isolation;
|
|
- legitimate identities can become compromised;
|
|
- harmful behavior can emerge from software that still looks formally allowed.
|
|
|
|
Security therefore needs a layer that does more than authenticate and allow.
|
|
It must continuously compare **declared healthy operation** against **observed
|
|
behavior**, decide whether the current state is acceptable, and coordinate
|
|
bounded response when it is not.
|
|
|
|
This repository exists to provide that adaptive layer.
|
|
|
|
---
|
|
|
|
## The Mission
|
|
|
|
> *Where we are going.*
|
|
|
|
Kings Guard aims to become a **recursive adaptive security system** for
|
|
multi-tenant, multi-operator, and agent-active environments.
|
|
|
|
It should make security an ongoing control loop:
|
|
|
|
```text
|
|
declare healthy intent
|
|
-> establish and attest identity
|
|
-> observe actual behavior
|
|
-> compare behavior with policy and intended scope
|
|
-> assess risk and confidence
|
|
-> respond within bounded authority
|
|
-> restore known-good operation
|
|
-> validate the outcome
|
|
-> retain governed security memory
|
|
```
|
|
|
|
The mature system should:
|
|
|
|
- model intended healthy operation explicitly;
|
|
- evaluate trust as temporary, scoped, and continuously reassessed;
|
|
- detect and contain disturbances near their origin;
|
|
- coordinate local and global defensive signals without collapsing tenant
|
|
boundaries;
|
|
- drive reconstitution and recovery, not only alerting;
|
|
- learn from incidents without normalizing compromise or leaking sensitive
|
|
tenant data.
|
|
|
|
---
|
|
|
|
## Responsibility Boundary
|
|
|
|
Kings Guard owns the **adaptive security assessment and response layer**.
|
|
|
|
### Kings Guard owns
|
|
|
|
- the model of healthy intent, tolerated variation, and harmful deviation;
|
|
- security phenotype assessment from observed state and behavior;
|
|
- normalized immune observations and signal contracts;
|
|
- posture assessment across compartments, subjects, and resources;
|
|
- bounded response policy for containment, inflammation, quarantine, and
|
|
reconstitution;
|
|
- recovery validation and governed immune memory;
|
|
- coordination between local autonomous defense and broader federated defense.
|
|
|
|
### Kings Guard does not own
|
|
|
|
- primary human, workload, or device identity issuance;
|
|
- login, MFA, token minting, or directory lifecycle;
|
|
- resource authorization policy administration;
|
|
- long-lived secret custody, lease issuance, or secret value delivery;
|
|
- infrastructure provisioning, workload deployment, or platform operations;
|
|
- general work coordination, task management, or live project state.
|
|
|
|
### System boundary
|
|
|
|
| Concern | Primary owner | Kings Guard responsibility |
|
|
| --- | --- | --- |
|
|
| Identity, authentication, MFA, and verified claims | `key-cape` and related IAM systems | Consume identity and attestation as security inputs; do not replace identity. |
|
|
| Resource authorization and decision logs | `flex-auth` | Contribute posture and risk context; do not become the authorization control plane. |
|
|
| Secret custody, delivery, leases, and rotation | `railiance-platform` and `secrets-engine` | Consume secret-access evidence and drive defensive posture; do not hold raw secret authority. |
|
|
| Operational SSH certificate issuance and access routing | `ops-warden` | Supply posture, evidence, or future response hooks; do not become the SSH issuing lane. |
|
|
| Infrastructure, runtime, and platform execution | Railiance repos and workload operators | Signal constraints, isolation, and reconstitution needs; do not own deployment mechanics. |
|
|
| Workstream and task coordination | `state-hub` | Emit non-secret evidence and integration events where appropriate; do not become a work tracker. |
|
|
|
|
---
|
|
|
|
## Design Principles
|
|
|
|
### 1. Intent before anomaly
|
|
|
|
Security should first ask whether behavior is compatible with declared healthy
|
|
operation, not merely whether it is statistically unusual.
|
|
|
|
### 2. Trust is temporary
|
|
|
|
Trust is not a permanent property of an identity, network location, or workload.
|
|
It is a time-bound judgment derived from identity, provenance, integrity,
|
|
context, and observed behavior.
|
|
|
|
### 3. Local containment first
|
|
|
|
Defensive action should happen as close as possible to the disturbed
|
|
compartment, with wider coordination only when impact crosses boundaries.
|
|
|
|
### 4. Bounded response over uncontrolled automation
|
|
|
|
Automated response must be explicitly scoped, reversible where possible, and
|
|
governed so defense does not become its own source of harm.
|
|
|
|
### 5. Recovery is part of security
|
|
|
|
Detection without reconstitution is incomplete. The system should restore
|
|
known-good operation and verify that restoration succeeded.
|
|
|
|
### 6. Memory must be governed
|
|
|
|
The system should learn from incidents, but memory must preserve tenant
|
|
confidentiality, prevent evidence poisoning, and avoid turning compromise into
|
|
"normal" behavior.
|
|
|
|
### 7. Replaceable implementations, stable contracts
|
|
|
|
Sensors, policy engines, response effectors, and deployment substrates may
|
|
change. Kings Guard should depend on stable capability contracts rather than one
|
|
mandatory product stack.
|
|
|
|
---
|
|
|
|
## What This Is
|
|
|
|
Kings Guard is:
|
|
|
|
- an adaptive security control-plane concept and implementation home;
|
|
- a contract layer for healthy intent, observations, signals, posture, and
|
|
effectors;
|
|
- a coordination system for detection, containment, recovery, and memory;
|
|
- a reference architecture for recursive, compartment-aware cloud defense.
|
|
|
|
---
|
|
|
|
## What This Is Not
|
|
|
|
Kings Guard is not:
|
|
|
|
- an identity provider;
|
|
- an authorization registry;
|
|
- a secret store;
|
|
- a SIEM-only alerting surface;
|
|
- a generic deployment/orchestration repository;
|
|
- a justification to weaken tenant isolation in the name of global defense.
|
|
|
|
---
|
|
|
|
## Direction of Evolution
|
|
|
|
The repository should evolve through clear layers:
|
|
|
|
1. **Canonical model:** define the stable vocabulary for security genome,
|
|
phenotype, observation, signal, effector, tolerance, inflammation, and
|
|
immune memory.
|
|
2. **Assessment loop:** provide a minimal service that ingests observations,
|
|
evaluates posture against declared intent, and produces typed signals.
|
|
3. **Bounded response:** integrate with selected effectors for isolation,
|
|
throttling, revocation, or reconstitution under explicit policy.
|
|
4. **Recovery and validation:** prove that known-good restoration can be
|
|
coordinated and verified, not merely requested.
|
|
5. **Federated memory:** retain reusable defensive knowledge without exposing
|
|
tenant-confidential operational detail.
|
|
|
|
---
|
|
|
|
## Guiding Question
|
|
|
|
> **How can a cloud environment continuously distinguish healthy from harmful
|
|
> behavior, contain damage near its origin, and learn from incidents without
|
|
> centralizing too much trust or harming legitimate operation?**
|