Send-flow починається не з кнопки Send
AI agent send crypto transaction - це не команда "відправ 100 USDT" у prompt. Для продукту, який дозволяє агенту рухати кошти, send-flow має починатися зі структурованого intent, проходити policy checks, мати idempotency key, отримувати Co-Signer approval, підписуватися через MPC і завершуватися статусом у ledger та WebSocket events.
Це важлива межа. AI-агент може допомогти оператору, support-команді, finance або продукту підготувати транзакцію. Але модель не має отримувати приватні ключі, MPC shares, API private keys або необмежене право витрачати кошти. Якщо агент може відправляти USDT, USDC або інші supported assets, інфраструктура має примусово перевіряти amount, destination, asset, network, business reason і risk state.
У BroLabel такий flow логічно будувати через BroLabel AI Agents, BroSettlement і Agent Skills. Агент створює signed request або send intent. Wallet infrastructure перевіряє policy, Co-Signer тримає signing boundary поза model context, MPC підписує transaction, а ledger фіксує результат.
Коротка відповідь
AI-агент може відправляти crypto transactions без доступу до приватного ключа, якщо він працює через scoped API access, customer-hosted Co-Signer, allowlist, spending limits, idempotent requests і ledger tracking. Безпечний flow: агент створює send intent, інфраструктура перевіряє policy, Co-Signer підтверджує або відхиляє операцію, MPC підписує transaction, broadcast відправляє її в мережу, а WebSocket events показують статус.
Чому autonomous sending потребує жорсткої межі
Receive-flow відносно безпечніший: агент може створити address, слухати events і показувати balance state. Send-flow інший. Тут помилка може одразу перемістити кошти на неправильний destination, обійти internal approval або створити duplicate payout.
Типові failures у send-flow:
- Unbounded spend. Агент може відправити більше, ніж дозволено workflow або бюджетом.
- Wrong destination. Address виглядає валідною, але не входить в allowlist або належить неправильному отримувачу.
- Duplicate transaction. Retry без idempotency key створює другий payout.
- Wrong asset or network. User просив USDT TRON, а intent створений для іншої network або asset.
- Missing business reference. Finance бачить transaction hash, але не бачить invoice, user, withdrawal request або case ID.
- Prompt-secret leakage. Хтось намагається дати агенту seed phrase, private key або recovery material.
Правильна архітектура не питає: "чи достатньо розумний агент". Вона питає: "яка система не дасть агенту підписати неправильну дію".
Як це працює
Контрольований send-flow має кілька незалежних шарів.
- Agent runtime отримує user або system request.
- Агент створює structured send intent замість raw transaction.
- API request підписується scoped Ed25519 key.
- Wallet infrastructure перевіряє wallet, asset, network, balance і idempotency key.
- Policy layer перевіряє limits, allowlist, velocity, role і compliance state.
- Customer-hosted Co-Signer підтверджує або відхиляє intent.
- MPC signing створює transaction signature без розкриття private key.
- Transaction broadcast відправляє signed transaction у blockchain network.
- Ledger і WebSocket events оновлюють product, support і finance.
Агент у цьому flow не є custody layer. Він є операційним інтерфейсом, який готує intent і читає state. Signing authority залишається в захищеній інфраструктурі.
Required fields для send intent
Send intent має бути достатньо структурованим, щоб його могли перевірити machine policy і людина.
| Field | Навіщо потрібне | Приклад контролю |
|---|---|---|
| walletId | Який wallet відправляє кошти | Wallet має належати правильному account або treasury |
| network | У яку мережу йде transaction | Дозволити тільки supported networks |
| asset | Який token або coin відправляється | Відхилити невідомий asset |
| amount | Сума transaction | Перевірити per-transaction limit |
| destination | Address отримувача | Перевірити allowlist або risk policy |
| businessReference | Invoice, withdrawal, case або workflow ID | Дати finance повну звірку |
| idempotencyKey | Захист від duplicate sends | Один business action - один payout |
| requestedBy | Хто або який agent створив intent | Audit trail і accountability |
| policyProfile | Який набір правил застосувати | Різні ліміти для support, treasury, payout bot |
Якщо intent не має business reference або idempotency key, його краще відхилити до signing. Це дешевше, ніж потім розбирати duplicate payout або непояснений withdrawal.
Policy matrix: що має перевірити Co-Signer
Co-Signer не має бути просто "сервером, який підписує". Для AI-agent wallet він має бути policy boundary між model intent і transaction signing.
| Check | Що перевіряється | Типове рішення |
|---|---|---|
| Asset and network | Asset і network дозволені для цього wallet | Reject або continue |
| Amount cap | Сума не перевищує per-transaction limit | Reject, manual review або continue |
| Velocity limit | Денний або тижневий spend не перевищено | Pause або review |
| Destination allowlist | Address дозволена або проходить risk policy | Reject або review |
| Role and permission | Agent або user має право ініціювати цей action | Reject або continue |
| Balance and liquidity | Wallet має доступний balance | Reject або queue |
| Business reference | Є invoice, withdrawal request або case ID | Reject якщо reference відсутній |
| Compliance state | KYC/KYB, AML і Travel Rule checks актуальні, якщо застосовно | Review або reject |
| Emergency pause | Немає активного stop condition | Reject |
Для агентів корисна модель "cold by default, online only to sign". Це не обіцянка strict air-gapped cold wallet, якщо така deployment model не налаштована. Це практичний принцип: Co-Signer не має бути безконтрольно доступним агенту постійно; він активується для constrained signing, перевіряє policy і вимикає доступ після операції.
Auto-approval vs manual review
Не кожна transaction має чекати людину. Але не кожна має проходити автоматично.
Auto-approval підходить для повторюваних, низькоризикових operations:
- destination уже в allowlist;
- amount нижче configured limit;
- asset і network дозволені;
- business reference існує;
- idempotency key новий;
- compliance state не блокує payout;
- velocity limits не перевищено.
Manual review потрібен, коли destination новий, amount високий, withdrawal нетиповий, user risk state змінився, Travel Rule data неповна або agent request не збігається з business context.
Важливо: manual review не має жити в prompt. Людина або ops system має бачити structured intent, policy result, wallet, amount, address, reference і risk reason.
Що ніколи не має потрапляти в prompt
Send-flow не вимагає, щоб модель бачила секрети. Не передавайте агенту:
- private keys або seed phrases;
- API private keys;
- encryption keys;
- MPC share material;
- Co-Signer persistent volume contents;
- recovery files;
- admin credentials;
- raw environment variables;
- unrestricted wallet export або backup material.
Агенту достатньо scoped permissions для allowed API actions: create send intent, read policy result, read transaction status, listen to events і show ledger records. Підписання має проходити через Co-Signer і MPC.
Покроковий flow
- User або system ставить задачу. Наприклад: "відправ 250 USDC approved vendor".
- Агент визначає context. Wallet, asset, network, destination, amount і business reference.
- Агент створює send intent. Intent включає idempotency key і policy profile.
- API request підписується. Scoped Ed25519 key підтверджує identity automation layer.
- Infrastructure перевіряє базові умови. Wallet існує, balance доступний, network підтримується.
- Policy layer перевіряє risk. Limits, allowlist, velocity, permissions і review thresholds.
- Co-Signer приймає рішення. Approve, reject або manual review.
- MPC signing створює signature. Private key не збирається в одному місці й не потрапляє в model context.
- Transaction broadcast відправляє signed transaction. Product отримує transaction hash.
- WebSocket events оновлюють статус.
intent_created,policy_reviewed,approved,mpc_signing,broadcast,confirmed,failedабоmanual_review. - Ledger фіксує результат. Finance бачить amount, account, wallet, reference, hash, timestamps і final state.
Якщо будь-який крок не проходить, agent response має показати state і next action, а не повторювати send request без контролю.
Як тут підходить BroSettlement
BroSettlement підходить для команд, яким потрібен не hosted checkout, а API-first wallet, ledger і settlement infrastructure. Для AI-agent send-flow це означає:
- Agent Skills для Codex, Claude Code, Cursor або іншого agentic tooling;
- scoped Ed25519 API keys для automation;
- customer-hosted Co-Signer як signing boundary;
- MPC signing без приватного ключа в prompt;
- idempotent send requests;
- WebSocket events для transaction lifecycle;
- ledger records для audit і reconciliation;
- policy controls для limits, destinations, roles і review.
Це не знімає з команди KYC/KYB, AML, Travel Rule, licensing або jurisdiction responsibilities. BroSettlement дає infrastructure layer. Команда все одно має визначити правила, risk process і legal requirements для свого ринку.
Checklist перед production
Перед тим як дати AI-агенту send access, перевірте:
- які wallets агент може бачити;
- які assets і networks дозволені;
- які per-transaction і daily limits діють;
- які destinations входять в allowlist;
- коли потрібен manual review;
- хто може approve або pause flow;
- де зберігається Co-Signer runtime;
- чи не потрапляють secrets у prompt або logs;
- як працює idempotency для retries;
- які WebSocket events слухає продукт;
- як ledger records потрапляють до finance;
- що відбувається при failed або stuck transaction.
Якщо ці answers не задокументовані, агент ще не готовий до autonomous sending.
FAQ
Чи може AI-агент відправляти crypto transactions?
Так, але тільки через контрольований flow. Агент має створювати send intent або signed API request, а не отримувати приватний ключ. Policy layer, Co-Signer і MPC signing мають визначати, чи transaction можна підписати.
Чи потрібен агенту приватний ключ?
Ні. Приватні ключі, seed phrases, MPC shares і recovery material мають залишатися поза prompt і model context. Агенту достатньо scoped API access і читання статусів.
Навіщо потрібен idempotency key?
Idempotency key захищає від duplicate sends. Якщо network або API request retry повторюється, infrastructure має зрозуміти, що це той самий business action, а не новий payout.
Що перевіряє Co-Signer?
Co-Signer має перевірити asset, network, amount, velocity limits, destination allowlist, permissions, business reference, emergency pause і applicable compliance state.
Коли потрібен manual review?
Manual review потрібен для нових destinations, великих amounts, нетипових withdrawals, неповних compliance даних або intent, який не збігається з business context.
Як відстежити статус transaction?
Product або agent runtime має слухати WebSocket events і читати ledger records. Корисні стани: intent_created, policy_reviewed, approved, mpc_signing, broadcast, confirmed, failed і manual_review.