kings-guard/docs/AdjacentSystemBoundary.md

---
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).
7. Every containment **proposal** carries the originating observation and
   signal identity, the stream-completeness state, and a restrictive
   direction. It does not carry credentials, secret values, or a direct
   actuation instruction. The receiving Engine (today: `access-engine` as
   decision point; actuation still unowned) MUST retain those origin
   references on the eventual decision record so a containment action is
   reconstructable as a decision, not a side channel (statute §9.2;
   `gate-house/docs/contracts/posture-findings-return.md`). Origin linkage
   does not widen authority.

## 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`;
- every `EffectorRequest` also carries `originating_observation_id` and
  `originating_signal_id` so a later decision record can name what was
  proposed and against which observation;
- no module exposes an authorization decision surface.