Implement KG-WP-0002 posture pilot scaffold
This commit is contained in:
codex
parent
6cee3503da
commit
3c549d9b78
22 changed files with 1418 additions and 25 deletions
77
docs/AdjacentSystemBoundary.md
Normal file
77
docs/AdjacentSystemBoundary.md
Normal file
|
|
@ -0,0 +1,77 @@
|
|||
---
|
||||
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`.
|
||||
119
docs/pilots/QontoAssistantPosturePilot.md
Normal file
119
docs/pilots/QontoAssistantPosturePilot.md
Normal file
|
|
@ -0,0 +1,119 @@
|
|||
---
|
||||
title: Qonto Assistant Posture Pilot
|
||||
version: 0.1.0
|
||||
status: Draft
|
||||
date: 2026-07-23
|
||||
repo: kings-guard
|
||||
classification: Public
|
||||
---
|
||||
|
||||
# Qonto Assistant Posture Pilot
|
||||
|
||||
## 1. Decision
|
||||
|
||||
`qonto-assistant` is selected as the first pilot lane for `KG-WP-0002-T04`.
|
||||
|
||||
This is a deliberate override of the original preference order
|
||||
(`ops-warden` -> `secrets-engine` -> Railiance reconstitution), not because
|
||||
those lanes are unimportant, but because `qonto-assistant` already provides all
|
||||
three prerequisites needed for a meaningful first pilot:
|
||||
|
||||
1. a declared `security_genome`;
|
||||
2. a real audit stream that maps cleanly to `immune_observation`;
|
||||
3. a service-local fast loop that can consume an advisory posture hint.
|
||||
|
||||
That makes it a better first validation target for the contract layer than a
|
||||
more abstract platform lane.
|
||||
|
||||
## 2. Why This Lane
|
||||
|
||||
`qonto-assistant` is:
|
||||
|
||||
- reachable by external harness sessions, not only by cluster-internal callers;
|
||||
- the sole holder of a real company bank credential;
|
||||
- already instrumented with a deny-escalation local loop;
|
||||
- already documented as a future `kings-guard` consumer in
|
||||
`qonto-assistant/docs/SecurityPractice.md`.
|
||||
|
||||
This gives the pilot real risk, real evidence, and a bounded local response
|
||||
path without granting `kings-guard` any new secret or authorization authority.
|
||||
|
||||
## 3. Pilot Question
|
||||
|
||||
Can `kings-guard` consume a normalized observation derived from
|
||||
`qonto-assistant`'s existing audit stream, compare it against a declared
|
||||
security genome, and emit a bounded **posture hint** that the service can use
|
||||
for its own local fast loop?
|
||||
|
||||
## 4. Request/Response Flow
|
||||
|
||||
```text
|
||||
client request
|
||||
-> qonto-assistant policy kernel denies suspicious action
|
||||
-> qonto-assistant emits audit event
|
||||
-> kings-guard normalizes event into immune_observation
|
||||
-> kings-guard evaluates posture against qonto security_genome
|
||||
-> kings-guard emits posture_hint signal
|
||||
-> qonto-assistant chooses whether to activate local deny-escalation lockout
|
||||
-> state-hub receives metadata-only evidence
|
||||
```
|
||||
|
||||
## 5. Input Mapping
|
||||
|
||||
| qonto-assistant field | Kings Guard field | Notes |
|
||||
| --- | --- | --- |
|
||||
| `request_id` | `observation_id` | Stable correlation id |
|
||||
| `timestamp` | `timestamp` | Direct mapping |
|
||||
| `actor` | `actor_id` | Current pilot still tolerates self-asserted identity binding |
|
||||
| `tenant_id` | `tenant_id` | Direct mapping |
|
||||
| `capability` | `resource_scope` | Fine-grained route/capability name such as `org_summary` |
|
||||
| derived constant | `capability` | Coarse scope: `finance.qonto.read` |
|
||||
| `protocol` | `protocol` | `rest` or `mcp` |
|
||||
| `decision` | `decision` | `allow` / `deny` |
|
||||
| `deny_reason` | `deny_reason` | Pilot currently exercises `credential_exfil` |
|
||||
| derived constant | `identity_binding` | `self_asserted` until key-cape integration lands |
|
||||
| derived constant | `egress_destination` | `qonto-thirdparty-api` for this pilot |
|
||||
|
||||
## 6. Output Shape
|
||||
|
||||
The pilot emits one `immune_signal` of kind `posture_hint` when posture is
|
||||
above `healthy`.
|
||||
|
||||
For the initial `credential_exfil` scenario:
|
||||
|
||||
- posture: `inflamed`
|
||||
- primary finding: `credential_exfil_probe`
|
||||
- bounded local action hint: `lock_actor_temporarily`
|
||||
- evidence sink hint: `state-hub` metadata-only incident recording
|
||||
|
||||
## 7. Authority Boundary
|
||||
|
||||
`kings-guard` does **not**:
|
||||
|
||||
- authorize or deny the client request;
|
||||
- fetch or hold the Qonto credential;
|
||||
- change `qonto-assistant` policy rules directly;
|
||||
- mutate OpenBao, `flex-auth`, or `key-cape`.
|
||||
|
||||
`qonto-assistant` keeps those responsibilities. `kings-guard` only emits an
|
||||
advisory posture hint and metadata-only evidence guidance.
|
||||
|
||||
## 8. Rollback / Safety
|
||||
|
||||
The pilot is easy to disable:
|
||||
|
||||
- if `kings-guard` is unavailable, `qonto-assistant` continues with its current
|
||||
local policy and deny-escalation behavior;
|
||||
- if the signal consumer is disabled, audit events still exist and no secret
|
||||
or authorization authority has moved;
|
||||
- no secret values are copied into `kings-guard` or `state-hub`.
|
||||
|
||||
## 9. Follow-On Lanes
|
||||
|
||||
Choosing `qonto-assistant` first does **not** reject the original preference
|
||||
order. It sequences them:
|
||||
|
||||
1. `qonto-assistant` proves the contract layer with a real consumer.
|
||||
2. `ops-warden` sign-request posture hinting is the next likely platform lane.
|
||||
3. `secrets-engine` delivery posture hinting follows once the contract is
|
||||
stable enough to reuse.
|
||||
Loading…
Add table
Add a link
Reference in a new issue