kings-guard/docs/pilots/QontoAssistantPosturePilot.md
tegwick 9daea96c43 Finish KG-WP-0003: stream completeness and live qonto observation
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
2026-09-02 00:11:57 +02:00

120 lines
4.4 KiB
Markdown

---
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 |
| genome `evidence_sources` | `evidence_class` / `event_class` | Copied from the source declaration. `audit.deny` is load-bearing; `audit.allow` is attributive. Not inferred from `decision`. |
## 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.