tegwick
9daea96c43
Classify evidence as load-bearing or attributive, draft the emission-cadence declaration for Taxonomy, treat silence as a stream finding, keep completeness separate from record richness, forbid immune memory as a state plane, and make containment proposals reconstructable to their origin. Observe real qonto-assistant audit events; deny-class completeness stays unknown until the source publishes a heartbeat. Assistant: grok Assistant-Session: 01a05ef1-9e5a-70f2-b0ff-0b05d6b38ae9
112 lines
7 KiB
Markdown
112 lines
7 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).
|
|
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.
|