Процес відправлення починається не з кнопки Send
Відправлення криптотранзакції AI-агентом - це не команда "відправ 100 USDT" у запиті. Для продукту, який дозволяє агенту рухати кошти, процес відправлення має починатися зі структурованого наміру, проходити перевірки правил, мати ключ ідемпотентності, отримувати схвалення Co-Signer, підписуватися через MPC і завершуватися статусом в операційному журналі та подіях WebSocket.
Це важлива межа. AI-агент може допомогти оператору, команді підтримки, фінансовій або продуктовій команді підготувати транзакцію. Але модель не має отримувати приватні ключі, частки MPC, приватні API-ключі або необмежене право витрачати кошти. Якщо агент може відправляти USDT, USDC або інші підтримувані активи, інфраструктура має примусово перевіряти суму, адресу отримувача, актив, мережу, операційну підставу і стан ризику.
У BroLabel такий процес логічно будувати через BroLabel AI-агенти, BroSettlement і Agent Skills. Агент створює підписаний запит або намір відправлення. Інфраструктура гаманців перевіряє правила, Co-Signer тримає межу підписання поза контекстом моделі, MPC підписує транзакцію, а операційний журнал фіксує результат.
Коротка відповідь
AI-агент може відправляти криптотранзакції без доступу до приватного ключа, якщо він працює через доступ до API з обмеженими правами, розгорнутий у клієнта Co-Signer, список дозволених адрес, ліміти витрат, ідемпотентні запити і відстеження в журналі. Безпечний процес: агент створює намір відправлення, інфраструктура перевіряє правила, Co-Signer підтверджує або відхиляє операцію, MPC підписує транзакцію, відправлення в мережу передає її у блокчейн, а події WebSocket показують статус.
Чому автономне відправлення потребує жорсткої межі
Процес отримання відносно безпечніший: агент може створити адресу, слухати події і показувати стан балансу. Процес відправлення інший. Тут помилка може одразу перемістити кошти на неправильну адресу отримувача, обійти внутрішнє схвалення або створити повторну виплату.
Типові відмови у процесі відправлення:
- Необмежені витрати. Агент може відправити більше, ніж дозволено робочим процесом або бюджетом.
- Неправильна адреса отримувача. Адреса виглядає валідною, але не входить у список дозволених адрес або належить неправильному отримувачу.
- Повторна транзакція. Повторна спроба без ключа ідемпотентності створює другу виплату.
- Неправильний актив або мережа. Користувач просив USDT TRON, а намір створений для іншої мережі або іншого активу.
- Відсутня операційна підстава. Фінансова команда бачить хеш транзакції, але не бачить інвойс, користувача, запит на виведення або ID кейсу.
- Витік секретів через запит. Хтось намагається дати агенту seed-фразу, приватний ключ або матеріали відновлення.
Правильна архітектура не питає: "чи достатньо розумний агент". Вона питає: "яка система не дасть агенту підписати неправильну дію".
Як це працює
Контрольований 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.
