kings-guard/docs/AdjacentSystemBoundary.md

title	version	status	date	repo	classification
Kings Guard Adjacent-System Boundary	0.1.0	Draft	2026-07-23	kings-guard	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.