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
100 lines
6.2 KiB
Markdown
100 lines
6.2 KiB
Markdown
---
|
|
title: Kings Guard Adjacent-System Boundary
|
|
version: 0.1.0
|
|
status: Draft
|
|
date: 2026-07-23
|
|
repo: kings-guard
|
|
classification: Public
|
|
---
|
|
|
|
# Kings Guard Adjacent-System Boundary
|
|
|
|
## 1. Purpose
|
|
|
|
This document records how `kings-guard` interacts with adjacent security and
|
|
platform systems in the current NetKingdom stack.
|
|
|
|
It exists to prevent overlap drift: `kings-guard` consumes evidence, evaluates
|
|
posture, and emits bounded signals. It does not absorb the primary authority of
|
|
identity, authorization, secret custody, or operations systems.
|
|
|
|
## 2. Cross-System Rules
|
|
|
|
The following rules apply to every integration below:
|
|
|
|
1. `kings-guard` consumes **non-secret evidence** or references to secret
|
|
operations, never raw secret values.
|
|
2. `kings-guard` contributes **risk and posture context**, never final
|
|
authorization or identity decisions.
|
|
3. `kings-guard` emits **bounded signals and effector requests** that remain
|
|
advisory unless the owning system already delegates a narrow action lane.
|
|
4. `kings-guard` must preserve **tenant isolation**: any retained evidence or
|
|
memory must stay bounded by declared confidentiality rules.
|
|
5. `kings-guard` is a **Staff-layer** repository and is bound by §5 of the
|
|
NetKingdom Security Layer Model v0.6: it never holds a direct client for a
|
|
Tooling-layer system. Evidence from Tooling (OpenBao, key-cape components)
|
|
is consumed **through the owning engine**. Where no engine surface exists,
|
|
the lane stays fixture-driven and the gap is declared in `INTENT.md`.
|
|
6. `kings-guard` never renders or caches an authorization decision.
|
|
`access-engine` is the estate's only decision point (layer model §6).
|
|
|
|
## 3. System-by-System Boundary
|
|
|
|
| Adjacent system | Primary authority | Evidence consumed by `kings-guard` | Signals returned by `kings-guard` | Non-goals |
|
|
| --- | --- | --- | --- | --- |
|
|
| `key-cape` **(Tooling — reach via `user-engine` / `access-engine`)** | verified identity, login, MFA, assurance claims | token assurance level, attestation outcomes, claim provenance, authentication anomalies | posture hints about assurance drift or identity inconsistency | minting tokens, login flow, MFA lifecycle |
|
|
| `access-engine` (currently `flex-auth`) | resource authorization policy, decision logs, protected-system registry | live allow/deny decisions, decision explanations, policy version, decision-rate anomalies | risk context or posture hints that a protected system may choose to include in an auth check | becoming the PDP, registering resources, final allow/deny |
|
|
| `secrets-engine` | approved secret workflow and scoped capability delivery | metadata-only records of reads, leases, deliveries, rotations, revocations | posture hints about abnormal secret-use patterns or repeated denied delivery attempts | holding secret values, issuing leases, bypassing approval |
|
|
| OpenBao **(Tooling — reach via `secrets-engine`)** | runtime secret custody, secret engines, dynamic credentials | engine/mount metadata, lease/revocation evidence, platform-secret posture | posture hints for secret-authority consumers or operators | root-token custody, secret-engine configuration ownership |
|
|
| `ops-warden` | operational SSH certificate issuance and routing guidance | signing attempts, TTL/principal anomalies, access-routing misuse evidence | sign-request posture hints, actor-scrutiny hints, metadata-only evidence requests | issuing certificates, routing non-SSH credentials, host trust config |
|
|
| Railiance runtime layers **(reach via the owning engine)** | provisioning, deployment, isolation, workload lifecycle | deployment provenance, runtime health, workload/network/storage events, recovery outcomes | bounded requests for isolate, rebuild, or validate, always within the runtime's own authority | becoming the deployment repo or cluster operator |
|
|
| Governed domain assistants (example: `qonto-assistant`) | service-local business logic, service-local fast loops, customer/domain-facing policy enforcement points | audit events, policy denies, local safety loop outcomes, service-owned genome records | service-local posture hints and metadata-only evidence requests | replacing local policy kernels or business logic |
|
|
| `state-hub` | live coordination state and work-record indexing | repo/workplan/task/progress metadata, incident references | non-secret progress events, posture evidence, incident notes | becoming canon, storing secret payloads, driving irreversible response |
|
|
|
|
## 4. Governed Domain Assistants
|
|
|
|
`qonto-assistant` introduces an important pattern that deserves to be named
|
|
explicitly in the boundary model:
|
|
|
|
- it is a workload protected by the platform,
|
|
- it is also a policy enforcement point in its own right,
|
|
- and it already emits an audit stream and operates a local fast loop.
|
|
|
|
That class of system is not identical to a generic workload behind
|
|
`access-engine`, and it is not infrastructure either.
|
|
|
|
`kings-guard`'s relationship to this class is:
|
|
|
|
- consume its service-local audit stream as `immune_observation`;
|
|
- consume its declared healthy intent as `security_genome`;
|
|
- emit posture hints that the service may adopt through its own local control
|
|
logic;
|
|
- never take over its business logic, credentials, or final access policy.
|
|
|
|
## 5. Current First-Class Integrations
|
|
|
|
The first executable `kings-guard` slice targets one concrete adjacent-system
|
|
pattern:
|
|
|
|
- **Chosen pilot:** governed domain assistant (`qonto-assistant`)
|
|
- **Why first:** already has a real genome record, audit stream, and fast local
|
|
loop; lets `kings-guard` validate contracts without waiting for new platform
|
|
control paths
|
|
|
|
See `docs/pilots/QontoAssistantPosturePilot.md`.
|
|
|
|
The pilot lane is chosen partly *because* it is layer-clean: `qonto-assistant`
|
|
publishes its own audit stream and genome record, so kings-guard needs no
|
|
Tooling client to run it. The `key-cape`, OpenBao and runtime rows above stay
|
|
fixture-driven until the engine surfaces named in `INTENT.md` §*Declared engine
|
|
gaps* exist.
|
|
|
|
## 6. Layer conformance
|
|
|
|
Mechanically checkable, per layer model §10:
|
|
|
|
- `pyproject.toml` declares **zero runtime dependencies** — no database driver,
|
|
no OpenBao client, no Kubernetes client;
|
|
- every `EffectorRequest` carries an explicit `authority_boundary`, and the
|
|
values in use are `advisory_only` and `metadata_only`;
|
|
- no module exposes an authorization decision surface.
|