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
120 lines
4.4 KiB
Markdown
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.
|