tegwick
72c2a42d67
The standard moved v0.4 -> v0.6. All four findings from our v0.4 review were adopted in v0.5, and v0.6 went further on two of them. §11 now requires a machine-readable declaration — prose cannot distinguish a declaration from a transcribed review. We had none. Added layer.yaml (form adapted from ops-warden's reference implementation), scripts/check_layer_conformance.py, and tests/test_layer_conformance.py. The check makes our central claim mechanical rather than asserted: no direct Tooling client in src/. The test exercises the negative case on a synthetic tree, so it fails if the checker goes blind. pyyaml is added as a DEV dependency only — `dependencies = []` is load-bearing for the §5 claim and stays empty. Adopted from v0.6: - containment is no longer ours (§9.2). Actuation is an Engine concept, unowned and held at zero; kings-guard proposes containment and never performs it. The register row is now a dependency, not our gap. - observation is scoped to Staff-reachable sources, with identity and secret observation pending — our finding 1, adopted near-verbatim. - access-engine DECLINED the authentication-evidence gap; owner is now the identity layer plus audit-core, reproposed and unassented. - §11 blocked-clean recorded, with the rule that it must not rank below conforming — our finding 2. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UEtvmYUBP2fDtirJGWn5MW Assistant: claude-code Assistant-Model: opus Assistant-Process: 4014379@bnt-lap001 Assistant-Session: 4af9e20f-1768-4afc-951b-b507784e382b
84 lines
2.8 KiB
Markdown
84 lines
2.8 KiB
Markdown
# SCOPE
|
|
|
|
> Lightweight boundary for agents and contributors.
|
|
|
|
---
|
|
|
|
## Layer
|
|
|
|
**Staff** — interactive, non-deterministic; adaptive defence, observation,
|
|
containment. Binding rule: kings-guard never touches Tooling directly; it acts
|
|
only through Engine APIs. See `INTENT.md` and
|
|
`net-kingdom/canon/standards/security-layer-model_v0.6.md`.
|
|
|
|
---
|
|
|
|
## One-liner
|
|
|
|
Adaptive security assessment and bounded-response layer for multi-tenant cloud
|
|
platforms.
|
|
|
|
---
|
|
|
|
## Core Idea
|
|
|
|
`kings-guard` turns declared healthy intent plus observed runtime behavior into
|
|
posture judgments, typed security signals, and bounded response requests. It
|
|
consumes evidence from identity, authorization, secret, and runtime systems
|
|
without replacing those systems' primary authority.
|
|
|
|
---
|
|
|
|
## In Scope
|
|
|
|
- Canonical terminology and contracts for security genome, phenotype,
|
|
observation, signal, effector, tolerance, inflammation, and immune memory.
|
|
- Reference architecture and boundary documents for adaptive defense in
|
|
multi-tenant and agent-active environments.
|
|
- Minimal posture-evaluation loop design: ingest observations, compare against
|
|
intended healthy state, and emit typed posture/signal results.
|
|
- Integration seams to adjacent security systems such as `key-cape`,
|
|
`flex-auth`, `secrets-engine`, `ops-warden`, and the Railiance runtime
|
|
layers.
|
|
- Non-secret evidence, workplans, and repo-operational metadata.
|
|
|
|
---
|
|
|
|
## Out of Scope
|
|
|
|
- Identity issuance, login, MFA, or token minting.
|
|
- Any direct client for a Tooling-layer system (OpenBao, key-cape components,
|
|
a database, a cluster) — every such need routes through the owning engine.
|
|
- Rendering or caching an authorization decision; `access-engine` is the
|
|
estate's only decision point.
|
|
- "Control plane" as a self-description — that vocabulary belongs to the
|
|
Engine layer.
|
|
- Authorization policy administration or final resource allow/deny decisions.
|
|
- Secret custody, lease issuance, or raw secret-value delivery.
|
|
- Infrastructure provisioning, workload deployment, or cluster/platform
|
|
operations.
|
|
- Generic SIEM ownership, ticket tracking, or live work coordination beyond
|
|
this repo's own workplans.
|
|
|
|
---
|
|
|
|
## Current State
|
|
|
|
- Canon now includes `specs/ImmuneContracts.md`,
|
|
`docs/AdjacentSystemBoundary.md`, and
|
|
`docs/pilots/QontoAssistantPosturePilot.md`.
|
|
- A minimal Python reference scaffold exists under `src/kings_guard/` with
|
|
fixture-driven tests under `tests/`.
|
|
- The implementation currently evaluates normalized observations and emits
|
|
posture/signal results for one bounded pilot lane; it is not an enforcement
|
|
service and will not become one.
|
|
|
|
---
|
|
|
|
## Getting Oriented
|
|
|
|
- Start with: `INTENT.md`
|
|
- Architecture draft: `specs/NetKingdomImmuneArchitecture.md`
|
|
- Exploration notes: `history/InitialExploration.md`
|
|
- Agent instructions: `AGENTS.md`
|
|
- Workplans: `workplans/`
|