Как работают агентские кошельки: от намерения до исполнения в архитектуре самостоятельного хранения

Самохранительный агентный кошелёк позволяет ИИ-агенту преобразовать инструкцию в подписанную onchain-транзакцию, не получая доступа к ключам пользователя. Агент предлагает действие, кошелёк применяет политику, перед подписанием выполняются предварительные проверки, а участие человека требуется только в случае, если транзакция помечена как подозрительная или выходит за рамки допустимого.

Этот жизненный цикл — ключевой архитектурный вопрос для разработчиков, создающих агентные системы с поддержкой транзакций. Категория больше не является гипотетической. MetaMask уже запустил продукт в режиме раннего доступа — MetaMask Agent Wallet, вышедший 8 июня 2026 года. Coinbase представил CDP Agentic Wallets и AgentKit, а также ряд других решений. Подробное сравнение продуктов доступно в материале Лучшие агентные кошельки 2026 года.

Дискуссия сместилась от вопроса «могут ли агенты совершать транзакции?» к вопросу «как уровень кошелька должен обеспечивать контроль, когда они это делают?» Именно здесь самохранение становится ключевым отличием.

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

Жизненный цикл агентного кошелька: от намерения до исполнения

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

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

1. Намерение: агент получает запрос, триггер или сигнал стратегии, например: «обменяй 500 USDC на ETH, если проскальзывание не превышает 50 б.п.» или «оплати этот x402-эндпоинт, если котировка ниже 0,10 USDC».

2. Формирование: агент определяет маршрут, целевую сеть, вызов контракта, путь подтверждения, допущения по газу и любые зависимые действия — например, бриджинг или погашение делегирования.

3. Проверка политики: кошелёк проверяет, соответствует ли запрошенное действие политике, заданной пользователем. Это может включать лимиты расходов, списки разрешённых протоколов и получателей, сетевые ограничения и разрешения с временны́м сроком действия.

4. Предварительные проверки: перед подписанием система выполняет симуляцию, сканирование угроз и другие проверки безопасности транзакции. В некоторых стеках здесь же реализована защита от MEV.

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

6. Эскалация к человеку: если транзакция является вредоносной, выходит за рамки политики или вызывает неоднозначность, рабочий процесс приостанавливается для проверки человеком, а не подписывается автоматически.

7. Исполнение и журналирование: транзакция отправляется, состояние обновляется, а система фиксирует путь исполнения, чтобы разработчик или пользователь мог провести аудит произошедшего.

Эта последовательность — полезная ментальная модель, поскольку отвечает на вопрос разработчика, который постоянно возникает при работе с LLM: не «что такое агентный кошелёк?», а «как агент реально переходит от инструкции к живой транзакции, не получая доступа к моим ключам?»

Почему самохранение важно для агентных систем

Самохранение важно потому, что автономность агента расширяет поверхность атаки вокруг процесса подписания. Когда человек нажимает кнопку один раз, риск ограничен единственным моментом проверки. Когда агент может превратить один запрос в подтверждения, переводы, свопы и вызовы контрактов, возникает вопрос: где в действительности находится контроль?

В самохранительной модели пользователь сохраняет возможность выхода. Кошелёк может использовать защищённую инфраструктуру для выполнения операций подписания, однако архитектура по-прежнему строится вокруг того, что пользователь сохраняет контроль над ключами или возможностью восстановления и может забрать их при необходимости. Пользователи MetaMask Agent Wallet могут в любой момент экспортировать свою секретную фразу восстановления, тогда как ключи защищены через доверенную среду выполнения (TEE). Это полностью самохранительный агентный кошелёк, позволяющий агентам работать в рамках ограничений, заданных пользователем.

Это не тот же вопрос, что «является ли инфраструктура безопасной?» Как MetaMask, так и Coinbase описывают свои агентные кошельки как некастодиальные и оба используют TEE для защиты ключей. Принципиальное различие для разработчиков — не терминология хранения, а то, как на практике работает применение политики:

• MetaMask применяет политику через настраиваемые пользователем лимиты расходов, списки разрешённых протоколов и обязательный конвейер безопасности, который запускается для каждой транзакции, с эскалацией к человеку через 2FA, когда транзакция помечена или выходит за рамки политики. Пользователь определяет контрольную поверхность до начала работы агента.

• Coinbase применяет политику программно — через лимиты расходов, устанавливаемые пользователем в интерфейсе кошелька, KYT-скрининг, блокирующий высокорисковые транзакции, и ограничения навыков агента, предотвращающие переводы на произвольные адреса. Применение политики осуществляется на уровне инфраструктуры, а не в интерактивном режиме.

Оба подхода безопасны. Архитектурный вопрос состоит в том, предпочитаете ли вы модель, при которой транзакции вне политики по умолчанию приостанавливаются для проверки человеком (Guard Mode в MetaMask), или модель, при которой ограничения применяются программно без стандартного пути эскалации для каждой транзакции (подход Coinbase). Этот выбор определяет, как вы проектируете границы автономности для своей агентной системы.

MetaMask Agent Wallet: сквозной процесс

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

1. Намерение

Пользователь или вышестоящий агент-оркестратор даёт инструкцию, например:

• ребалансировать портфель в ETH в рамках фиксированного бюджета

• открыть позицию по бессрочным фьючерсам на Hyperliquid при достижении порогового значения

• изучить котировку на рынке предсказаний

2. Формирование

Агент использует CLI и базовый SDK для проверки балансов, определения маршрутов, построения транзакции и подготовки точного действия. Операции только для чтения — такие как проверка балансов и запросы метаданных токенов — не требуют подтверждения.

3. Проверка политики

MetaMask Agent Wallet работает в двух режимах: Guard Mode и Beast Mode. В Guard Mode пользователь устанавливает дневные лимиты расходов, разрешённые протоколы и правила политики до начала транзакций агента. В Beast Mode обязательный конвейер безопасности по-прежнему запускается для каждой транзакции, однако прерывания политики по пограничным случаям сокращены. Это важно, потому что агент не определяет свои полномочия в режиме реального времени. Пользователь задаёт контрольную поверхность до начала исполнения.

4. Предварительные проверки

Каждая поддерживаемая EVM-транзакция проходит через обязательный трёхэтапный конвейер безопасности MetaMask — симуляцию транзакции, сканирование угроз Transaction Shield на базе Blockaid и защиту от MEV через Smart Transactions — прежде чем попасть в блокчейн. Конвейер не является опциональным. Он запускается для каждой транзакции независимо от режима работы, что делает безопасность транзакций неотъемлемой частью пути кошелька, а не дополнением, которое разработчик должен собирать самостоятельно.

5. Подписание в рамках самохранения

Если действие проходит правила и проверки безопасности, подписание происходит без передачи необработанных ключей агентной среде выполнения. Именно здесь самохранительный дизайн приобретает значение. Агент получает возможность исполнения, однако архитектура продукта по-прежнему строится вокруг экспортируемых ключей, находящихся у пользователя, и подписания с поддержкой TEE.

6. Эскалация к человеку

Если попытка транзакции помечена как вредоносная или выходит за рамки политики, MetaMask приостанавливает процесс для проверки через 2FA. Пользователь может проверить запрос через push-уведомление в MetaMask Mobile или ссылку подтверждения по электронной почте. Агент не может обойти этот путь эскалации.

7. Исполнение и журналирование

После подтверждения транзакция отправляется и фиксируется. Метаданные CLI-сессии и кошелька хранятся в защищённых локальных файлах, что важно для разработчиков, проводящих аудит локального состояния и управления сессиями.