From a2ee0e2d89ba331b65867fdbf2df188acabd789a Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 23 Jul 2026 23:01:17 +0200 Subject: [PATCH] Intake: qonto-assistant as a pilot-lane candidate for KG-WP-0002-T04 qonto-assistant is the first fleet service that must be both internet-reachable and hold a real bank credential -- a concrete, higher-stakes candidate for the first posture pilot than the currently-listed order (ops-warden/secrets-engine/Railiance reconstitution). It already ships an audit stream shaped like an Immune Observation, a Security Genome record, and a working Fast Local Loop (deny-escalation lockout), all without any kings-guard component existing -- registered as intake 019f90c8 against KG-WP-0002 so T04's pilot-lane selection can weigh it. Co-Authored-By: Claude Sonnet 5 --- ...6-07-23-qonto-assistant-pilot-candidate.md | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 intake/2026-07-23-qonto-assistant-pilot-candidate.md diff --git a/intake/2026-07-23-qonto-assistant-pilot-candidate.md b/intake/2026-07-23-qonto-assistant-pilot-candidate.md new file mode 100644 index 0000000..8d0921e --- /dev/null +++ b/intake/2026-07-23-qonto-assistant-pilot-candidate.md @@ -0,0 +1,96 @@ +--- +title: "qonto-assistant as a pilot-lane candidate for KG-WP-0002-T04" +origin: "qonto-assistant docs/SecurityPractice.md" +origin_ref: "QONTO-WP-0004" +lane: green +status: open +state_hub_intake_id: "019f90c8-2d56-7897-858c-03b463791797" +--- + +# qonto-assistant as a pilot-lane candidate + +`KG-WP-0002-T04` ("Choose and specify the first pilot lane") currently lists +a preferred order of `ops-warden` sign-request posture hinting, +`secrets-engine` exec-delivery posture hinting, and Railiance workload +reconstitution signal generation. This intake asks that a fourth candidate — +`qonto-assistant` — be weighed alongside those, because it is a live, +concrete consumer with a real deadline (deployment to `railiance01`), not a +hypothetical one. + +## Why this is a strong pilot candidate + +`qonto-assistant` (`net-kingdom` domain `infotech`, +`QONTO-WP-0004-security-hardening-and-scale-to-zero.md`) is the first +fleet service that is both: + +- reachable by clients outside the cluster (laptop-based agent harness + sessions), and +- the sole holder of a real company bank credential. + +That combination makes it a higher-value pilot than a purely internal +signal-generation lane: a posture pilot here would be exercised against +genuine internet-facing risk, not synthetic test traffic. + +## What already exists, ready to be a sensor/evidence source + +No `kings-guard` component needs to exist for this list to be true today — +these are already-shipped properties of `qonto-assistant` that a pilot could +consume with no rework on its side: + +1. **An audit stream shaped like an Immune Observation.** Every capability + call emits `{actor, tenant_id, capability, decision, deny_reason, + latency_ms, qonto_http_status, policy_version, protocol, request_id, + timestamp}` — see `qonto-assistant/src/qonto_assistant/audit.py` and + `tests/test_audit_parity.py` (proves REST and MCP emit schema-identical + events). This maps closely to + `NetKingdomImmuneArchitecture.md` §9.4's `immune_observation` contract + already. +2. **A Security Genome record.** `qonto-assistant/specs/security-genome.yaml` + follows §9.1's schema today — declared capabilities, expected egress, + data classification, recovery expectations, and explicit tolerances for + known-temporary gaps. +3. **A real Fast Local Loop already running.** `DenyEscalationTracker` + (`qonto-assistant/src/qonto_assistant/security_watch.py`) locks out an + actor after repeated `arg_constraint`/`credential_exfil` denies within a + window — a genuine §14.1 fast local loop response, implemented without + waiting for `kings-guard` to exist. A pilot could validate the *shape* of + posture escalation against a real, already-instrumented control rather + than inventing one from scratch. + +## What we need from `kings-guard`, in priority order + +1. **The Immune Observation contract, stabilized enough to target.** + `qonto-assistant`'s audit event shape was designed by inference from + `NetKingdomImmuneArchitecture.md` §9.4, not against a ratified contract. + `KG-WP-0002-T01`'s canonical contract work is the direct unblock — once + it exists, we want to confirm (or correct) the mapping rather than guess + again. +2. **A stated adjacent-system boundary for `qonto-assistant`-like domain + assistants**, i.e. `KG-WP-0002-T02` extended to name this class of + service explicitly (a governed domain assistant that is itself a policy + enforcement point, not just a workload behind one) — the boundary + document currently names `key-cape`/`flex-auth`/`secrets-engine`/ + `ops-warden`/Railiance, but not this pattern. +3. **A concrete decision on whether `qonto-assistant` becomes the (or a) + first pilot lane for `KG-WP-0002-T04`.** If not selected as the pilot, + we still want the resulting contracts (item 1) as soon as they exist — + this intake is not asking to block on being chosen. +4. **Nothing secret, identity, or final-authorization related** — consistent + with `kings-guard`'s own SCOPE.md, this intake only asks for + posture/signal contract work, not for `kings-guard` to gain any new + authority over `qonto-assistant`'s credentials or access decisions. + +## What this is not asking for + +- Not asking `kings-guard` to take over authorization (`flex-auth` remains + that owner) or secret custody (`OpenBao`/`ops-warden` remain that owner). +- Not asking for automated response authority yet — observation/posture + contract stabilization is the ask, not bounded-response implementation + (that is `KG-WP-0002-T04`'s own scope to define, if this lane is chosen). + +## References + +- `qonto-assistant/docs/SecurityPractice.md` +- `qonto-assistant/specs/security-genome.yaml` +- `qonto-assistant/workplans/QONTO-WP-0004-security-hardening-and-scale-to-zero.md` +- `kings-guard/workplans/KG-WP-0002-canonical-immune-contracts-and-posture-pilot.md`