77 lines
4.9 KiB
Markdown
77 lines
4.9 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.
|
|
|
|
## 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`.
|