coulomb/key-cape
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
key-cape/docs/qonto-runtime-identity-contract.md

2.1 KiB
Raw Permalink Blame History

Qonto Runtime Identity Contract

Date: 2026-07-26 Status: Provisioning-ready; tenant canon decision and first issue remain open

Stable Names

  • runtime package/principal: rapp-qonto
  • service account: rapp-qonto
  • non-interactive caller client: rapp-qonto-client
  • OpenBao runtime role: rapp-qonto
  • existing bank credential reference: tenants/binky/qonto-api
  • tenant claim: tenant:friendly:binky, subject to the open NetKingdom canon alignment already recorded in KEY-WP-0004

Any identity or role named qonto-assistant is a migration bridge with an owner and expiry, not the steady-state contract.

Least-Privilege Contract

The runtime client:

  • uses a non-interactive workload grant
  • receives only the Binky tenant claim and the minimum Qonto runtime scopes
  • receives no platform-root, other-tenant, or tenant-admin authority
  • uses short-lived tokens
  • is independently revocable

The workload role may resolve only the Qonto runtime secret references required by the package. Positive access and unrelated-role denial must both be tested.

Automation And Custody

Credential planning begins with warden plan.

The 2026-07-26 plan result is:

  • Forgejo and deployment-key use can be autonomous through sanctioned warden access --exec, --out, or --wrap transports.
  • First-time provisioning of a new OpenBao value remains one explicit founder authority act through warden desk; agents must not replace it with a file drop or captured stdout.
  • The existing Qonto bank credential lane is resolvable but high risk and must never be streamed to an agent.

After the first authority act, issuance tests, negative access, revocation, posture conformance, route discovery, and evidence reconciliation should be agent-executable and then scheduled where stable.

Required Non-Secret Evidence

  • client id, issuer, audiences, scopes, token TTL, and tenant claim
  • workload role and secret-reference path names
  • positive token exchange without token disclosure
  • wrong-tenant and excessive-scope denial
  • positive/negative OpenBao capability checks
  • revocation result
  • ops-warden route and conformance result
  • migration-bridge expiry, if used