BINKY-WP-0005 finished: first Qonto pull and CostRunRate v2
All checks were successful
Work Records / validate (push) Successful in 13s

Live custody path tenants/binky/qonto-api (API_KEY/API_USER). First read-only
thirdparty pull (122 txs): desk 297.50 €/mo, Qonto plan 70.80 €/mo, main
balance 2185.94 €. Evidence under finance/; workplan status finished.
This commit is contained in:
tegwick 2026-07-21 21:42:10 +02:00
parent fc4c2149e3
commit 143eef2f0d
6 changed files with 1391 additions and 146 deletions

View file

@ -1,10 +1,10 @@
# Qonto MCP Integration — Design
> Status: design v1 — 2026-07-19 (BINKY-WP-0005, from AWQ-010).
> Status: **lane active** — 2026-07-21 (BINKY-WP-0005 finished).
> Goal: the company Qonto account becomes an agent-readable finance source
> (balance, transactions, statements) through the sanctioned harness/MCP
> lane. **Read scopes first; payments/transfers are Red lane forever.**
> Credential provisioning is a single founder Red-lane step (DEC-2026-004).
> (balance, transactions, statements) through the sanctioned harness/MCP /
> thirdparty API lane. **Read scopes first; payments/transfers are Red lane forever.**
> Credentials live at `tenants/binky/qonto-api` (CCR-2026-0008 / DEC-2026-004).
## Variant decision (T01)
@ -46,35 +46,38 @@ Same pattern as `integrations/company-email-openbao.md`
| Item | Value |
| --- | --- |
| Mount | `tenants` |
| Path | `tenants/binky/qonto/api` |
| Fields | `QONTO_API_KEY`, `QONTO_ORGANIZATION_ID` |
| Policy | `workload-kv-read-binky-qonto-api` (to be created, warden playbook) |
| Catalog | `binky-qonto-api` (draft until provision) |
| Path | **`tenants/binky/qonto-api`** (live) |
| Fields | **`API_KEY`**, **`API_USER`** (login/org slug) |
| MCP env map | `API_KEY``QONTO_API_KEY`, `API_USER``QONTO_ORGANIZATION_ID` |
| Policy | `workload-kv-read-binky-qonto-api` |
| OIDC role | `binky-qonto-api-workload-kv-read` |
| Catalog | `binky-qonto-api` (**active**, resolvable) |
| Risk | high (full-scope bank API key — read-only is harness-enforced) |
Auth to Qonto thirdparty API: `Authorization: <API_USER>:<API_KEY>`.
```text
founder (Red lane, once)
└─ bao kv put tenants/binky/qonto/api QONTO_API_KEY=@file QONTO_ORGANIZATION_ID=@file
└─ OpenBao: tenants/binky/qonto/api
└─ bao kv put tenants/binky/qonto-api API_KEY=@file API_USER=@file
└─ OpenBao: tenants/binky/qonto-api
└─ warden access binky-qonto-api --exec
└─ qonto-mcp-server (env names only) → harness read tools
└─ map fields → QONTO_* env → qonto-mcp-server / curl thirdparty
└─ finance/CostRunRate.md + rhythm session feeds
```
### Founder provision (Red lane — interactive human shell)
```bash
# In the Qonto dashboard: /settings/integrations → create API key, note org ID
# In the Qonto dashboard: /settings/integrations → create API key, note login/org slug
umask 077
# key into /tmp/qonto.key, org id into /tmp/qonto.org — private terminal only
bao kv put tenants/binky/qonto/api \
QONTO_API_KEY=@/tmp/qonto.key \
QONTO_ORGANIZATION_ID=@/tmp/qonto.org
shred -u /tmp/qonto.key /tmp/qonto.org
bao kv put tenants/binky/qonto-api \
API_KEY=@/tmp/qonto.key \
API_USER=@/tmp/qonto.user
shred -u /tmp/qonto.key /tmp/qonto.user
```
The organization ID is low-secrecy but lives with the key so consumers get
one fetch surface (same rule as IMAP username). **Key never in git/chat.**
`API_USER` is low-secrecy but lives with the key so consumers get one fetch
surface (same rule as IMAP username). **Key never in git/chat.**
## Consumer design (T03)
@ -97,72 +100,45 @@ Rules:
## Execution checklist
1. [x] Variant + read-only enforcement decided (this doc)
2. [x] OpenBao lane designed (`tenants/binky/qonto/api`)
2. [x] OpenBao lane designed → **live path `tenants/binky/qonto-api`**
3. [x] DecisionQueue package prepared (DEC-2026-004)
4. [x] DEC-2026-004 **approved** (founder, 2026-07-19)
5. [x] CCR-2026-0008 + policy HCL + agent-high-risk-boundary deny (railiance-platform)
6. [x] ops-warden catalog `binky-qonto-api` **draft** + playbook
(`ops-warden/wiki/playbooks/binky-qonto-api.md`)
7. [ ] **Red lane — founder (OH-2026-003):** create API key; `bao kv put` via `@file`
(see founder block below and `officehour/2026-08-command-day-runbook.md`)
8. [ ] Apply CCR-2026-0008 metadata (policy + OIDC role) — platform-operator
9. [ ] Capabilities-safe verify; promote catalog draft → active
10. [ ] First read-only pull; update CostRunRate TBC rows (BINKY-WP-0005-T05)
11. [ ] Wire Finance Steward recurring session (post-cutover, harness lane —
out of scope for BINKY-WP-0005 close; follow-on after T05)
5. [x] CCR-2026-0008 **active** (policy + OIDC role + agent-high-risk-boundary)
6. [x] ops-warden catalog `binky-qonto-api` **active** + playbook
7. [x] Red-lane secret present (`API_KEY` + `API_USER`)
8. [x] Capabilities-safe verify (lane-policy → `read` on data+metadata paths)
9. [x] First read-only pull 2026-07-21 (122 txs); CostRunRate v2
(`finance/qonto-first-pull-2026-07-21.json`)
10. [ ] Wire Finance Steward recurring session (post-cutover, harness lane —
**follow-on**, out of scope for BINKY-WP-0005)
## OH-2026-003 / T05 runbook (copy-paste)
## First-pull results (T05, 2026-07-21)
### A. Founder Red lane (interactive human shell only)
```bash
# 1) Qonto dashboard (browser):
# - /settings/integrations → create API key
# - copy organization ID
# - note plan tier + monthly fee (CostRunRate row 4)
# - optional while there: recent HUB31 / desk-rent debit amount (row 1)
# 2) OpenBao (private terminal — never paste key into chat/agent):
bao login -method=oidc -path=netkingdom # platform-admin or write-capable role
umask 077
# put key into /tmp/qonto.key and org id into /tmp/qonto.org (editor / paste)
bao kv put tenants/binky/qonto/api \
QONTO_API_KEY=@/tmp/qonto.key \
QONTO_ORGANIZATION_ID=@/tmp/qonto.org
shred -u /tmp/qonto.key /tmp/qonto.org
```
### B. Platform apply (after or before A — metadata only, no secret write)
```bash
cd ~/railiance-platform
# after platform-operator approval recorded on CCR-2026-0008:
python3 scripts/credential-change.py applier-dry-run CCR-2026-0008
python3 scripts/credential-change.py applier-apply CCR-2026-0008
# re-apply agent-high-risk-boundary if that policy is live-managed separately
```
### C. Promote + first pull (agent or human, Blue lane)
```bash
# capabilities-safe (never bao kv get for deny tests)
LANE=$(bao token create -policy=workload-kv-read-binky-qonto-api -ttl=2m -field=token)
bao token capabilities "$LANE" tenants/data/binky/qonto/api # expect read
bao token revoke "$LANE"
# promote ops-warden catalog entry status: draft → active (see playbook)
# then:
warden access binky-qonto-api --all --exec -- \
qonto-mcp-server # read tools only: org, accounts, transactions
# Update finance/CostRunRate.md rows 1 + 4 with verified amounts;
# log evidence metadata (dates, counterparties, amounts) — no bulk statements in git.
```
| Item | Value |
| --- | --- |
| Org | Binky Hedgehog GmbH |
| Main balance | 2185,94 € |
| Desk (HUB31) | **297,50 €/mo** |
| Qonto plan fee | **70,80 €/mo** (since 2025-10; was 22,80 / 35,40 earlier) |
| Evidence | `finance/qonto-first-pull-2026-07-21.json` |
**Harness read-only allow-list (enforce at session wire-up):** organization,
accounts, transactions, statements metadata, attachments metadata, labels.
Never: cards, invoicing, payment requests, transfers.
### Consumer fetch (after active)
```bash
bao login -method=oidc -path=netkingdom role=binky-qonto-api-workload-kv-read
umask 077
bao kv get -field=API_KEY tenants/binky/qonto-api > /tmp/qonto.key
bao kv get -field=API_USER tenants/binky/qonto-api > /tmp/qonto.user
export QONTO_API_KEY="$(cat /tmp/qonto.key)"
export QONTO_ORGANIZATION_ID="$(cat /tmp/qonto.user)"
shred -u /tmp/qonto.key /tmp/qonto.user
# Authorization for thirdparty API: "$QONTO_ORGANIZATION_ID:$QONTO_API_KEY"
```
## See also
- `integrations/company-email-openbao.md` — custody pattern being mirrored