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