kings-guard/intake/2026-07-23-qonto-assistant-pilot-candidate.md

title	origin	origin_ref	lane	status	outcome	state_hub_intake_id
qonto-assistant as a pilot-lane candidate for KG-WP-0002-T04	qonto-assistant docs/SecurityPractice.md	QONTO-WP-0004	green	closed	absorbed	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).

Resolution

Closed on 2026-07-23 as absorbed by KG-WP-0002.

The intake's requested work is now implemented in this repo:

• specs/ImmuneContracts.md and src/kings_guard/contracts.py provide the first canonical contract layer that qonto-assistant can target.
• docs/AdjacentSystemBoundary.md explicitly names governed domain assistants such as qonto-assistant in the adjacent-system boundary.
• docs/pilots/QontoAssistantPosturePilot.md selects qonto-assistant as the first pilot lane and defines the bounded request/response flow.
• src/kings_guard/adapters/qonto_assistant.py, src/kings_guard/posture.py, and tests/ implement and verify the initial normalized observation -> posture -> advisory signal path.

No separate follow-on work record is needed for this intake itself. Future work should start from a new intake or workplan for the next lane beyond KG-WP-0002.

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