Створи мені гаманець: AI-агент і безпечні транзакції

Як AI-агент може створити testnet-гаманець, отримувати й відправляти транзакції без приватних ключів у prompt, з Co-Signer і MPC.

BroLabel TeamAI AgentsInfrastructureIntegration
Створи мені гаманець: AI-агент і безпечні транзакції

Коли запит звучить просто, ризик зазвичай прихований

"Створи мені гаманець, щоб я міг отримувати та відправляти транзакції" - це правильний запит для AI-агента, але неправильна відповідь на нього не має виглядати як seed phrase у чаті. Якщо агент просто генерує приватний ключ, показує його користувачу й пропонує скопіювати в нотатки, команда отримує не wallet infrastructure, а операційний ризик.

Для BroLabel цей запит варто читати як product workflow. Користувач не просить "дай мені секрет". Він хоче робочий гаманець, який може приймати кошти, відправляти транзакції, показувати статуси й не втрачати контроль над підписанням. Саме тут BroLabel AI Agents, BroSettlement і Agent Skills мають працювати разом.

AI-агент може провести користувача через setup, підготувати API identity, допомогти запустити Co-Signer, перевірити MPC/DKG readiness, створити testnet wallet, отримати deposit address і виконати першу транзакцію. Але агент не має отримувати приватний ключ, MPC share material або безмежний доступ до коштів.

Коротка відповідь

Так, AI-агент може допомогти створити гаманець для отримання й відправлення транзакцій, але він не має отримувати приватний ключ. Безпечніший flow: встановити Agent Skills, створити scoped Ed25519 API key, запустити customer-hosted Co-Signer, пройти MPC/DKG readiness, створити testnet wallet, отримати deposit address і відправляти транзакції тільки через ліміти, allowlist, idempotency key, WebSocket events і ledger tracking.

Як це працює

Правильна модель проста: агент формує намір, інфраструктура виконує контроль. Модель може зрозуміти задачу, поставити уточнення, підготувати параметри, викликати API й пояснити результат. Але підписання, політики, секрети й журнали мають залишатися у контрольованому runtime.

У BroSettlement workflow складається з кількох шарів:

  1. Agent Skills. Агент отримує інструкції, як працювати з BroSettlement API й onboarding flow, не вигадуючи небезпечні кроки.
  2. Scoped API identity. Для автоматизації використовується Ed25519 API key з обмеженими правами, а не wallet private key.
  3. Customer-hosted Co-Signer. Частина підписувального процесу працює у середовищі клієнта й перевіряє локальну policy.
  4. MPC/DKG readiness. Гаманець готовий до підписання тільки після коректного threshold setup.
  5. Wallet and address creation. Агент може створити testnet wallet і отримати адресу для депозитів.
  6. Transaction intent. Для відправлення агент створює structured request: wallet, network, asset, amount, destination, idempotency key.
  7. Events and ledger. WebSocket events і журнал показують, що було створено, підписано, відправлено, підтверджено або відхилено.

Це не "AI отримав гаманець". Це "AI працює через wallet infrastructure, яка не дає йому обійти контроль".

Flow отримання транзакцій

Отримання коштів не закінчується на адресі. Якщо агент створив адресу, але продукт не бачить confirmations, balance impact і internal owner, finance й support все одно працюватимуть вручну.

Практичний receive flow виглядає так:

  1. агент створює або вибирає wallet для конкретного user, account або use case;
  2. BroSettlement повертає deposit address для потрібної network і asset;
  3. продукт показує адресу користувачу або передає її сервісу, який має зробити оплату;
  4. incoming transaction потрапляє в мережу;
  5. WebSocket event повідомляє про deposit detection;
  6. система чекає потрібну кількість confirmations;
  7. ledger фіксує зміну балансу й transaction history;
  8. агент або support-інтерфейс може пояснити фінальний статус.

Ключова частина тут - mapping. Адреса має бути пов'язана з внутрішнім account, agent workflow, invoice або операційною дією. Без цього команда бачить on-chain hash, але не бачить бізнес-контекст.

Flow відправлення транзакцій

Відправлення має бути ще жорсткіше контрольованим, бо тут агент рухає кошти з балансу. Нормальний агент не повинен писати: "я думаю, можна відправити". Він має створити transaction intent, який інфраструктура перевіряє.

У send request мають бути:

  • wallet;
  • network;
  • asset;
  • amount;
  • destination;
  • idempotency key;
  • business reason або reference;
  • policy context, якщо потрібен callback.

Idempotency key важливий не для краси API. Він захищає від дублювання, якщо агент або runtime повторить запит після timeout. У фінансових операціях retry без idempotency швидко створює duplicate withdrawal problem.

