tegwick
3d6025ae51
Answers gate-house intake KG-IN-0001 / GH-DEC-2026-001 against the NetKingdom Security Layer Model v0.1. Assent to all three points, recorded as KG-DEC-2026-001: - kings-guard declares layer Staff in INTENT.md; - "control plane" released to the Engine layer across INTENT, SCOPE, README, AGENTS and the adjacent-system boundary; - the posture asymmetry adopted as a repo invariant — already satisfied, every EffectorRequest carries an explicit authority_boundary. Boundary corrections: key-cape and OpenBao are Tooling, so their evidence is routed through user-engine/access-engine and secrets-engine rather than read directly. Finding on the invited challenge to §5: do not weaken the binding rule, but §4 catalogs kings-guard as owning containment while no engine exposes a containment surface — the charter is currently undischargeable. Two rulings requested of gate-house. Three engine gaps declared in INTENT.md. Residual handed off as KG-IN-0002 (vocabulary sweep of the architecture spec). 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
2.8 KiB
2.8 KiB
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.1.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-engineis 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, anddocs/pilots/QontoAssistantPosturePilot.md. - A minimal Python reference scaffold exists under
src/kings_guard/with fixture-driven tests undertests/. - 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/