Co-Signer є межею контролю
Co-Signer для AI-агентів - це не просто ще один сервіс у системі гаманця. Для команд, які дозволяють AI-агентам створювати гаманці, готувати виплати або допомагати з операціями казначейства, Co-Signer є межею між корисною автономністю та необмеженим правом підписання.
Агент може читати контекст, готувати намір транзакції, пояснювати відмову або пропонувати наступну дію. Він не має зберігати приватні ключі, частки MPC, приватні API-ключі, файли відновлення або необмежений дозвіл рухати кошти. Така межа має жити в інфраструктурі, а не в запиті до моделі.
У BroLabel AI-агентах цей підхід з'єднує агентський шар із BroSettlement та Agent Skills. Агент може супроводжувати налаштування й ініціювати структуровані запити. Розгорнутий у клієнта Co-Signer перевіряє правила до підписання через MPC, а операційний журнал фіксує, що було схвалено, відхилено, відправлено в мережу, підтверджено або завершилося помилкою.
Коротка відповідь
AI-агент може допомагати керувати гаманцем, але саме Co-Signer має вирішувати, чи дозволено підписати транзакцію. Безпечна архітектура залишає модель у шарі намірів і видимості, а розгорнута в клієнта інфраструктура застосовує ліміти, правила для адрес отримувачів, пороги схвалення, аварійну зупинку та підписання через MPC. Агент пропонує; Co-Signer контролює.
Чому автономності потрібна окрема межа підписання
Автономність агента виглядає просто, коли дія має низький ризик: прочитати баланс, створити звіт, знайти інвойс або підготувати відповідь для підтримки. Рух коштів - інша історія. Успішна помилкова дія може стати незворотною транзакцією.
Саме тому архітектура AI-гаманця має відповідати на два різні питання:
- Що агенту дозволено запитувати? Це модель прав агента.
- Що системі дозволено підписувати? Це модель правил і Co-Signer.
Ці питання не можна зводити до одного дозволу. Якщо агент може створити запит на виплату, це не означає, що він може підписати кожну виплату. Якщо оператор просить термінове виведення, це не означає, що транзакція може обійти ліміти, список дозволених адрес, ідемпотентність або ручну перевірку.
Co-Signer створює стійку точку контролю поза контекстом моделі. Навіть якщо запит помилковий, неповний або навмисно маніпулятивний, шар підписання все одно має оцінити структуровані дані.
Що вирішує агент, а що застосовує Co-Signer
Найзрозуміліший спосіб спроєктувати процес - розділити відповідальність.
| Шар | Що може робити | Чого не має робити |
|---|---|---|
| AI-агент | Розуміти запит, збирати контекст, готувати намір гаманця або транзакції, пояснювати статус | Зберігати секрети гаманця або самостійно ухвалювати остаточне підписання |
| API-шар | Автентифікувати автоматизацію з обмеженими правами, перевіряти форму запиту, забезпечувати ідемпотентність | Вважати підписаний запит автоматичним дозволом витрачати кошти |
| Шар правил | Перевіряти суму, актив, мережу, роль, адресу отримувача, швидкість операцій і стан ризику | Покладатися лише на природномовну інструкцію як на джерело істини |
| Co-Signer | Схвалювати, відхиляти або відправляти на ручну перевірку до підписання через MPC | Бути постійно відкритим для необмежених команд агента |
| Шар MPC-гаманця | Створювати підписи без збирання приватного ключа в одному місці | Розкривати частки MPC агенту |
| Операційний журнал і події | Фіксувати зміни стану й публікувати події WebSocket | Залишати фінансову команду або підтримку без відстежуваного статусу |
Саме такий поділ робить гаманець придатним для роботи з агентом, але не перетворює агента на шар зберігання активів.
Як це працює
Контрольований процес для AI-гаманця зазвичай виглядає так:
- Користувач, продуктовий робочий процес або операційна система ставить агенту задачу.
- Агент визначає бізнес-контекст: рахунок, гаманець, актив, мережу, суму, адресу отримувача та причину.
- Агент створює структурований намір замість сирої транзакції.
- API-запит підписується Ed25519 API-ключем з обмеженими правами.
- BroSettlement перевіряє форму запиту, ідемпотентність, баланс і належність гаманця.
- Шар правил оцінює ліміти, список дозволених адрес, швидкість операцій, ролі, стан ризику та пороги ручної перевірки.
- Розгорнутий у клієнта Co-Signer схвалює, відхиляє або ставить запит на ручну перевірку.
- Підписання через MPC створює дійсний підпис транзакції без розкриття приватного ключа моделі.
- Якщо запит схвалено, транзакція відправляється в мережу.
- Події WebSocket та записи в операційному журналі оновлюють продуктову команду, підтримку, операції та фінанси.
Важливо не те, що кожен крок складний. Важливо, що кожен крок явний. Агент не має спиратися на нечітку інструкцію на кшталт "можеш витрачати скільки розумно". "Розумно" має стати правилом.
Перелік перевірок для правил Co-Signer
Перед тим як AI-агент отримає можливість запитувати відправлення коштів, Co-Signer має мати чітку модель рішення.
| Контроль | Питання | Приклад правила |
|---|---|---|
| Обсяг гаманців | Яких гаманців може торкатися цей агент? | Лише гаманці одного продукту, бренду або профілю казначейства |
| Обсяг активів | Які активи дозволені? | Тільки USDT і USDC або тільки тестові активи під час підключення |
| Обсяг мереж | Які мережі дозволені? | Дозволити TRON або EVM лише після операційної готовності |
| Ліміт суми | Скільки можна відправити за одну дію? | Відхилити суму понад ліміт або вимагати ручну перевірку |
| Ліміт швидкості операцій | Скільки можна відправити за годину, день або тиждень? | Призупинити, якщо сукупні витрати перетнули поріг |
| Правило адреси отримувача | Куди можуть піти кошти? | Для автоматичного схвалення потрібен список дозволених адрес |
| Правило ролі | Хто або що може ініціювати запит? | Розділити права підтримки, фінансів і автоматизації |
| Ідемпотентність | Чи це повторна дія? | Одна операційна підстава не може створити кілька виплат |
| Операційна підстава | Чому рухаються кошти? | Потрібен інвойс, запит на виведення, ID кейсу або інструкція казначейства |
| Аварійна зупинка | Чи можна швидко зупинити процес? | Відхиляти всі нові запити на підписання, поки зупинка активна |
Цей перелік варто налаштувати до того, як агент отримає будь-яку можливість відправляти кошти. Консервативне правило легше послабити пізніше, ніж пояснювати транзакцію, яку не мали підписувати.
Що ніколи не має потрапляти в контекст моделі
Модель не має ставати сховищем секретів. Не розміщуйте ці матеріали в запиті, історії чату, результатах інструментів, журналах або файлах, які агент може читати:
- приватні ключі або seed-фрази;
- приватні API-ключі;
- ключі шифрування;
- частки MPC;
- постійне сховище Co-Signer;
- файли відновлення;
- облікові дані адміністратора;
- необмежені дані експорту гаманця;
- змінні середовища із секретами.
Агент може працювати з діями з обмеженими правами та видимими станами: створити намір, прочитати результат перевірки правил, перевірити статус транзакції, підписатися на події WebSocket або підсумувати записи операційного журналу. Йому не потрібні самі матеріали підписання.
Ручна перевірка - це продуктова функція, а не трюк у запиті
Деякі команди намагаються обробляти ризикові дії інструкцією для моделі: "запитай людину, якщо не впевнений". Цього недостатньо. Ручна перевірка має бути реальним станом у процесі транзакції.
Екран перевірки або операційна черга мають показувати:
- гаманець і рахунок;
- актив, мережу та суму;
- адресу отримувача;
- операційну підставу;
- агента або користувача, який ініціював намір;
- результат правил і причину ризику;
- попередні спроби з тим самим ключем ідемпотентності;
- дії схвалення, відхилення та призупинення.
Це важливо для підтримки та фінансів. Якщо виплата затримується, команда має знати, чи вона чекає перевірки правил, схвалення Co-Signer, відправлення в мережу, підтверджень або обробки помилки. Події WebSocket і записи в операційному журналі роблять ці стани видимими.
Як тут підходить BroSettlement
BroSettlement підходить командам, яким потрібна автономність гаманців разом з інфраструктурними контролями. Це не кнопка розміщеного платіжного екрану. Це інфраструктура гаманців, операційного журналу та розрахунків з API-доступом для продуктів, яким потрібно створювати гаманці, отримувати кошти, відправляти транзакції та зберігати операційні записи у власному продуктовому досвіді.
Для сценаріїв з AI-агентами BroSettlement дає агенту безпечнішу робочу поверхню:
- Agent Skills для супроводу налаштування та API-операцій;
- Ed25519 API-ключі з обмеженими правами для ідентичності автоматизації;
- розгорнутий у клієнта Co-Signer для контролю підписання;
- підписання через MPC без сирих приватних ключів у запитах;
- правила для суми, адреси отримувача, ролі та швидкості операцій;
- ідемпотентні запити транзакцій;
- події WebSocket для стану в реальному часі;
- записи операційного журналу для аудиту та звірки.
Ця інфраструктура все одно потребує чітких операційних правил від команди. BroSettlement не знімає вимоги KYC/KYB, AML, Travel Rule, ліцензування або юрисдикційні обов'язки. Він дає команді контрольований шар, де ці обов'язки можна застосовувати, а не імпровізувати в запиті до моделі.
Як почати
Перед тим як давати AI-агенту повноваження працювати з гаманцем, опишіть один вузький процес:
- виберіть сценарій тестового гаманця;
- визначте, який агент може запитувати дію;
- створіть доступ до API з обмеженими правами;
- запустіть Co-Signer поза контекстом моделі;
- задайте правила для суми, адреси отримувача, швидкості операцій і ручної перевірки;
- вимагайте ключ ідемпотентності та операційну підставу;
- слухайте події WebSocket;
- перевірте записи операційного журналу з фінансами або операційною командою.
Якщо перший процес не можна пояснити в таблиці, ще рано автоматизувати його агентом.
FAQ
Що таке Co-Signer для AI-агента?
Co-Signer для AI-агента - це контрольований клієнтом компонент підписання, який перевіряє правила перед підписанням транзакції гаманця. Він дозволяє агенту запитувати дію без передачі моделі приватних ключів або необмеженого права підписання.
Чи може AI-агент сам схвалювати свою транзакцію?
Для низькоризикових дій агент може створити намір, який автоматично схвалять заздалегідь визначені правила. Але схвалення має йти від інфраструктурних правил, а не від рішення моделі, що її власний запит безпечний.
Чи замінює Co-Signer MPC?
Ні. Co-Signer є частиною моделі контролю підписання. MPC - це криптографічний підхід до підписання, який не збирає приватний ключ в одному місці. Для агентських гаманців вони працюють разом.
Де має працювати Co-Signer?
Co-Signer має працювати в інфраструктурі під контролем клієнта, поза контекстом моделі та поза запитом агента. Так клієнт може застосовувати власні правила підписання й операційні контролі.
Що має запускати ручну перевірку?
Ручну перевірку варто вмикати для нових адрес отримувача, великих сум, незвичної швидкості операцій, відсутньої операційної підстави, зміненого стану ризику, неповних даних відповідності вимогам або будь-чого поза звичайним профілем правил.
Як команда перевіряє дії AI-гаманця?
Продукт має використовувати записи операційного журналу та події WebSocket, щоб відстежувати створення наміру, перевірку правил, схвалення, підписання, відправлення в мережу, підтвердження, відхилення та помилки.