kings-guard/SCOPE.md

SCOPE

Lightweight boundary for agents and contributors.

---

Layer

Staff — interactive, non-deterministic; adaptive defence, observation, and judgment. Kings-guard proposes containment but does not own or perform it. 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.7.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 without replacing any system's primary authority, and it actuates nothing: containment is rendered by an Engine and enforced by a PEP (statute §9.2).

The one-line test for anything proposed here: does it judge and propose, or does it decide and act? The first is in scope. The second is another layer's.

---

In Scope

• Canonical terminology and contracts for security genome, phenotype, observation, signal, effector, tolerance, inflammation, and immune memory.
• Evidence classification — marking each consumed stream load-bearing or attributive (§9.6), since the obligations differ.
• The emission-cadence declaration draft (§17). kings-guard is its only consumer and drafts it; Taxonomy owns it. Includes the reconciliation or heartbeat form required for low-volume load-bearing classes, where rate monitoring cannot work.
• Stream-completeness judgment — treating silence as a signal, and carrying the resulting doubt in the posture output rather than reporting confidence in a stream that may be incomplete.
• 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, taken through the owning engine: access-engine (the decision point, currently named flex-auth), secrets-engine, user-engine, audit-core, and the Railiance runtime layers. key-cape and OpenBao are Tooling and are never contacted directly.
• Non-secret evidence, workplans, and repo-operational metadata.

---

Out of Scope

• Actuation of any kind. Reduce authority, require step-up, isolate a workload — these are authority-changing operations rendered by an Engine and enforced by a PEP. kings-guard proposes them and never performs them, even when no engine surface exists to receive the proposal.
• Holding a standing credential (§3.4 rule 1).
• Becoming a state plane for another layer, immune memory included (§3.4 rule 3). Immune memory informs kings-guard's judgment and may be published as evidence; nothing may depend on it at runtime.
• 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.
• Claiming that an event's absence from an archive proves it did not happen, or that a quiet stream is a healthy one (§9.6).
• 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.
• Evidence class, stream-completeness evaluation, origin-linked proposals, and the emission-cadence Taxonomy draft landed in KG-WP-0003.
• layer.yaml, scripts/check_layer_conformance.py and tests/test_layer_conformance.py make the no-Tooling-client claim and the no-standing-credential claim executable; the companion cites them estate-wide as the reference for a repository with no Tooling contacts at all.
• Live observation of qonto-assistant uses the source's own AuditLogger emit path. The hand-built fixture is retained as a regression case. The local contract proof now consumes the source-owned cadence declaration and checks heartbeat, sequence, and reconciliation evidence for the load-bearing deny class. Validation against a deployed stream remains operational work.
• Engine secret-use snapshots have a pure, scoped metadata adapter with explicit unknown completeness and snapshot freshness findings. Event-based secret-abuse posture awaits source provenance and operational evidence (KG-IN-0005). See docs/SecretUseSnapshotAdmission.md.
• Cadence fixtures consume InfoTechCanon standard/emission-cadence 0.1; the local handover draft is historical and NetKingdom profile adoption remains with its owner.
• specs/NetKingdomImmuneArchitecture.md was swept under KG-WP-0004 onto Staff / Engine / Tooling (v0.7). It is an estate map; this repository implements the Staff slice only. Containment is proposed, not performed. Immune memory is not a state plane.

---

Getting Oriented

• Start with: INTENT.md
• Architecture (estate map, layer-swept): specs/NetKingdomImmuneArchitecture.md
• Exploration notes: history/InitialExploration.md
• Agent instructions: AGENTS.md
• Workplans: workplans/