Перейти к основному контенту

Фреймворк безопасности MCP Web3 от Google Cloud: Как защитить кошелек от опустошения ИИ-агентами

· 9 мин чтения
Dora Noda
Software Engineer

ИИ-агенты, которые могут автономно торговать токенами, ребалансировать DeFi-позиции и оплачивать собственные вычисления, звучат революционно — до тех пор, пока один из них не подвергнется промпт-инъекции, в результате которой ваши сбережения будут отправлены злоумышленнику. Недавно опубликованный фреймворк безопасности MCP Web3 от Google Cloud решает именно этот кошмарный сценарий, предлагая план корпоративного уровня для защиты агентов Model Context Protocol, взаимодействующих с блокчейнами.

Вот что рекомендует фреймворк, почему это важно и как он соотносится с конкурирующими подходами от Coinbase, Ledger и развивающимся стандартом платежей x402.

Проблема: ИИ-агенты с кошельками — это заряженное ружье

Конвергенция автономного ИИ и блокчейна создает уникальную поверхность угроз. В отличие от традиционного программного обеспечения, исполняющего детерминированный код, большие языковые модели вероятностны — их можно обмануть, запутать или перехватить в середине сессии. Когда такие модели владеют приватными ключами или имеют право подписи для ончейн-средств, ставки возрастают с «неправильного ответа» до «необратимых финансовых потерь».

Цифры подчеркивают серьезность ситуации. Тестирование Red Team от Anthropic показало, что ИИ-агенты успешно использовали уязвимости в 207 из 405 тестовых смарт-контрактов, украв 550 миллионов долларов в симулированных средствах. Еще более тревожным является тот факт, что использование ИИ для эксплуатации уязвимостей блокчейна подскочило с 2% до почти 56% всех эксплойтов всего за один год. Между тем, промпт-инъекция — когда злоумышленники внедряют вредоносные инструкции в, казалось бы, безобидные данные — остается основным вектором атак для агентов с доступом к кошельку, позволяя давать агенту команды на вывод средств на адрес, контролируемый злоумышленником.

Фреймворк Google Cloud появляется в момент, когда индустрия отчаянно нуждается в защитных барьерах. Учитывая, что рынок ИИ-агентов, по прогнозам, превысит 52 миллиарда долларов, а сотни блокчейн-инструментов с поддержкой MCP уже находятся в эксплуатации, разрыв между функциональностью и безопасностью стал опасным.

Кастодиальные против некастодиальных: две архитектуры, два профиля риска

В основе фреймворка Google лежит трезвый анализ двух доминирующих моделей взаимодействия агентов с блокчейном.

Кастодиальные агенты напрямую управляют приватными ключами. Агент (или хостинг-платформа) удерживает средства и может автономно подписывать транзакции. Это обеспечивает полностью автономную работу — агент может ребалансировать DeFi-портфель в 3 часа ночи без подтверждения человеком. Но цена этого высока: если хост агента будет взломан, каждый делегированный кошелек становится мишенью. Кастодиальная модель концентрирует риск на уровне платформы, превращая ее в привлекательную цель (хонипот) для хакеров.

Некастодиальные агенты создают транзакции, но не могут их подписывать. Агент готовит неподписанную транзакцию и возвращает ее пользователю (или на аппаратный кошелек) для окончательного подтверждения. Фреймворк Google делает меткое замечание: если сервер MCP уже может подготовить и подписывать транзакцию с помощью ключа, которым он владеет, он должен иметь возможность выполнять ту же логику без шага финальной подписи. Это «незначительное изменение открывает гораздо более безопасную и гибкую парадигму» — агент сохраняет свои аналитические и стратегические возможности, в то время как пользователь сохраняет полный контроль над движением средств.

Рекомендация Google однозначна: по возможности использовать некастодиальную модель по умолчанию и добавлять дополнительные меры контроля безопасности (изоляция TEE, лимиты расходов, симуляция транзакций), когда кастодиальный доступ действительно необходим.

Стек безопасности: глубокая эшелонированная оборона для ончейн-агентов

Вместо того чтобы предлагать одну «серебряную пулю», Google описывает многоуровневую архитектуру безопасности, где несколько независимых уровней контроля компенсируют слепые зоны друг друга.

Изоляция TEE для управления ключами

Доверенные среды исполнения (TEE) — аппаратные анклавы, такие как Intel SGX или AMD SEV — обеспечивают физически изолированное пространство, где приватные ключи могут существовать без доступа со стороны промпта агента, контекстного окна LLM или даже операционной системы хоста. Как выразился один исследователь безопасности: «вы не можете пропатчить физику или применить методы социальной инженерии к чипу». Изоляция TEE гарантирует, что даже полностью скомпрометированный агент не сможет извлечь ключ подписи, поскольку ключ никогда не покидает аппаратный анклав.

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

Симуляция транзакций перед выполнением

Прежде чем любая транзакция попадет в блокчейн, фреймворк рекомендует пропустить ее через среду симуляции. Это предотвращает атаки, при которых транзакция кажется агенту легитимной, но приводит к непредвиденным последствиям — опустошению пулов ликвидности, запуску эксплойтов с мгновенными займами (flash loans) или взаимодействию с вредоносными контрактами, замаскированными под легитимные протоколы.

Симуляция транзакций также служит проверкой на ошибки самого агента. LLM могут галлюцинировать параметры, неверно интерпретировать десятичные знаки токенов или создавать транзакции, которые технически валидны, но экономически катастрофичны. Уровень симуляции выявляет эти ошибки до того, как они станут необратимыми в сети.

Ограничение скорости и лимиты расходов

