---
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`