Гаманець для AI-агента: як безпечно дати доступ до крипти

Гаманець для AI-агента потрібен для автономних дій: оплати API, ончейн-операцій, ребалансування та переказів стейблкоїнів за заданими правилами. Але головне питання — якими саме коштами агент може розпоряджатися і що обмежить збиток, якщо він помилиться або буде скомпрометований.

У цій статті розберемо, чому основний гаманець має залишатися поза зоною доступу агента. Кейси Freysa, Grok/Bankrbot, дослідження атак на пам’ять агентів і шкідливих LLM-роутерів показують, що самої криптографії недостатньо, якщо системі дали надто широкі повноваження. Далі — як відокремити операційний гаманець від основного, де виставляти ліміти і яку роль тут відіграють апаратні гаманці, session keys — тимчасові ключі з обмеженими правами — та смартконтрактні акаунти.

Гаманець для AI-агента: що означає «дати доступ»

Звичайний криптогаманець побудований навколо людини. Є інтерфейс, seed-фраза для відновлення, адреса отримувача, сума і фінальне підтвердження. Перед підписом ви можете зупинитися, перевірити дані на екрані апаратного гаманця і відхилити підозрілу транзакцію.

Гаманець агента працює інакше. Для автономної роботи потрібен механізм, який може підписувати транзакції без ручного підтвердження кожної дії. 11 лютого 2026 року Coinbase представила Agentic Wallets — інфраструктуру, створену для автономних агентів із програмованими обмеженнями. Паралельно розвивається x402 — відкритий платіжний протокол, який використовує HTTP 402 Payment Required: агент звертається до API, отримує умови оплати, підписує платіж і повторює запит вже з підтвердженням.

Звідки взялася ця потреба

Частину ончейн-активності вже виконують автоматизовані системи. У дослідженні DWF Labs за 2026 рік наводиться оцінка, що автоматизована й агентська активність становить понад 19% усієї ончейн-активності, а боти генерують понад 76% обсягу переказів стейблкоїнів. Це оцінки дослідників, а не точна частка всього ринку, проте напрям зрозумілий: програми дедалі частіше не лише аналізують дані, а й самі ініціюють фінансові дії.

Для таких платежів особливо зручні стейблкоїни. Агенту, який оплачує десятки або сотні невеликих запитів, потрібна передбачувана одиниця розрахунку: якщо API коштує один цент, платіж не повинен залежати від волатильності ETH чи іншого активу. У x402 основним прикладом тривалий час був USDC, а в березні 2026 року протокол розширив підтримку на інші ERC-20 токени. В EVM-середовищі для таких сценаріїв часто використовують L2-мережі, зокрема Base.

Чим гаманець агента відрізняється від вашого

Ключова різниця — в моделі контролю. У звичайному сценарії останній крок залишається за користувачем. Навіть якщо сайт сформував ризиковану транзакцію, її ще потрібно підтвердити. В агентському сценарії ручне підтвердження частково або повністю прибирають навмисно, інакше агент не буде автономним.

Тому безпека зміщується з моменту підпису на момент налаштування правил. Якщо агент має необмежений ключ, помилка моделі, шкідливі зовнішні дані або скомпрометований сервіс можуть відкрити шлях до всього балансу. Якщо права вузькі, максимальний збиток обмежується наперед заданими умовами.

Чому мовна модель не повинна контролювати підпис без обмежень

Системні правила, команда користувача і зовнішні дані можуть бути позначені різними ролями, але мовна модель усе одно обробляє їх у спільному контексті. Це не створює криптографічно жорсткої межі між «надійною інструкцією» та «недовіреним контентом». Саме тому дані із сайту, документа, Discord або X можуть впливати на подальше рішення агента.

На цьому побудована prompt injection. Зловмисник додає інструкцію туди, де агент очікує побачити звичайні дані, а модель може сприйняти її як частину завдання. У криптовалюті наслідки особливо серйозні: після підтвердження ончейн-транзакцію не можна просто відкликати кнопкою «скасувати». Тому заборона в системному промпті корисна, але не може бути єдиним захистом.

Freysa: одна заборона, якої виявилося недостатньо

Freysa стала показовим прикладом. У листопаді 2024 року на Base запустили гру, в якій учасники платили за повідомлення агенту й намагалися змусити його віддати призовий фонд. Головне правило Freysa було простим: не переказувати кошти. Кожна невдала спроба збільшувала фонд.