Даже с изоляцией TEE и симуляцией, Google выступает за использование жестко закодированных финансовых ограничений. Лимиты расходов на уровне сессии ограничивают сумму, которую агент может потратить в рамках одной сессии. Лимиты на транзакцию предотвращают превышение установленного порога любой отдельной операцией. Периоды ожидания между дорогостоящими транзакциями добавляют временной буфер.

Здесь ClawPay MCP и Агентские кошельки Coinbase уже реализовали схожие подходы. ClawPay дополняет Agent Wallet SDK встроенным контролем лимитов расходов — транзакции, превышающие лимит, автоматически ставятся в очередь на одобрение человеком, а не просто отклоняются. Агентские кошельки Coinbase поставляются с программируемыми лимитами сессий, ограничениями транзакций и готовой к соблюдению нормативных требований проверкой KYT (Know Your Transaction), которая блокирует высокорисковые взаимодействия до их выполнения.

Аудиторские журналы на основе мандатов

Протокол платежей агентов Google (AP2) вводит «мандаты» — защищенные от несанкционированного доступа, криптографически подписанные цифровые контракты, которые подтверждают инструкции пользователя. Каждая транзакция несет в себе неоспоримый аудиторский след, связывающий ее с первоначальным намерением пользователя. Это не просто «театр безопасности»; это требование соответствия для институционального внедрения, где регуляторы требуют доказательств того, что автономный агент действовал в рамках своих полномочий.

Широкая экосистема: как вписывается фреймворк Google

Фреймворк Google не существует в вакууме. Он появляется наряду с несколькими конкурирующими и дополняющими подходами, которые вместе определяют ландшафт безопасности агентских финансов к 2026 году.

Агентские кошельки Coinbase и x402

Агентские кошельки Coinbase представляют собой кастодиальную часть спектра, созданную специально для полной автономии. Они используют изоляцию анклавов для хранения закрытых ключей в защищенной инфраструктуре Coinbase, никогда не раскрывая их промптам агента или LLM. В сочетании с протоколом x402, который сейчас регулирует более 50 миллионов транзакций, они позволяют агентам автономно оплачивать доступ к API, вычисления и данные, используя стейблкоины, такие как USDC.

Фонд x402 Foundation, запущенный совместно с Coinbase и Cloudflare, управляет открытой спецификацией с поддержкой нескольких сетей и независимым от токенов дизайном. Его механизм HTTP 402 «Payment Required» позволяет любому эндпоинту API запрашивать оплату перед предоставлением ответа, создавая нативный платежный уровень для агентского интернета.

Аппаратное подписание Ledger

Интеграция MoonPay с Ledger представляет собой максимально некастодиальный подход. Каждая транзакция, инициируемая ИИ-агентом, должна быть физически одобрена на устройстве Ledger. Это полностью исключает кражу средств через промпт-инъекции — злоумышленнику потребуется как цифровой доступ к агенту, так и физический доступ к аппаратному кошельку. Компромиссом является задержка и потеря полной автономии, что делает этот метод наиболее подходящим для дорогостоящих операций, где безопасность важнее скорости.

Академическая перспектива

В статье «Автономные агенты на блокчейнах» от января 2026 года были формализованы границы доверия, которые реализует фреймворк Google. Исследование показало, что один скомпрометированный агент может отравить 87 % последующих процессов принятия решений в течение четырех часов в сетевых агентских системах — это подтверждает акцент Google на изоляции и независимой проверке на каждом уровне.

Что это значит для разработчиков

Для разработчиков, создающих ИИ-агентов, взаимодействующих с блокчейнами, фреймворк Google предлагает практическое дерево решений.

  • Низкобюджетные высокочастотные операции (микроплатежи, доступ к API, извлечение данных): используйте кастодиальные кошельки с лимитами расходов и x402 для оплаты. Риск на транзакцию невелик, а преимущество в скорости при полной автономии оправдывает кастодиальную модель.

  • DeFi-операции средней стоимости (доходное фермерство, ребалансировка портфеля): используйте управление ключами с изоляцией TEE и симуляцию транзакций. Агент работает автономно в рамках заданных параметров, но каждая транзакция проверяется перед выполнением.

  • Высокобюджетные или необратимые операции (крупные переводы, голосования по управлению, развертывание контрактов): используйте некастодиальную архитектуру с аппаратным подписанием. Агент подготавливает и рекомендует; человек (или аппаратное устройство) одобряет.

  • Мультиагентные системы: внедряйте аудиторские журналы на основе мандатов и изолируйте сферу полномочий каждого агента. Никогда не позволяйте компрометации одного агента каскадно распространяться по сети.

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

Путь вперед

Гонка за обеспечение безопасности взаимодействий ИИ и блокчейна только начинается. Фреймворк безопасности MCP Web3 от Google — это наиболее полный корпоративный план, опубликованный на сегодняшний день, но ландшафт угроз развивается быстрее, чем любой отдельный документ может охватить. По мере того как ИИ-агенты становятся более способными и автономными, инфраструктура безопасности должна масштабироваться синхронно.

Отрасль сходится на нескольких ключевых принципах: отделение принятия решений от полномочий на подписание, изоляция ключей на аппаратном уровне, обязательная симуляция транзакций и криптографические аудиторские журналы. Независимо от того, строите ли вы на Google Cloud, инфраструктуре Coinbase или создаете свой собственный стек агентов, эти принципы не подлежат обсуждению.

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


Строите ИИ-агентов, взаимодействующих с блокчейнами? BlockEden.xyz предоставляет RPC- и API-инфраструктуру корпоративного уровня для Sui, Aptos, Ethereum и более 20 сетей — надежный уровень данных, необходимый вашим агентам для симуляции транзакций, ончейн-запросов и получения состояния блокчейна в реальном времени. Изучите наш маркетплейс API, чтобы расширить возможности ваших агентских приложений на инфраструктуре, созданной для автономной работы.