Brex у Claude: як дати finance assistant read/write доступ без передачі approval authority

Finance questions регулярно виникають не в expense app, а під час іншої роботи: чи потрібен receipt, скільки залишилось T&E limit, коли прийде reimbursement, який policy rule діє. Brex перенесла цей interaction layer у Claude через connector замість примушувати користувача кожного разу відкривати окремий dashboard.

Важливий design choice — connector не робить Claude новим finance system of record. Brex лишається джерелом permissions, expenses, cards, policies, balances та audit. Claude — conversational/orchestration surface над дозволеними tools. Саме так integration не перетворюється на чергову копію фінансового стану в prompt history.

Trigger — natural-language request у Claude: знайти transaction, перевірити limit, пояснити policy або виправити власний expense. Input формується через connector із Brex-authorized data, а не зі сліпого user paste. Claude інтерпретує intent, обирає дозволений tool, формує аргументи й повертає grounded result або bounded action proposal.

Brex описує read доступ до expenses, balances, cards, vendors, bills, accounting records та travel context залежно від ролі. Write scope навмисно вужчий: користувач може оновлювати memos, receipts, attendees і власні spend-limit actions у визначеному scope, тоді як admin approvals лишаються у Brex dashboard.

• Trigger → запит користувача в Claude;
• Input → identity + Brex permissions + relevant expense/policy records;
• AI stage → intent, tool selection, argument construction, explanation;
• Integration → Brex connector / Brex systems of record;
• Output → answer, structured finance data, chart або bounded write result;
• HITL → user intent/confirmation + dashboard approval для admin-level actions.

Brex прямо пише, що permissions переносяться в connector: користувач бачить і змінює лише те, на що авторизований. Це значно сильніший control, ніж system prompt із фразою «ніколи не чіпай чужі витрати». Authorization має жити в tool/application layer і перевірятися на кожний call.

Ще важливіше, admin-level approvals залишаються у Brex dashboard, де живе audit trail. Це хороший authority split для A3: AI може прискорити discovery і self-service writes, але не отримує автоматично право approve/reject expenses або змінювати чужі financial records.

Finance connector має обробляти не лише LLM mistakes. Реальні failures: session identity змінилась; transaction уже edited у mobile app; upload receipt завершився частково; limit змінився між read і write; timeout стався після успішного update; tool list застарів. Brex support окремо зазначає refresh connector tools після update у травні 2026 року — schema/version drift тут не теорія.

Reproduction pattern: re-read authoritative record перед mutating call, include version/idempotency key де API дозволяє, validate payload, execute, потім verify postcondition. Після timeout спершу query current state. Якщо user просить admin action поза connector scope, система повинна route у dashboard, а не винаходити обхід.

Brex повідомляє, що customers її AI-native finance platform у середньому підтримують приблизно 98% policy compliance. У тому ж product material connector описується як розширення цієї financial intelligence в Claude. Це не дає підстав стверджувати, що саме connector підняв compliance до 98%.

Для власного connector rollout міряйте task completion, tool-call success, incorrect-write rate, permission-denied correctness, duplicate-action rate, handoff-to-dashboard rate, time saved per expense task, user correction rate, p95 latency і cost per successfully completed finance task.

Workflow високочастотний у компаніях із travel/expense volume: lookup tasks дешеві, write flows дорожчі через attachment handling, validation і retries. Масштабування переважно визначається Brex API/connector limits, identity sessions, concurrency і finance data freshness, а не одним LLM rate limit.

Cost model: Claude plan/API usage + connector/platform cost + identity/security administration + observability/evals + finance-ops exceptions. Requirements: managed Claude workspace, Brex account/permissions, approved connector policy, data-retention review, audit ownership і чітке правило, які actions дозволено виконувати поза Brex dashboard.

Патерн підходить finance/expense, CRM, HRIS, procurement та ticketing systems, де користувач уже має granular permissions і багато дрібних self-service tasks. Найкращий 80/20 старт — read-only lookup + одна reversible write action для власного record.

Rollout: inventory tools/permissions → read-only pilot → eval на identity/tenant/permission boundaries → одна bounded write action → idempotency/postcondition → limited production → expand by risk tier. Admin approvals, money movement, payroll або irreversible actions не додавайте в той самий tier лише тому, що connector уже працює.

• Виписати read/write tools і authority owner для кожного.
• Почати read-only та перевірити permission isolation.
• Додати одну self-service write action із postcondition.
• Прогнати stale-state, duplicate, denied-access і tool-schema-change cases.
• Залишити high-authority approvals у system-of-record UI.
• Масштабувати тільки після stable incorrect-write та reconciliation metrics.