Після 481 невдалої спроби користувач p0pular.eth змінив контекст, у якому агент інтерпретував власні інструменти. Він представив approveTransfer як дію для вхідного поповнення, а потім написав, що хоче внести кошти до казни. На 482-й спробі Freysa викликала дозволену їй функцію і переказала весь фонд — 13,19 ETH, приблизно $47 000 на той момент.

Контракт не зламували, seed-фразу не викрадали. Агент сам викликав доступну йому дію, бо неправильно зрозумів контекст. Цей кейс добре показує, чому автономному агенту потрібні зовнішні технічні обмеження, які він не може змінити власним рішенням.

Непряма prompt injection: атака через дані, які агент читає

Freysa отримала інструкцію безпосередньо від користувача. Непряма prompt injection працює інакше: шкідлива команда ховається в даних, які агент читає під час роботи. Це може бути відповідь у соцмережі, текст на сайті, коментар у документі, метадані або закодований фрагмент. Для людини це контент; для агента він може стати частиною інструкції.

У травні 2026 року такий сценарій проявився у зв’язці Grok і Bankr. Спочатку зловмисник надіслав у гаманець, який Bankr автоматично пов’язував з акаунтом Grok у X, спеціальний membership NFT, що розширював дозволи. Потім він попросив Grok перекласти рядок, закодований азбукою Морзе. Після декодування Grok опублікував текстову команду з тегом Bankrbot, а Bankrbot сприйняв її як достатню авторизацію і виконав переказ.

У результаті з гаманця вийшло близько 3 млрд DRB. Оцінка вартості в різних джерелах коливалася приблизно від $150 000 до $200 000 через різку зміну ціни токена; близько 80–88% коштів згодом повернули через переговори. Важливий тут не формат Морзе, а сама архітектура: текст, який згенерувала одна модель, став фінансовою командою для іншої системи без незалежної перевірки наміру.

Memory injection: підміна пам’яті агента

Окремий ризик — пам’ять агента. Дослідники з Princeton University і Sentient Foundation показали це на ElizaOS, відкритому фреймворку для Web3-агентів. Агент зберігає історію взаємодій і використовує її як контекст для майбутніх рішень. Якщо зловмисник може записати туди шкідливу або фальшиву інструкцію, агент пізніше може сприйняти її як частину справжньої історії.

У такій схемі навіть легітимна команда користувача може виконатися не так, як очікувалося. У дослідах із ElizaOS отруєна пам’ять могла змінити адресу отримувача, а ін’єкція через один канал — наприклад Discord — впливала на дію, яку агент пізніше виконував через інший канал. Тобто ризик зберігається між сесіями і може поширюватися між інтеграціями одного агента.

Що вже показали інциденти й дослідження

Окремий клас ризику створюють LLM-роутери — проміжні сервіси між агентом і постачальником моделі. Вони завершують TLS-з’єднання з клієнтом і створюють нове з’єднання до моделі, тому технічно можуть бачити запити, API-ключі, визначення інструментів і відповіді відкритим текстом.

У квітні 2026 року дослідники опублікували систематичне дослідження цієї поверхні атаки. Серед 28 платних і 400 безкоштовних роутерів вони виявили сервіси, які активно підміняли вміст запитів (payload) або взаємодіяли з контрольними обліковими даними, які дослідники залишили як приманки; один із протестованих роутерів також вивів ETH із дослідницького приватного ключа. Це вже не prompt injection усередині моделі, а компрометація самого посередника між агентом і LLM.

На цьому тлі варто пам’ятати і про ширші крипторизики. За оцінкою Chainalysis, у 2025 році було викрадено понад $3,4 млрд у криптовалюті. Найбільшим окремим інцидентом став злам Bybit приблизно на $1,5 млрд; ФБР пов’язало його з північнокорейською операцією TraderTraitor. Ці атаки не були атаками на AI-агентів, але добре показують, наскільки дорого коштує компрометація інфраструктури доступу до коштів.

Для агентів висновок прямий: у разі компрометації атакувальник зможе використати ті повноваження, які вже має агент. Якщо доступ обмежений операційним бюджетом і жорсткими правилами, збиток має верхню межу. Якщо агенту дали ключ від основного гаманця, верхньою межею стає весь доступний баланс.

Що буде, якщо дати агенту ключ від основних коштів

Розглянемо типовий сценарій. Агент відстежує дохідність стейблкоїнів і переміщує USDC між Aave, Morpho та Compound. Щоб не підтверджувати кожну операцію вручну, власник додає приватний ключ основного гаманця в конфіг, змінну середовища або сховище секретів, доступне процесу агента. На перший погляд це зручно, але така архітектура прибирає межу між автоматизацією і всім капіталом користувача.

