Model context - це не сховище секретів
AI agent MPC wallet не має починатися з приватного ключа в prompt. Якщо модель бачить seed phrase, API private key, encryption key або MPC share, команда вже перейшла неправильну межу контролю. Агент може допомогти створити гаманці й підготувати транзакції, але signing material має жити у захищеній runtime-інфраструктурі поза chat history, logs і tool output.
Це важливо, бо фраза "AI wallet" звучить оманливо просто. Користувач просить агента створити гаманець, отримувати кошти й відправляти транзакції. У демо це можна "вирішити", надрукувавши ключ. У робочій системі так не можна. Коли автономний процес може рухати value, питання змінюється з "як створити адресу?" на "де живе authority, хто може схвалити відправлення і як ми доведемо, що саме сталося?"
Для BroLabel безпечніша відповідь - підключити агента до BroLabel AI Agents, BroSettlement і Agent Skills. Модель формує intent. Scoped API access, customer-hosted Co-Signer policy, MPC signing, WebSocket events і журнал забезпечують межу контролю.
Коротка відповідь
Так, AI-агент може допомогти створити й використовувати MPC-гаманець, але приватний ключ ніколи не має потрапляти в prompt. Безпечніша архітектура тримає secrets у protected runtime infrastructure, використовує scoped Ed25519 API keys для automation, запускає customer-hosted Co-Signer для локальних policy checks, проходить MPC/DKG readiness і дозволяє агенту відправляти тільки structured transaction intents через idempotent API requests, WebSocket events і ledger tracking.
Чому приватні ключі в prompt - неправильна модель
Prompt - це поверхня інструкцій, а не custody system. Він може зберігатися в conversation history, копіюватися у traces, використовуватися в tool calls, підсумовуватися, replay-итися або переглядатися людьми й системами, які не мають отримувати signing authority. Навіть якщо конкретний продукт каже, що захищає дані, операційний висновок той самий: model context - неправильне місце для secrets.
Команди часто змішують три різні категорії:
- Instruction. Що агенту потрібно зробити.
- Authorization. Які виклики або запити агенту дозволені.
- Signing authority. Що фактично може рухати активи.
Ці категорії не мають зливатися в один prompt. Хороший агент може зрозуміти інструкцію: "створи testnet wallet і підготуй USDT send". Він може використовувати authorization через scoped API identity. Але signing authority має залишатися поза моделлю і проходити через policy, MPC та audit records.
Те саме правило стосується seed phrases і API secrets. Seed phrase у вікні чату - це не self-custody, а leaked custody. API private key, вставлений у prompt, дає моделі reusable credential, який може бути залогований, скопійований або використаний не за призначенням. MPC share material ще чутливіший, бо бере участь у threshold signing.
Model context vs protected runtime
Найбезпечніша архітектура розділяє те, про що агент може міркувати, і те, що інфраструктура може підписувати.
| Layer | Що там має бути | Чого там не має бути |
|---|---|---|
| Model context | Task description, wallet label, network choice, asset, amount, destination, business reason | Private keys, seed phrases, API private keys, encryption keys, MPC shares |
| Agent tool runtime | Signed API request creation, validation helpers, idempotency keys, status reads | Long-lived unscoped secrets, raw wallet keys, hidden policy overrides |
| BroSettlement API | Wallet creation, address generation, transaction intent, status, ledger records | Customer MPC share material |
| Customer-hosted Co-Signer | Local policy, approval logic, MPC participation, protected persistent volume | Model instructions, які можуть самі змінити limits |
| Finance and operations layer | Ledger review, reconciliation, exception handling, support visibility | Unexplained on-chain activity без internal owner або reference |
Такий поділ робить агента корисним, але не робить його суверенним над коштами. Він може підготувати request, пояснити результат, безпечно повторити дію через idempotency і показати статус. Він не може непомітно обійти signing boundary.
Як AI-агент може безпечно використовувати MPC-гаманець
Controlled agent wallet flow починається ще до створення першої адреси.
- Команда визначає use case: отримувати депозити, платити постачальникам, тестувати x402-style payments, керувати service wallet або підтримувати user workflow.
- Агент використовує Agent Skills, а не імпровізовані інструкції.
- Оператор створює або надає доступ до BroSettlement organization.
- Automation отримує scoped Ed25519 API access, обмежений потрібними діями.
- Customer-hosted Co-Signer працює поза model context і тримає protected state.
- MPC/DKG readiness завершується до того, як будь-який wallet вважається готовим до signing.
- Агент створює або вибирає wallet і генерує deposit address.
- Для відправлення агент створює structured transaction intent з wallet, network, asset, amount, destination, business reference і idempotency key.
- Co-Signer policy оцінює request до підписання.
- Команда відстежує created, rejected, signed, broadcast, confirmed і failed states через WebSocket events і журнал.
Ключова думка: агент не "тримає гаманець". Він працює через інфраструктуру, яка вирішує, що насправді може відбутися.
Що вирішують scoped API keys, а що ні
Scoped API keys корисні, бо перетворюють широку інструкцію на контрольовану capability. AI-агенту може бути потрібно створити wallet, прочитати balances, згенерувати deposit address або відправити transaction request. Ці permissions мають бути явними й вузькими.
Але API keys не замінюють wallet signing controls. Scoped Ed25519 API key може автентифікувати request до BroSettlement. Його не слід плутати з приватним ключем самого гаманця. Якщо транзакція потребує підписання, request усе одно має пройти Co-Signer policy і MPC signing.
Хороший API access має кілька властивостей:
- Least privilege. Агент отримує тільки ті actions, які йому потрібні.
- Rotation. Credentials можна замінити без перебудови wallet.
- Separation by agent. Одна automation не має ділити unrestricted credentials з усіма іншими workflows.
- Auditability. Команда бачить, яка API identity запросила яку operation.
- No prompt storage. Private key material для API signing має оброблятися tooling або runtime, а не вставлятися в model text.
Саме тому shortcut "private key in prompt" настільки крихкий. Він пропускає і authorization design, і signing design.
Co-Signer policy - це межа контролю
Co-Signer - це місце, де autonomy зустрічається з policy. Модель може вирішити, що потрібно відправити платіж. Co-Signer вирішує, чи може цей request стати підписом.
Для AI wallet policy має покривати щонайменше:
| Policy area | Приклад контролю |
|---|---|
| Asset | Дозволити USDT або USDC, заблокувати unsupported assets |
| Network | Дозволити тільки approved networks для агента |
| Amount | Обмежити single transaction size |
| Velocity | Обмежити total spend per hour, day або week |
| Destination | Вимагати allowlist або risk check для outgoing addresses |
| Business reason | Вимагати invoice, customer, workflow або ticket reference |
| Approval path | Auto-approve low-risk sends, exceptions направляти в callback або human review |
| Emergency pause | Зупинити agent-initiated sends без видалення wallet infrastructure |
Ці правила мають жити в controlled infrastructure, а не тільки в інструкції "будь ласка, не витрачай забагато". Prompt - це guidance. Policy - це enforcement.
Що ніколи не має потрапляти в prompt
Коротке правило просте: якщо це може рухати гроші або розблокувати signing, цьому не місце в model context.
Не вставляйте:
- wallet private keys;
- seed phrases;
- API private keys;
- encryption keys;
- MPC share files або recovery material;
- contents of Co-Signer persistent volume;
- admin credentials;
- allowlist override secrets;
- emergency recovery credentials.
Також уникайте непрямих витоків. Не просіть агента друкувати secrets для debugging. Не зберігайте signing material у logs. Не додавайте private key paths у public issue trackers. Не дозволяйте агенту завантажувати runtime folders в unrelated repository. Не давайте tool call показувати environment variables у plain text.
Агент може знати, що key існує і що Co-Signer healthy. Йому не потрібно бачити key.
Як тут підходить BroLabel
BroLabel AI Agents і BroSettlement спроєктовані навколо цієї межі. Агент може працювати з official Agent Skills, API operations, wallet setup, event status і operational checks. Чутливі частини залишаються в інфраструктурі, створеній для signing і audit, а не в моделі.
Це найкраще підходить командам, яким потрібен агент для реальних wallet operations, але які все ще хочуть finance-grade records і controls:
- AI-продукти, де агенти платять за сервіси або отримують кошти.
- Developer platforms, які тестують agentic commerce або x402-style flows.
- Fintech-команди, які хочуть wallet automation без raw key exposure.
- iGaming, neobank або payment teams, яким потрібні event visibility і reconciliation.
- Internal automation teams, яким потрібен безпечний шлях від testnet до production.
BroSettlement не знімає з оператора регуляторні обов'язки. KYC/KYB, AML, Travel Rule handling, licensing і jurisdiction analysis усе одно потребують правильних процесів та інтеграцій. Але він дає чистішу control model для wallet creation, transaction requests, signing boundaries, events і ledger history.
Checklist для старту
Перед тим як давати AI-агенту wallet access, перевірте:
- Визначений точний wallet use case і maximum allowed actions.
- Використовуються official Agent Skills, а не ad hoc setup instructions.
- Усі private keys і MPC material залишаються поза prompt і model context.
- Для агента створено scoped Ed25519 API access.
- Co-Signer працює у protected customer-controlled environment.
- MPC/DKG readiness пройдено на testnet.
- Визначені asset, network, destination, amount, velocity і approval policies.
- Transaction requests вимагають idempotency keys.
- WebSocket events підключені для deposits, sends, failures і confirmations.
- Ledger records перевірені з finance або operations до production funds.
Якщо чогось із цього немає, проблема не в тому, що агент занадто слабкий. Проблема в тому, що control boundary ще не готова.
FAQ
Чи може AI-агент створити MPC-гаманець?
Так. AI-агент може провести setup і викликати wallet infrastructure через approved tools і scoped API access. Він не має генерувати або тримати приватний ключ гаманця в prompt.
Чи потрібен агенту приватний ключ?
Ні. Агенту потрібні контрольовані permissions для запиту wallet actions. Signing authority має залишатися в MPC і Co-Signer infrastructure поза model context.
Чим API key відрізняється від wallet private key?
API key автентифікує request до infrastructure. Wallet private key або MPC share бере участь у signing transactions. Це різні security layers.
Навіщо AI-агентам Co-Signer?
Co-Signer enforce-ить policy до того, як transaction буде підписана. Він може перевірити limits, destinations, assets, velocity і approval rules, навіть якщо модель хоче рухатися далі.
Чи можна спочатку зробити це на testnet?
Так. Безпечніший шлях - створити testnet wallet, запустити Co-Signer, пройти MPC/DKG readiness, протестувати receive і send flows і тільки потім обговорювати production settings.
Що команда має моніторити після запуску?
Моніторте transaction intents, Co-Signer decisions, signed requests, broadcasts, confirmations, failures, balances і ledger records. AI wallet operations не мають перетворюватися на black box.