Глава Microsoft призвал создать «аварийный тормоз» для продвинутых моделей ИИ: что из этого должны вынести команды криптобезопасности

Генеральный директор Microsoft Сатья Наделла, как сообщается, призвал компании относиться к мощным моделям ИИ не как к безобидным инструментам повышения продуктивности, а как к потенциальным внутренним угрозам. Его главный тезис прост, но крайне важен: организациям следует исходить из того, что продвинутые модели могут быть скомпрометированы, с самого начала ограничивать их полномочия и сохранять управляемый человеком «аварийный тормоз», который позволит приостановить или отключить автономных ИИ-агентов во время их работы.

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

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

Почему «kill switch» для ИИ особенно важен в криптоиндустрии

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

Именно поэтому автономные ИИ-агенты особенно чувствительны в Web3-среде. Модель ИИ, имеющая право подписывать транзакции, ребалансировать казначейские активы, разворачивать смарт-контракты, взаимодействовать с DeFi-протоколами или управлять операционными учетными данными, может стать крайне ценной целью.

Скомпрометированный ИИ-агент может не выглядеть как классический хакер. Он может действовать через обычные API, утвержденные рабочие процессы или внешне легитимные промпты. Именно поэтому подход «исходить из уже произошедшего взлома» становится все более актуальным. Такие фреймворки безопасности, как NIST AI Risk Management Framework, подчеркивают важность управления, картирования, измерения и контроля рисков на протяжении всего жизненного цикла ИИ. Для криптокоманд эти принципы должны распространяться также на доступ к кошелькам, подтверждение транзакций и исполнение смарт-контрактов.

Новая поверхность атаки: ИИ-агенты с ончейн-полномочиями

В 2025 году ИИ-агенты становятся более способными и все глубже встраиваются в финансовые процессы. В криптоиндустрии их могут использовать для:

• Мониторинга рисков смарт-контрактов и уведомления команд об аномальной активности
• Исполнения торговых стратегий на децентрализованных биржах
• Подготовки кратких обзоров предложений DAO и рекомендаций по управлению
• Автоматизации отчетов казначейства и бухгалтерских процессов
• Помощи пользователям в интерпретации транзакций кошелька перед подписанием
• Обнаружения фишинговых доменов, вредоносных контрактов и подозрительных разрешений на токены

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

Prompt injection, отравление данных, злоупотребление инструментами, манипуляция моделью и скомпрометированные плагины больше не являются чисто теоретическими угрозами. В OWASP Top 10 for Large Language Model Applications выделяются такие риски, как prompt injection, небезопасная обработка выходных данных, чрезмерная автономность и раскрытие чувствительной информации. Каждый из этих рисков становится опаснее, когда модель подключена к криптоинфраструктуре.

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

Чем больше автономии получает ИИ-система, тем важнее заранее определить, чего она не имеет права делать.

Принцип «не полагайтесь на одну модель» применим и к блокчейн-решениям

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

• Следует ли подписывать транзакцию
• Безопасно ли взаимодействие со смарт-контрактом
• Содержит ли голосование DAO скрытый риск для управления
• Связан ли адрес с подозрительной активностью
• Должна ли быть выполнена автоматическая транзакция казначейства

Ни одну модель нельзя воспринимать как безусловный авторитет в таких вопросах. Более безопасная архитектура предполагает несколько уровней проверки.

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

Это особенно важно потому, что модели ИИ могут звучать уверенно даже тогда, когда ошибаются. В криптоиндустрии уверенность — это не механизм безопасности.

Неизменяемые журналы естественно подходят для Web3-безопасности

Еще одна важная рекомендация — сохранять устойчивые к подделке записи о поведении ИИ-агентов. Это хорошо согласуется с принципами блокчейна.

Криптокомандам следует вести подробные журналы, отражающие:

• К каким данным обращался ИИ-агент
• Какие инструменты или API он вызывал
• Какие промпты или инструкции повлияли на действие
• Какую транзакцию он рекомендовал или инициировал
• Кто одобрил финальное исполнение
• Были ли проигнорированы какие-либо предупреждения о рисках

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

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

Независимый аудит должен расшириться от смарт-контрактов к ИИ-процессам

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

Независимая проверка должна изучать:

• Разрешения модели и границы доступа
• Дизайн промптов и системных инструкций
• Источники данных, используемые моделью
• Разрешения на вызов инструментов
• Сценарии отказов и процедуры резервного реагирования
• Требования к человеческому одобрению
• Планы реагирования на инциденты
• Системы журналирования и мониторинга

Это не замена аудиту смарт-контрактов. Это расширение модели безопасности. В криптостеке, где используется ИИ, пристального анализа требуют и код, и процессы принятия решений.

Более широкое сообщество кибербезопасности также подчеркивает важность принципов secure-by-design. Руководства инициативы CISA Secure by Design особенно актуальны для команд, создающих системы, в которых настройки по умолчанию, контроль доступа и операционная устойчивость имеют значение с первого дня.

Раскрытие информации об инцидентах может укрепить всю криптоэкосистему

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

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

В эпоху ИИ раскрытие информации об инцидентах должно включать новые категории данных:

• Был ли ИИ-агент скомпрометирован через prompt injection?
• Полагался ли он на недоверенные внешние данные?
• Были ли его разрешения слишком широкими?
• Отсутствовало ли в системе человеческое одобрение для действий с высоким риском?
• Были ли журналы достаточно полными, чтобы восстановить ход событий?
• Может ли та же атака затронуть другие криптоприложения?

Такая прозрачность помогает предотвращать повторение одних и тех же ошибок в DeFi, кошельках, у инфраструктурных провайдеров и на торговых платформах.

Практические меры контроля для криптокоманд, использующих ИИ-агентов

Криптокомпаниям, внедряющим ИИ, стоит придерживаться многоуровневой модели защиты. Следующие меры могут снизить риск сбоев, вызванных ИИ:

1. Ограничивайте полномочия на транзакции

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

2. Используйте разрешения на основе политик

Определите, что ИИ может и чего не может делать. Например, агенту можно разрешить подготовить транзакцию, но не отправлять ее в сеть; или анализировать контракт, но не одобрять token allowance.

3. Добавьте механизм экстренной остановки

Команды должны иметь возможность немедленно приостанавливать ИИ-процессы при обнаружении аномального поведения. Это включает отзыв API-ключей, заморозку автоматизированных пайплайнов, отключение доступа к инструментам и остановку запланированных действий.

4. Отделяйте рекомендации от исполнения

ИИ-система может помогать с анализом, но исполнение должно проходить через защищенную транзакционную инфраструктуру с независимой проверкой.

5. Ведите устойчивые к подделке аудит-трейлы

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

6. Требуйте человеческой проверки для необратимых действий

Любое действие, которое может навсегда переместить активы, изменить владельца контракта, обновить логику протокола или изменить контроль над казначейством, должно включать человеческое одобрение.

7. Тестируйте систему на враждебные промпты

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

Что это означает для обычных криптопользователей

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

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

• Адрес получателя
• Актив и сумму
• Разрешения на использование токенов
• Идентичность смарт-контракта
• Сеть и настройки газа
• Соответствует ли действие их намерению

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

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

Общая картина: автономному ИИ нужны крипто-нативные ограничители

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

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

Правильный путь — не отказываться от ИИ. Правильный путь — проектировать ИИ-системы со строгими границами, независимыми проверками, аудитируемостью и возможностью быстрого отключения.

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