Кошелек для 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 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.

Даже полностью скомпрометированный агент не должен иметь возможность вывести больше, чем вы заранее выделили для его работы. В этом и заключается главный принцип: система должна быть устроена так, чтобы ошибка агента имела предел. Доступ к вашим средствам должен оставаться там, куда не может добраться ни агент, ни тот, кто попытается им воспользоваться.