По-перше, основний приватний ключ опиняється в середовищі, де працює код агента, його залежності, MCP-сервери для підключення зовнішніх інструментів, логування та сторонні API. Компрометація будь-якої ланки може дати доступ до секрету. По-друге, якщо зовнішніх обмежень немає, агент технічно може підписати транзакцію на будь-яку доступну суму і будь-яку адресу.

По-третє, підтверджену блокчейн-транзакцію не можна просто скасувати. У деяких випадках біржі або емітенти окремих активів можуть заморозити кошти, а правоохоронці — допомогти з розслідуванням, але це не механізм відновлення самого self-custody гаманця. Якщо ключ підписав виведення активів, гарантованого способу повернути їх немає.

Найважливіше — втрачається холодний контур. Поки основний ключ залишається в апаратному гаманці, підпис створюється на самому пристрої, а приватний ключ не повинен залишати його захищене середовище. Якщо той самий seed або приватний ключ експортувати в середовище агента, цей гаманець більше не можна вважати холодним.

Як правильно: операційний гаманець окремо від основного

Безпечніша схема починається з поділу коштів. Основний капітал залишається в холодному зберіганні, до якого агент не має прямого доступу. Для роботи створюється окремий операційний гаманець з іншим приватним ключем або смартконтрактний акаунт із чіткими правилами. На ньому лежить тільки сума, потрібна для роботи в межах прийнятного ризику.

Принцип найменших привілеїв

Принцип найменших привілеїв тут дуже практичний: агент має отримати тільки ті права і той бюджет, які потрібні для конкретного завдання. Якщо він оплачує API на кілька доларів на день, йому не потрібен доступ до всього портфеля. Якщо він ребалансує позицію на $500, у нього не повинно бути технічної можливості витратити $5 000.

Сприймайте агента як зовнішнього автоматизованого виконавця з доступом до грошей. Йому можна дати робочий бюджет, журнал дій і обмежені повноваження. Ключ від основного сховища до цього набору не належить. Навіть якщо агент працює коректно сьогодні, завтра він може прочитати шкідливі дані, отримати отруєну пам’ять або пройти через скомпрометований сервіс.

Холодний гаманець як корінь довіри

Апаратний гаманець у такій архітектурі може бути коренем довіри: саме ним власник підтверджує створення, зміну або відкликання прав для агента. Замість передачі основного приватного ключа агенту видається окремий дозвіл: що саме дозволено, на яку суму, для яких адрес або контрактів і до якого часу.

На цьому побудована логіка session keys і smart accounts. Основний ключ залишається поза середовищем агента, а агент підписує дії окремим сесійним ключем або через інший обмежений механізм. Якщо такий доступ скомпрометують, атакувальник упирається в параметри сесії: суму, список дозволених адрес, строк дії та можливість відкликання.

Скільки давати агенту на операційний гаманець

Універсальної суми немає. Практичний підхід — тримати на операційному балансі стільки, скільки потрібно для кількох днів нормальної роботи агента, а не весь запас коштів. Порахуйте добові витрати на gas, API, комісії та цільові операції. Потім додайте невеликий запас на короткий період, втрату якого ви готові прийняти без критичних наслідків.

Поповнюйте операційний гаманець вручну або за розкладом невеликими сумами. Один великий переказ «щоб надовго вистачило» поступово перетворює робочий гаманець на другий основний. Малий баланс із регулярним поповненням — це простий грошовий ліміт ризику.

Технічні обмеження

Окремий гаманець обмежує ризик балансом. Ще сильніший захист дають правила, які не залежать від того, що «вирішила» модель. Ліміт лише в коді застосунку може бути реалізований неправильно або обійдений через компрометацію цього рівня. Ліміт у смартконтракті перевіряється під час виконання операції і не змінюється від тексту в промпті.

Для цього використовують смартконтрактні гаманці та account abstraction — підхід, за якого правила перевірки операцій можна реалізувати в логіці акаунта. EntryPoint для ERC-4337 був розгорнутий в Ethereum mainnet 1 березня 2023 року; сам ERC-4337 сьогодні має статус Final. Така архітектура дозволяє задавати правила, які виконуються незалежно від рішення мовної моделі.

• Ліміт на одну транзакцію — максимальна сума одного переказу або однієї дії.
• Денний або тижневий ліміт — сукупна стеля витрат за період, щоб атаку не можна було розтягнути на багато дрібних списань.
• Список дозволених адрес і контрактів — агент може взаємодіяти лише з наперед визначеними отримувачами та протоколами.
• Термін дії сесії (TTL) — дозвіл автоматично перестає працювати після заданого часу.
• Швидке відкликання — кореневий власник може анулювати дозвіл агента без переміщення основних коштів.

