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 <noreply@anthropic.com>

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`