Фреймворк безопасности MCP Web3 от Google Cloud: Как защитить кошелек от опустошения ИИ-агентами
ИИ-агенты, которые могут автономно торговать токенами, ребалансировать 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. Это полностью исключает кражу средств через промпт-инъекции — злоумышленнику потребуется как цифровой доступ к агенту, так и физический доступ к аппаратному кошельку. Компромиссом является задержка и потеря полной автономии, что делает этот метод наиболее подходящим для дорогостоящих операций, где безопасность важнее скорости.