Далі Co-Signer перевіряє policy: чи дозволена мережа, чи дозволений asset, чи сума в межах ліміту, чи destination у allowlist, чи не порушено velocity limits, чи не потрібен manual approval. Якщо policy не проходить, транзакція не має підписуватися, навіть якщо модель упевнена у відповіді.

Якщо policy дозволяє дію, MPC-процес створює підпис без складання повного приватного ключа. Після broadcast команда відстежує статус через WebSocket events і ledger, а не через скріншот із block explorer.

Що ніколи не має потрапляти в prompt

Model context не є secret store. Це правило варто записати в onboarding checklist для кожної команди, яка дає AI-агенту доступ до wallet operations.

У prompt, chat history, tool output і логах не мають з'являтися:

  • seed phrase;
  • raw private key;
  • encryption key;
  • MPC share material;
  • unscoped production API secret;
  • Co-Signer persistent volume contents;
  • recovery material;
  • credentials, які агент може самостійно змінити або експортувати.

Агент може знати, що існує wallet, policy, ліміт і API endpoint. Він не має знати secret material. Якщо для дії потрібен секрет, він має жити у runtime, vault, Co-Signer або іншому контрольованому середовищі, а не в текстовій інструкції.

Також агент не має сам собі підвищувати права. Якщо він може змінити власний ліміт, додати новий destination в allowlist і одразу відправити кошти, це не автономність. Це відсутність control boundary.

Покроковий flow

Для першого запуску варто йти testnet-first:

  1. Відкрийте BroLabel AI Agents і скопіюйте installation prompt.
  2. Встановіть офіційні brosettlement-onboarding і brosettlement-api Agent Skills.
  3. Перевірте SKILL.md, scripts і destination folder перед запуском.
  4. Створіть або підтвердьте BroSettlement organization.
  5. Створіть scoped Ed25519 API key для агентського runtime.
  6. Запустіть customer-hosted Co-Signer у контрольованому середовищі.
  7. Пройдіть MPC/DKG readiness checks.
  8. Створіть testnet wallet.
  9. Отримайте deposit address і зробіть тестовий deposit.
  10. Перевірте WebSocket events, confirmations і ledger entry.
  11. Створіть send intent з idempotency key і невеликою testnet-сумою.
  12. Перевірте Co-Signer policy, MPC signing, broadcast і фінальний статус.
  13. Тільки після цього описуйте production limits, allowlists, emergency pause і review rules.

Такий flow повільніший за "ось seed phrase", але він масштабується. Команда отримує не разовий гаманець, а повторюваний operating model.

Контрольна матриця перед production

ПитанняЩо має бути готово
Хто може створити wallet?Scoped API role і audit trail
Як агент отримує кошти?Address mapping, deposit events, confirmations
Як агент відправляє кошти?Transaction intent, idempotency key, Co-Signer policy
Де живуть секрети?Не в prompt; у runtime, vault або Co-Signer boundary
Як зупинити агента?Emergency pause, revoked API key, disabled policy
Як finance робить звірку?Ledger entries, transaction references, balance history
Як support бачить статус?WebSocket events і зрозумілі state transitions

Ця матриця важливіша за вибір красивого wallet UI. Якщо команда не може відповісти на ці питання, agent wallet ще не готовий до реальних коштів.

FAQ

Чи може AI-агент створити гаманець?

Так, якщо він працює через контрольований onboarding flow і API. Агент може створити testnet wallet, отримати адресу й підготувати транзакцію, але не має генерувати або зберігати приватний ключ у prompt.

Чи отримує агент приватний ключ?

Ні. У правильній архітектурі агент працює через scoped API access, Co-Signer policy і MPC signing. Secret material не має потрапляти в модель, чат або логи.

Як гаманець отримує транзакції?

Система створює deposit address, мапить її на account або workflow, слухає WebSocket events, чекає confirmations і записує balance impact у ledger.

Як AI-агент відправляє транзакцію?

Агент створює transaction intent з network, asset, amount, destination і idempotency key. Co-Signer перевіряє policy, MPC підписує дозволену дію, а BroSettlement показує статус через events і журнал.

Що робити перед production?

Запустити testnet flow, перевірити DKG/MPC readiness, задати ліміти, allowlists, emergency pause, callback або manual review, а також підтвердити, що finance бачить ledger і reconciliation data.

Висновок

Запит "створи мені гаманець" не має закінчуватися приватним ключем у чаті. Для AI-агентів правильна відповідь - це контрольований wallet workflow: Agent Skills, scoped Ed25519 API key, customer-hosted Co-Signer, MPC signing, idempotency, WebSocket events і ledger.

AI може допомогти створити гаманець і провести перші транзакції. Але контроль над коштами має залишатися в інфраструктурі.

Створи мені гаманець: AI-агент і безпечні транзакції