coulomb/qonto-assistant
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
A policy governed qonto domain API and MCP assistant for binky-control.
40 commits 1 branch 0 tags 488 KiB
Find a file
tegwick 9fbcef7b05 QONTO-WP-0004-T06: draft isolation placement manifests + railiance/app.toml 
Concrete, reviewable placement request per docs/SecurityPractice.md #7
(I1 Reinforced minimum: dedicated node pool/namespace, given internet
reachability via the facade and sole custody of the bank credential).

deploy/k8s/qonto-assistant/: modeled on llm-connect's real deployment
(deploy/k8s/activity-core-llm-connect/) but tightened -- dedicated
namespace (not shared), Deployment starts at replicas:0 (meant to be
scaled 0<->1 by the facade, QONTO-WP-0004-T05), ClusterIP-only Service,
NetworkPolicy default-deny with ingress limited to the facade and
egress limited to DNS+443 (the FQDN-egress limitation is called out
explicitly, not silently widened). Verified: `kubectl kustomize`
renders all six resources cleanly.

externalsecret.yaml depends on CCR-2026-0009 (new), proposed in
railiance-platform: a workload-scoped Kubernetes-auth access lane into
the existing tenants/binky/qonto-api credential, since CCR-2026-0008
is human/OIDC admin access only and unusable by a running pod. Mirrors
CCR-2026-0003's llm-connect/ExternalSecretsOperator pattern. Paired
draft ClusterSecretStore also added there. Both validated against
schemas/credential-change-request.schema.yaml. Status: proposed, not
approved -- explicitly not something this repo can complete alone.

railiance/app.toml: staged-promotion contract (criticality=critical,
mandatory human approval before Stage 2 traffic exposure and Stage 3
promotion, per railiance-cluster/docs/app-toml-contract.md's own rule
for production-critical workloads). Validated against
railiance-cluster/schemas/railiance-app.schema.json.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-24 00:27:37 +02:00
deploy/k8s/qonto-assistant QONTO-WP-0004-T06: draft isolation placement manifests + railiance/app.toml 2026-07-24 00:27:37 +02:00
docs QONTO-WP-0004-T04: live flex-auth + tenant-engine authorization gate 2026-07-24 00:19:04 +02:00
railiance QONTO-WP-0004-T06: draft isolation placement manifests + railiance/app.toml 2026-07-24 00:27:37 +02:00
research Bootstrap qonto-assistant: intent, blueprint, research, workplans 2026-07-21 23:32:24 +02:00
scripts QONTO-WP-0003-T06: MCP smoke script + operator runbook update 2026-07-23 11:04:39 +02:00
specs Add SecurityPractice.md, Security Genome record, and deny-escalation lockout 2026-07-23 22:59:06 +02:00
src/qonto_assistant QONTO-WP-0004-T04: live flex-auth + tenant-engine authorization gate 2026-07-24 00:19:04 +02:00
tests QONTO-WP-0004-T04: live flex-auth + tenant-engine authorization gate 2026-07-24 00:19:04 +02:00
workplans QONTO-WP-0004: mark T03/T04 done 2026-07-24 00:21:04 +02:00
.custodian-brief.md chore(consistency): sync task status from DB [auto] 2026-07-24 00:21:24 +02:00
.gitignore Bootstrap qonto-assistant: intent, blueprint, research, workplans 2026-07-21 23:32:24 +02:00
.repo-classification.yaml Complete Phase 1: policy kernel, REST service, and local smoke tooling 2026-07-22 21:21:05 +02:00
AGENTS.md Complete Phase 1: policy kernel, REST service, and local smoke tooling 2026-07-22 21:21:05 +02:00
INTENT.md Seeded intent and initial workplan 2026-07-22 00:31:50 +02:00
LICENSE Initial commit 2026-07-21 21:19:44 +00:00
Makefile Complete Phase 1: policy kernel, REST service, and local smoke tooling 2026-07-22 21:21:05 +02:00
pyproject.toml QONTO-WP-0004-T03: verify key-cape IAM Profile tokens 2026-07-24 00:10:41 +02:00
README.md QONTO-WP-0003-T07: close out Phase 2 MCP workplan 2026-07-23 13:56:06 +02:00
SCOPE.md Bootstrap qonto-assistant: intent, blueprint, research, workplans 2026-07-21 23:32:24 +02:00
WORK-RECORDS.md chore(consistency): sync T03/T04 status from DB [auto] 2026-07-24 00:21:32 +02:00

README.md

qonto-assistant

Policy-governed Qonto domain API and MCP assistant for Binky (and later multi-tenant dogfood).

One choke point for bank access across every coding agent and harness. Clients never hold the Qonto API key. v1 policy: read for awareness only — no spend, no volume-cost actions.

Start here

Doc What
INTENT.md Why this exists; boundaries
specs/ArchitectureBlueprint.md Architecture, phases, policy model
research/2026-07-21-mcp-gateway-and-governed-domain-assistant.md External + internal research
docs/operator-runbook.md How to run and verify Phase 1 (REST)
docs/mcp-integration.md How to run and verify Phase 2 (MCP)

Status

Phase 1 runtime is implemented:

  • Python 3.12 service under src/qonto_assistant/
  • default-deny YAML policy
  • Qonto read-only client (organization, transactions)
  • REST endpoints: /v1/health, /v1/accounts, /v1/transactions, /v1/snapshot
  • audit metadata, rate limiting, concurrency bounds, tests

Phase 2 (MCP surface, workplans/QONTO-WP-0003-mcp-surface.md) is finished: a streamable-HTTP MCP adapter is mounted at /mcp on the same capability core and policy kernel as REST — proven identical by test, not just by construction (tests/test_policy.py, tests/test_audit_parity.py) — with tools qonto_org_summary, qonto_list_transactions, and qonto_cost_run_rate_hints. The endpoint is gated by a shared-secret bearer token (QONTO_ASSISTANT_MCP_TOKEN); see docs/mcp-integration.md for the auth model, its explicit gap vs. the OIDC/workload target (no issuer exists in this fleet yet), and the shared multi-harness client config snippet. The finance-qonto-read agent-harness tool profile is documented (qonto-assistant side) but not yet registered in agent-harness itself — separate repo, separate workplan.

Current verification:

  • PYTHONPATH=src ../state-hub/.venv/bin/python -m pytest → 31 passed
  • python3 -m compileall src tests scripts
  • ../state-hub/.venv/bin/python scripts/smoke_rest_api.py --python ../state-hub/.venv/bin/python
  • ../state-hub/.venv/bin/python scripts/smoke_mcp.py --python ../state-hub/.venv/bin/python

Local fixture-backed smoke mode is available through QONTO_FIXTURE_DIR, so the service can be exercised without real Qonto credentials. The REST smoke checks both a 31-day recent snapshot and a 90-day recurring-cost snapshot; the MCP smoke additionally exercises the bearer-token auth gate and an out-of-catalog tool deny path.

Phase 3 (flex-auth resource finance.qonto.read, graduated quotas, redaction profiles) is not started — see workplans/QONTO-WP-0003-mcp-surface.md closure notes for the seed.

Normal local workflow, when toolchain support exists:

make install-dev
make test
make run

Related

  • OpenBao lane: tenants/binky/qonto-api (ops-warden binky-qonto-api)
  • First pull / CostRunRate: binky-control BINKY-WP-0005