Session keys поєднують ці правила в окремому тимчасовому доступі. Агент підписує дії не кореневим ключем, а сесійним, який діє лише в заданих межах. Конкретна реалізація залежить від гаманця або смартконтракту: перевірятися можуть сума, адреса, тип дії, час, токен та залишок ліміту.

Поряд із ERC-4337 розвиваються окремі механізми делегування. ERC-7715 і ERC-7710 станом на вересень 2026 року залишаються Draft. ERC-7715 пропонує стандартний спосіб запитувати у гаманця обмежені дозволи на виконання дій, а ERC-7710 описує інтерфейс делегування можливостей між смартконтрактами та акаунтами.

EIP-7702, активований разом з оновленням Pectra 7 травня 2025 року, дозволяє EOA делегувати виконання логіці смартконтракту. Це відкриває можливості для пакетних транзакцій (batching), оплати gas третьою стороною (gas sponsorship) і обмежених sub-keys, якщо делегований код реалізує відповідні правила. Сам EIP-7702 не є готовою системою дозволів — безпека залежить від контракту, якому делегує акаунт.

У готових продуктах подібна модель вже з’являється як набір запобіжників. У Coinbase Agentic Wallets можна задавати ліміти на сесію та окрему транзакцію, а приватні ключі не передаються в промпт або LLM. Конкретна реалізація може відрізнятися — Coinbase, Safe, ZeroDev, MetaMask Smart Accounts або власний контракт, — але принцип один: агент отримує обмежений дозвіл, а не універсальний ключ від усіх коштів.

Як безпечно під’єднати агента

Практична схема виглядає так. Кожен крок зменшує окремий клас ризику: витік ключа, помилковий переказ, prompt injection, отруєння пам’яті або компрометацію стороннього сервісу.

1. Створіть окремий гаманець під агента. Це має бути новий операційний гаманець з окремим приватним ключем або смартконтрактний акаунт. Не використовуйте той самий seed чи приватний ключ, що захищає основний капітал.
2. Залиште основні кошти в апаратному гаманці. Він може бути коренем довіри для підпису дозволів, але його seed-фраза й приватний ключ не повинні потрапляти в середовище агента.
3. Налаштуйте ліміти на технічному рівні. Базовий набір: ліміт на одну транзакцію, денна або тижнева стеля, список дозволених адрес і контрактів, термін дії сесії.
4. Поповнюйте операційний гаманець малими порціями. Орієнтир — бюджет на короткий період роботи, а не запас «на місяць наперед».
5. Ізолюйте ключі та середовище виконання. Не зберігайте приватні ключі в промптах, документах, відкритих конфігах або логах. Використовуйте сховище секретів, окремого системного користувача, контейнер або іншу ізоляцію залежно від вашої інфраструктури.
6. Увімкніть моніторинг і підготуйте відкликання доступу. Логи транзакцій, сповіщення про нетипову активність і швидкий спосіб анулювати дозвіл мають бути налаштовані до запуску агента.

Інструкції для самого агента теж потрібні, але це додатковий шар. У системному промпті можна прямо заборонити виконувати фінансові команди із зовнішніх джерел, змінювати ліміти, обходити список дозволених адрес або приховувати транзакції. Фінальне обмеження має бути закріплене в гаманці, контракті або policy layer, а не лише в тексті інструкції.

Підсумок

Гаманці для AI-агентів поступово стають окремою частиною криптоінфраструктури. Це не означає, що агенту потрібно передавати основний приватний ключ. Навпаки, автономність робить межі доступу важливішими: агент діє швидко, читає зовнішні дані і може виконувати фінансові операції без ручного підтвердження кожного кроку.

Безпечний гаманець для AI-агента — це окремий операційний контур: основний капітал залишається в холодному апаратному гаманці, а агент працює з невеликим балансом і технічно примусовими обмеженнями. Це можуть бути ліміти, список дозволених адрес, термін дії доступу, session keys або правила smart account.

Повністю скомпрометований агент не повинен мати можливості забрати більше, ніж ви заздалегідь виділили для його роботи. У цьому й полягає головний принцип: система має бути побудована так, щоб помилка агента мала межу. Ключі від основних коштів повинні залишатися там, куди не має доступу ні агент, ні той, хто спробує ним скористатися.