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.

3. System-by-System Boundary

Adjacent system	Primary authority	Evidence consumed by kings-guard	Signals returned by kings-guard	Non-goals
key-cape	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
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
railiance-platform / OpenBao	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	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 flex-auth, and it is not an infrastructure control plane 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.