Перелік перевірок безпеки AI-гаманця є умовою запуску
Перелік перевірок безпеки AI-гаманця має відповісти на одне запитання до того, як агент зможе переміщувати цінність: що зупинить формально правильну, але небезпечну транзакцію? Створити адресу легко. Готовність до запуску потребує ізольованих секретів, обмежених прав, правил Co-Signer, лімітів, аварійної паузи й доказів для звірки.
Ворогом є необмежена автономність. Модель може сформувати намір транзакції, але секрети, схвалення, підписання й облік мають належати окремим системам.
Коротка відповідь
До запуску тримайте приватні ключі, приватні API-ключі, матеріали шифрування та частки MPC поза контекстом моделі. Надайте агенту ідентичність з обмеженими правами, вимагайте ідемпотентні підписані запити, застосовуйте ліміти суми й список дозволених адрес через Co-Signer під контролем клієнта, під'єднайте WebSocket-події та операційний журнал і перевірте аварійну паузу. Дозволяйте реальні кошти лише після успішної перевірки відхилених, дубльованих, затриманих і перерваних транзакцій.
Матриця контролю перед запуском
Використовуйте цю матрицю як приймальну перевірку.
| Механізм контролю | Доказ, потрібний до запуску | Який збій обмежує |
|---|---|---|
| Ізоляція секретів | Приватний ключ, частка MPC, ключ шифрування, підписана адреса подій або довгострокові облікові дані не з'являються в запитах до моделі, журналах чи Git | Викрадення облікових даних і незворотне розкриття ключа |
| Обмежена ідентичність | Окремі Ed25519 API-ключі для Co-Signer та інтеграції з мінімальними правами | Отримання широких повноважень через один скомпрометований процес |
| Правила Co-Signer | Транзакція поза локальними правилами відхиляється до підписання | Перетворення наміру моделі на одноосібне право підпису |
| Правила адрес | Перевіряються дозволена адреса, мережа, актив, стандарт токена та обов'язкова примітка | Відправлення коштів на неправильну або непідтримувану адресу |
| Ліміти суми й частоти | Граничні значення однієї транзакції, дня та короткого періоду перевірені | Надмірні витрати й швидка автоматизована втрата |
| Аварійна пауза | Визначений оператор може зупинити нові відправлення без видалення доказів | Продовження руху коштів під час інциденту |
| Ідемпотентність | Повтор запиту після тайм-ауту з тим самим ключем не створює дубль | Подвійні платежі під час відновлення |
| Видимість подій | Стани створення, відхилення, підписання, відправлення в мережу, підтвердження й помилки доступні для спостереження | Невидимі збої та хибні баланси клієнтів |
| Журнал і аудит | Кожна зміна балансу пов'язана з учасником, гаманцем, операцією, результатом правил і зовнішнім посиланням | Незрозумілі рухи під час звірки |
1. Тримайте секрети поза контекстом моделі
Моделі не потрібні приватні ключі гаманців, фрази відновлення, частки MPC, матеріали шифрування Co-Signer або приватні API-ключі. Їй потрібні структуровані можливості: створити гаманець у дозволеному рахунку, прочитати схвалений баланс, запропонувати транзакцію або отримати стан. Підписаний запит виконує захищене середовище.
Рекомендації OWASP щодо керування секретами радять деталізований доступ, мінімальні права, ротацію, відкликання та захист секретів від потрапляння в журнали. Застосуйте цей життєвий цикл до кожної ідентичності агента.
Використовуйте різні секрети для розробки, тестових мереж і робочих процесів. Якщо секрет потрапив у запит до моделі, стенограму, задачу чи репозиторій, вважайте його розкритим і змініть.
2. Розділіть ідентичності та застосовуйте мінімальні права
Co-Signer і прикладна інтеграція виконують різні завдання, тому не мають використовувати одну API-ідентичність. Кожній потрібні лише права її робочого процесу.
Якщо інтеграцію скомпрометовано, команда може вимкнути її без заміни матеріалів підписання Co-Signer. Розташування в мережі саме по собі не є дозволом: автентифікуйте службу, обмежуйте права, перевіряйте актуальність запиту й застосовуйте правила до руху коштів. Дотримуйтеся посібника з автентифікації BroSettlement для підписаних запитів, часових позначок, nonce і захисту від повторного відтворення.
3. Поставте Co-Signer між наміром і підписанням
Агент може вирішити, що рахунок постачальника треба оплатити. Він не повинен одноосібно вирішувати, що криптографічний підпис дозволено створити. Co-Signer під контролем клієнта є межею між цими двома твердженнями.
Порогова криптографія розподіляє довіру між учасниками замість опори на один повний ключ. NIST описує багатосторонні порогові схеми як застосування захищених багатосторонніх обчислень до підписів і генерації ключів. В архітектурі BroSettlement 2-з-3 звичайне підписання потребує співпраці без відновлення повного приватного ключа.
Криптографія не визначає бізнес-правила. Co-Signer потребує точних умов для активів, мереж, адрес, сум і порогів ручної перевірки. Прочитайте посібник із Co-Signer та перевіряйте відхилення так само ретельно, як схвалення.
4. Визначте правила транзакцій до автоматизації
Запишіть правила так, щоб вони давали однозначну відповідь. «Сплачувати обґрунтовані рахунки» — не механізм контролю. «USDT у TRON, лише дозволені адреси, у межах лімітів транзакції та дня, з ручною перевіркою понад поріг» — умова, яку можна перевірити.
| Рішення за правилами | Автоматичний результат | Які докази зберігати |
|---|---|---|
| Адреси немає у списку дозволених | Відхилити | Адреса, мережа, версія правил, причина відхилення |
| Сума перевищує ліміт транзакції | Відхилити або вимагати перевірки | Запитана сума, поріг, рішення перевіряльника |
| Денний бюджет буде перевищено | Призупинити | Поточна сума, запитана сума, бюджетний період |
| Актив або мережа не відповідає маршруту | Відхилити | Запитані й дозволені параметри маршруту |
| Потрібна примітка або тег адреси відсутні | Відхилити | Результат перевірки без розкриття секретів |
| Ризик або питання відповідності не вирішене | Призупинити | Посилання на справу й відповідальний учасник |
Агент має отримувати обмежений результат: схвалено, відхилено або потрібна перевірка. Він не повинен змінювати правила, підвищувати ліміт або схвалювати власний виняток.
5. Зробіть аварійну паузу робочою
Аварійна пауза — це перевірена процедура з визначеним відповідальним, областю дії та збереженими доказами. Вона може поєднувати контроль застосунку, відкликання API-ключа, правила Co-Signer і ручне схвалення. Пауза має зупиняти нові відправлення без стирання операцій або історії журналу. Перевірте її в тестовій мережі, відновіть роботу та звірте кожну зміну стану.
6. Зробіть кожну зміну стану видимою
WebSocket-події дають швидку видимість, але не є джерелом облікової істини. Споживачі мають витримувати дублікати, безпечно повторно під'єднуватися й отримувати актуальний стан до зміни балансу клієнта.
Щонайменше розрізняйте такі етапи:
- агент створив намір;
- пройшли перевірки автентифікації та правил;
- Co-Signer схвалив або відхилив запит;
- MPC-підписання завершилося або зазнало помилки;
- транзакцію відправлено в блокчейн-мережу;
- мережа підтвердила, відхилила або замінила її;
- операційний журнал відобразив відповідну зміну балансу.
Використовуйте WebSocket-події для видимості, а операційний журнал — для впливу на баланс. Зберігайте ідентичність агента, версію правил, ключ ідемпотентності, ID гаманця, ID операції та зовнішнє посилання на транзакцію.
7. Перевірте повтори запитів і сценарії збоїв
До запуску перевірте ситуації, що найчастіше створюють фінансову невизначеність:
- API прийняв запит, але клієнт отримав тайм-аут;
- той самий ключ ідемпотентності надіслано повторно;
- Co-Signer недоступний;
- мережева комісія змінилася або балансу вже недостатньо;
- адреса не пройшла перевірку за списком дозволених;
- WebSocket повторно доставив подію або під'єднався після розриву;
- транзакція довше очікуваного не досягає кінцевого стану;
- операційний журнал і внутрішній баланс продукту не збігаються.
Тайм-аут не дозволяє створювати новий ключ ідемпотентності. Отримайте наявну операцію й продовжуйте з її поточного стану. Посібник із тестового гаманця показує, як перевірити отримання й відправлення до залучення реальних коштів.
8. Залучіть фінансову команду та команду з відповідності
Фінансовій команді недостатньо хешу блокчейн-транзакції. Кожен рух має поєднувати агента, бізнес-мету, вихідний гаманець, адресу отримувача, актив, суму, комісію, результат правил, схвалювача, записи журналу та кінцевий стан у мережі. Звірка має порівнювати баланси продукту, записи BroSettlement і дані блокчейну через стабільні ідентифікатори.
MPC і контроль Co-Signer не замінюють KYC/KYB, AML-рішення, Travel Rule, аналіз ліцензування, санкційні перевірки чи оцінювання юрисдикції. Призупинена транзакція потребує відповідального й історії вирішення.
Експортуйте докази за політикою зберігання вашої організації. Audit Logs API BroSettlement дає змогу фільтрувати активність організації за джерелом, дією, учасником, об'єктом, IP і часом. Доступність API не замінює обов'язків клієнта щодо зберігання, перегляду й контролю доступу до доказів.
Як BroSettlement підтримує межу контролю
BroSettlement поєднує вбудовані MPC-гаманці, Co-Signer під контролем клієнта, підписані API-запити, події, операційний журнал із послідовним додаванням записів та аудит. BroLabel AI Agents дає агенту змогу працювати без доступу до секретів підписання.
Практичний наступний крок — установити й перевірити BroSettlement Agent Skills, пройти весь перелік у тестовій мережі та зберегти докази для кожного успіху й відмови. Не переходьте до реальних коштів лише тому, що гаманець створено. Переходьте, коли правила, пауза, відновлення подій і звірка теж працюють. Bro has your back!
Перелік перевірок перед запуском
- Секрети: приватні ключі, частки MPC, матеріали шифрування та підписані адреси подій не потрапляють у контекст моделі.
- Ідентичність: Co-Signer та інтеграція розділені й мають мінімальні права.
- Правила: адреси, активи, мережі, суми, частота та ручна перевірка визначені явно.
- Розділення: агент не може змінити правила й схвалити власний виняток.
- Пауза: аварійний контроль має відповідального, область дії, шлях відновлення й докази.
- Повтори: той самий ключ ідемпотентності не створює подвійних платежів.
- Події: повторне під'єднання й дублікати обробляються безпечно.
- Журнал: записи звіряються з балансами продукту та посиланнями на блокчейн.
- Докази: експорт аудиту й зберігання мають визначених відповідальних.
- Обов'язки: KYC/KYB, AML, Travel Rule, ліцензування й санкційні перевірки задокументовані.
FAQ
Чи може AI-агент зберігати приватний ключ гаманця?
Не повинен. Агент може створювати намір транзакції, а приватні ключі, частки MPC і приватні API-ключі мають залишатися в захищеному середовищі поза контекстом моделі.
Чи достатньо MPC для захисту AI-гаманця?
Ні. Запуск також потребує обмежених ідентичностей, правил Co-Signer, лімітів, списку дозволених адрес, ідемпотентності, спостереження, звірки, відновлення та інцидентних процедур.
Що має зупиняти аварійна пауза?
Визначте область: один агент, гаманець, API-ідентичність, актив, маршрут або всі вихідні транзакції. Збережіть очікувані стани та аудиторські докази.
Як обробляти дубльовані запити транзакцій?
Повторно використайте початковий ключ ідемпотентності, отримайте наявну операцію й продовжуйте з її поточного стану. Не створюйте новий ключ лише тому, що перша відповідь не надійшла вчасно.
Коли AI-гаманець готовий до реальних коштів?
Лише коли докази з тестової мережі охоплюють схвалення, відхилення, ліміти, паузу, повтори, відновлення подій, записи журналу, звірку й відповідальність за інциденти. Створення адреси не є перевіркою готовності.
