Отметка @grok в посте X в сочетании с несколькими точками и тире — вот все, что потребовалось злоумышленнику прошлой ночью, чтобы выманить средства из верифицированного криптокошелька, даже не имея доступа к приватным ключам.
Агентная пусковая площадка токенов Bankrbot сообщила 4 мая, что отправила 3 миллиарда DRB в сети Base на адрес получателя 0xe8e47...a686b.
Средства поступили с кошелька, назначенного ИИ X, Grok, и были отправлены на неавторизованный кошелек, принадлежащий злоумышленнику. Эта транзакция в Base демонстрирует цепочку ончейн-перевода, стоящую за этим постом.
Анализ постов X вокруг инцидента, проведенный CryptoSlate, указывает на зафиксированный путь команды, который начался с обфускации азбукой Морзе. Grok декодировал текст в чистое публичное указание с отметкой @bankrbot и просьбой отправить токены, в то время как Bankrbot воспринял команду как исполняемую.
Уязвимым слоем стало сопряжение между языком и полномочиями. Модель, которая декодирует головоломку, пишет полезный ответ или переформатирует текст пользователя, может стать частью платежной системы, если другой агент рассматривает этот вывод как действительный.
Для криптоинвесторов этот перевод должен превратить риск, связанный с ИИ-агентами, из абстрактной дискуссии о безопасности в проблему контроля над кошельком. Публичная команда может стать разрешением на трату, когда одна система рассматривает вывод модели как инструкцию, а другая система имеет разрешение на перемещение токенов.
Разрешения кошелька, парсер, социальный триггер и политика исполнения становятся слоями векторов атаки.
Посты и контекст транзакции, проанализированные CryptoSlate, оценивают перевод DRB примерно в 155 000 – 200 000 долларов США на тот момент, при этом данные о цене DebtReliefBot предоставили рыночный контекст для токена.
В отчетах, просмотренных CryptoSlate, также говорится, что большая часть средств возвращается, а некоторое количество DRB, по сообщениям, сохраняется в качестве неофициальной награды за обнаружение ошибки (bug bounty). Такой исход уменьшил потери, но также показал, насколько восстановление зависело от посттранзакционной координации, а не от предтранзакционных ограничений.
Разработчик Bankr 0xDeployer заявил, что 80% средств были возвращены, а оставшиеся 20% будут обсуждаться с сообществом DRB. Это подтвердило частичное восстановление, оставив окончательное решение по удержанным средствам открытым.
0xDeployer также сообщил, что Bankr автоматически создает кошелек X для каждой учетной записи, взаимодействующей с платформой, включая Grok. Согласно посту, этим кошельком управляет тот, кто контролирует учетную запись X, а не сотрудники Bankr или xAI.
Как публичный текст стал разрешением на трату
Зафиксированный путь состоял из четырех шагов. Во-первых, злоумышленник определил NFT членства в Bankr Club в кошельке, связанном с Grok, до инцидента.
Анализ CryptoSlate показывает, что это расширило привилегии кошелька на передачу средств в среде Bankr. Страница доступа Bankr описывает механику членства и доступа на сегодняшний день, помещая претензию на NFT в более широкий уровень разрешений, а не делая это полным объяснением.
Во-вторых, злоумышленник опубликовал сообщение в X, содержащее азбуку Морзе с дополнительным “шумным” форматированием. Посты, связанные с инцидентом, описывали инъекцию запроса через азбуку Морзе, в то время как удаленный сейчас запрос был недоступен для нашего прямого анализа.
Заявленный вектор — азбука Морзе с возможными трюками с массивами или конкатенацией.
В-третьих, публичный ответ Grok, по сообщениям, перевел обфусцированный текст на чистый английский язык и включил тег @bankrbot. В этом случае Grok функционировал как полезный декодер.
Риск проявился после того, как текст покинул Grok и попал в интерфейс бота, который отслеживал публичный вывод на предмет отформатированных команд.
В-четвертых, Bankrbot воспринял публичную команду как исполняемую и инициировал перевод токенов. Bankr и Base описывают поверхность кошелька агента, которая может использовать функциональность кошелька для переводов, обменов, спонсирования газа и запуска токенов, в то время как отправка токенов на естественном языке идеально вписывается в эту продуктовую поверхность.
Более широкая документация Bankr по ончейн-помощнику ИИ показывает, почему граница между инструкциями чата и полномочиями на транзакции требует явной политики.
| Шаг | Поверхность | Наблюдаемое действие | Контроль, который изменил бы результат |
|---|---|---|---|
| Настройка привилегий | Уровень кошелька или членства | Доступ, по сообщениям, был расширен до появления запроса | Отдельный обзор привилегий для новых возможностей кошелька |
| Обфускация | Пост в X | Азбука Морзе поместила платежную инструкцию в обфусцированный текст | Проверки декодирования и классификации перед публикацией ответов |
| Публичный вывод | Ответ Grok | Чистая команда была раскрыта с тегом бота | Санитизация вывода для строк команд, похожих на инструменты |
| Исполнение | Bankrbot | Бот отреагировал на публичную команду и переместил токены | Списки разрешенных получателей, лимиты расходов и человеческое подтверждение |
Почему кошельковые агенты меняют риск
Инъекция запроса часто рассматривалась как проблема поведения модели. Финансовая версия более конкретна.
Модель может выполнять обычную работу, в то время как окружающая система предоставляет выводу слишком много полномочий.
Вредоносные инструкции могут попасть в модель через сторонний контент, а защита агентов все чаще фокусируется на доступе к инструментам, подтверждениях и контроле над сопутствующими действиями.
Категория чрезмерного агентства (excessive-agency) охватывает тот же операционный риск: широкие разрешения, чувствительные функции и автономные действия увеличивают радиус поражения. Более широкий список рисков приложений LLM также рассматривает инъекцию запросов и небезопасную обработку вывода как проблемы уровня приложения.
Криптовалюта усложняет поглощение этого радиуса поражения. Агент по обслуживанию клиентов, отправляющий плохое электронное письмо, создает проблему для проверки. Агент по торговле или кошельковый помощник, подписывающий транзакцию, создает проблему контроля активов.
Разница в окончательности. Как только кошелек подписывает и отправляет перевод, путь восстановления зависит от контрагентов, общественного давления или правоохранительных органов.
Инцидент с Bankr наиболее ярко демонстрирует сбой контроля. В документации Bankr по контролю доступа описывается режим только для чтения, флаги операций записи, списки разрешенных IP-адресов и списки разрешенных получателей.
Это те ворота, которые находятся вне модели и могут уменьшить ущерб, даже когда модель неожиданным образом обрабатывает вредоносный контент.
Такая же уязвимость проявляется в торговых агентах и локальных помощниках с разрешениями на кошелек или биржу. Торговый бот с API-ключами может быть манипулирован для совершения плохих ордеров, если он принимает комментарии о рынке, посты в социальных сетях, электронные письма или веб-страницы в качестве инструкций.
Локальный помощник с доступом к кошельку создает более рискованную версию той же проблемы вызова инструментов: косвенные инструкции могут подтолкнуть помощника к подготовке транзакций или раскрытию конфиденциальной операционной информации.
Исследования в области безопасности уже смоделировали этот класс сбоев. Косвенная инъекция запросов описывает вредоносный контент, который манипулирует агентами через обрабатываемые ими данные, в то время как исследования агентов с вызовом инструментов оценивают атаки и средства защиты для агентов, работающих с внешними инструментами.
Таксономия NIST по состязательному машинному обучению предоставляет более широкий язык для осмысления этих атак и мер по их смягчению.
Что должны требовать криптопользователи
Для криптоинвесторов ключевым требованием является проектирование разрешений. Агент, подключенный к кошельку, должен исходить из предположения, что веб-страницы, посты в X, личные сообщения, электронные письма и кодированный текст могут содержать враждебные инструкции.
Это предположение превращает безопасность агента в проблему политики транзакций.
Во-первых, торговые агенты должны иметь отдельные режимы чтения и записи. Режим чтения может суммировать рынки, сравнивать токены и предлагать действия.
Режим записи должен требовать свежего подтверждения пользователя, ограниченного размера ордера и предварительно одобренного места или получателя. Команда, появившаяся в публичном тексте, никогда не должна наследовать полномочия кошелька только потому, что она соответствует формату естественного языка.
Во-вторых, списки разрешенных получателей должны принудительно применяться кодом вне LLM. Модель может предложить перевод.
Уровень политики должен определять, разрешены ли получатель, токен, сеть, сумма и время. Если какое-либо поле выходит за рамки политики, исполнение должно быть остановлено или передано на проверку человеком.
В-третьих, лимиты расходов должны быть основаны на сеансе и агрессивно сбрасываться. Дневной лимит или лимит на одно действие могли бы уменьшить или заблокировать перевод DRB, в зависимости от политики.
Точное число зависит от баланса и стратегии пользователя, но инвариант проще: ни один агент не должен иметь неограниченных полномочий на трату только потому, что он правильно разобрал команду.
В-четвертых, изоляция локальных ключей должна рассматриваться как жесткая граница. Опытные пользователи, запускающие пользовательские помощники на машинах с доступом к кошельку или бирже, должны отделять эти учетные данные от разрешений помощника на файлы и браузер.
0xDeployer сообщил, что в более ранней версии агента Bankr была жестко закодированная блокировка для игнорирования ответов от Grok, чтобы предотвратить цепочки инъекций запросов LLM-на-LLM. Эта защита не была перенесена в последнюю версию агента, что создало лазейку, позволившую публичному ответу Grok стать исполняемой инструкцией Bankr.
Deployer сообщил, что Bankr с тех пор добавил более сильную блокировку для учетной записи Grok и указал операторам агентских кошельков на уже доступные владельцам учетных записей средства контроля, включая белые списки IP-адресов для API-ключей, разрешенные API-ключи и переключатель на учетную запись, который отключает исполнение Bankr из ответов X.
Помощник может подготовить черновик транзакции. Его должна одобрить другая поверхность кошелька.
Трейдер может отслеживать общие экраны активов и Bitcoin и Ethereum, но риск агента зависит от границ разрешений больше, чем от направления рынка.
Предыдущие материалы CryptoSlate о потоках в экономике агентов, агентах генеративного ИИ, автономных платежах агентов и криптопродуктах, подключенных к MCP, показывают, как быстро агенты приближаются к финансовой деятельности.
Урок безопасности заключается в пути авторизации. Рассматривайте вывод модели как недоверенный до тех пор, пока отдельный уровень политики не проверит намерение, полномочия, получателя, актив, сумму и подтверждение пользователя.
Инъекция запросов будет постоянно менять форму через кодированный текст и многоэтапные взаимодействия агентов. Защита должна находиться там, где авторизуется транзакция, до того, как кошелек подпишет ее.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Liam 'Akiba' Wright
