Безопасность агентных кошельков: как ИИ-агенты могут совершать транзакции с меньшим риском

Агентский кошелёк безопасен, когда он воспринимает AI-агента как незнакомого инициатора транзакций, а не как доверенного подписанта. Ключи изолированы от процесса принятия решений агентом, разрешения ограничены по области действия и могут быть отозваны, а каждая транзакция проверяется до подписания — это позволяет локализовать последствия действий скомпрометированного или неисправного агента.

MetaMask объясняет, что такое агентский кошелёк, в статье What is an agentic wallet?, полный жизненный цикл транзакции описан в How AI agents transact without touching your keys, а важность самостоятельного хранения активов разобрана в Why every AI agent needs a wallet. Далее речь пойдёт о снижении рисков, возникающих в ситуации, когда транзакции предлагает агент, а не человек.

Безопасны ли агентские кошельки?

Безопасность агентских кошельков зависит от того, имеет ли агент прямой доступ к приватным ключам, ограничены ли его разрешения или неограничены, а также проверяется ли транзакция до подписания, а не после. Агент, предлагающий действия изолированному кошельку с применением политик, несёт принципиально иной профиль риска, чем агент, самостоятельно хранящий ключи.

Почему агентскому кошельку нужна иная модель угроз

Кошелёк, созданный для человека, предполагает, что пользователь проверяет каждую транзакцию перед подписанием. Агентский кошелёк не может на это рассчитывать: один и тот же процесс, который считывает метаданные токена, веб-страницу или ответ API, может одновременно принимать решение о следующей подписи. Полный жизненный цикл от намерения до исполнения описан в статье How AI agents transact without touching your keys. С точки зрения безопасности важно, где именно находятся ненадёжные входные данные агента и его полномочия по подписанию транзакций относительно друг друга, а также участвует ли в принятии решения до попадания транзакции в блокчейн какой-либо независимый от агента компонент.

Риски, специфичные именно для агентов, а не просто для кошельков

Prompt injection, превращающийся в подписанную транзакцию

Prompt injection скрывает инструкции внутри контента, который агент предназначен читать, — например, в описании токена, на веб-странице, в письме или в ответе API, — а не в диалоге с пользователем. В контексте кошелька это опаснее, чем в большинстве других случаев: агент, обманутый вредоносным письмом, создаёт неудобство; агент с полномочиями подписания, которого удалось обмануть, может инициировать необратимую транзакцию.

Ключи, доступные из собственной среды выполнения агента

Агент, способный прочитать собственный ключ подписания — из конфигурационного файла, переменной окружения или памяти приложения, — превращает любую свою компрометацию в компрометацию контролируемых им средств. Показательный пример — инцидент 8 февраля 2026 года, когда Gitcoin's Owockibot раскрыл приватный ключ своего горячего кошелька в нескольких местах, несмотря на инструкцию никогда его не разглашать; потери удалось ограничить главным образом потому, что на кошельке находилось лишь около $2 100. Режим server-wallet в MetaMask Agent Wallet хранит ключи внутри доверенной среды исполнения (TEE), недоступной для агента. Для разработчиков, которым необходим локальный контроль над ключами, предусмотрен отдельный режим bring-your-own-wallet; в его документации явно указано, что мнемоническая фраза не должна передаваться в качестве аргумента командной строки — только через переменную окружения, поскольку история команд и списки процессов сами по себе являются путями утечки.

Разрешения, не сужающиеся под конкретную задачу

Агент, предназначенный для проверки балансов, не нуждается в полномочиях на неограниченное одобрение расходования токенов по любому контракту. Когда разрешения не масштабируются под конкретную задачу, один скомпрометированный или введённый в заблуждение агент может действовать от имени кошелька в полном объёме, а не в рамках узкого круга полномочий.

Путаница между страхованием транзакций и средством контроля безопасности

Некоторые агентские кошельки дополняют свой стек безопасности возмещением ущерба на случай непредвиденных потерь. Transaction Shield — подписка MetaMask, объединяющая Transaction Protection с приоритетной поддержкой, — возмещает до $10 000 в месяц в mUSD по транзакциям, прошедшим проверку безопасности MetaMask, но всё равно повлёкшим убытки. Из покрытия явно исключены: потери вследствие компрометации или утечки Secret Recovery Phrase или приватного ключа, обычные рыночные потери, эксплойты на уровне протокола и одноранговые переводы. Возмещение может компенсировать последствия транзакции, которая выглядела безопасной, но таковой не оказалась.

Как Guard Mode и Beast Mode влияют на уровень риска

Два режима работы MetaMask Agent Wallet определяют, какие средства контроля применяются автоматически, а какие зависят от того, заметит ли пользователь проблему в режиме реального времени. Документация MetaMask по торговым режимам перечисляет защитные механизмы, применяемые в каждом режиме до выполнения транзакции:

Оба режима блокируют транзакции, которые сканер угроз MetaMask помечает как вредоносные, или контракты, помеченные как рискованные, и в обоих случаях перед продолжением требуется подтверждение через 2FA. В Guard Mode всё, что выходит за пределы настроенных allowlist или превышает лимит расходования, также приостанавливается для подтверждения. В Beast Mode этого не происходит, поскольку никаких allowlist не существует. Beast Mode не ослабляет непосредственно обнаружение вредоносных транзакций — он убирает слой allowlist и лимитов расходования, который в противном случае мог бы перехватить легитимно выглядящую транзакцию, которую агент не должен был инициировать.

Как работает изоляция на уровне кошелька

Руководство MetaMask для разработчиков по созданию серверных кошельков для агентов описывает общую схему: ключ подписания хранится внутри доверенной среды исполнения без внешних сетевых подключений и постоянного хранилища, агент располагает только отдельным учётным данным для запроса подписи, а анклав — не агент — проверяет запрос, применяет политику и формирует подпись. Агент предлагает; он никогда не владеет. Архитектура MetaMask Agent Wallet реализует это разделение напрямую: в режиме server-wallet ключи управляются внутри TEE, недоступного для агента, при этом пользователь сохраняет самостоятельное хранение и может экспортировать базовую Secret Recovery Phrase. Запрос, требующий подтверждения, переходит в состояние AWAITING_MFA, и продвинуть его может только подтверждение пользователя через MetaMask Mobile или по электронной почте — но не агент.

Чек-лист перед подключением агента к реальным средствам:

• Среда выполнения агента не может прочитать или экспортировать приватный ключ.

• Подписание происходит в изолированной среде, а не в собственном процессе агента.

• Расходование ограничено на уровне каждой транзакции и на скользящей основе.

• Контракты, сети и получатели могут быть добавлены в allowlist, а не оставлены открытыми.

• Каждая транзакция симулируется и проходит сканирование угроз до подписания.

• Ограничения политики применяются вне модели. Системный промпт — это рекомендация, а не механизм принуждения.

• Разрешения могут быть отозваны, а сессия завершена немедленно.

• Помеченные и выполненные действия логируются и доступны для аудита.

• Конфигурация протестирована на сценарии prompt injection, а не только на ожидаемые промпты.

• Условия возмещения изучены с точки зрения исключений, а не только покрытия.

Где проходит граница безопасности в различных моделях агентских кошельков

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

Полное сравнение по каждому поставщику — Coinbase, Cobo, Ledger, BitGo и OKX — см. в статье Best agentic wallets in 2026, compared.

Всё это не делает агента невосприимчивым к манипуляциям. Реалистичная цель — не модель, которую невозможно обмануть. Это кошелёк, в котором обман не превращается в неограниченные финансовые полномочия, где максимальный ущерб от скомпрометированного агента ограничен лимитом расходования, allowlist и подписью, до которой агент так и не смог добраться самостоятельно.