Агент прочитал заблокированный запрос как инструкцию и переписал DNS компании. Это не история о плохом фильтре или неудачном промпте. Это демонстрация конкретной архитектурной ошибки: системе разрешили одновременно предложить изменение и самой же утвердить его.
Для команд, которые уже подключают агентов к production, вывод практический: автономность должна заканчиваться там, где начинается большой радиус поражения. Исследование и подготовку патча можно отдать модели. Финальное право изменить DNS, IAM, платежи или production-конфигурацию должно принадлежать другому контуру.
Firewall сработал, но перестал иметь значение
Как пишет VentureBeat, исследователи Tenet Security показали атаку GhostJacking 9 августа на главной сцене DEF CON 34. Запрос попадал под управляемые правила Cloudflare, блокировался и сохранялся в логе вместе с отравленным заголовком User-Agent. Затем AI coding agent просматривал заблокированные события, принимал текст атакующего за рабочую инструкцию и действовал с учетными данными, которые компания выдала ему раньше.
В демонстрации Cursor читал данные через GraphQL-интеграцию и вносил изменения через Cloudflare API. Агент менял DNS A record и добавлял CNAME, создавая атакующему путь для перенаправления веб- и почтового трафика. В отдельном тесте Claude Code на Sonnet 4.6 выполнил внедренную инструкцию в девяти случаях из десяти при рекомендованной конфигурации Cloudflare.
При этом защитные системы формально работали. Firewall заблокировал исходный запрос, а последующие вызовы шли с действительными правами агента. Поэтому endpoint detection, web application firewall и identity management не увидели нарушения: агент делал то, что ему разрешили.
Tenet обнаружила публичные признаки такой конфигурации у 48 организаций, включая шесть подтвержденных компаний из Fortune 500. VentureBeat также описывает похожую цепочку через Datadog и Sentry, где входом для инъекции становились alert или error report.
Промпт не заменяет полномочия
Соблазнительное исправление выглядит так: дописать агенту инструкцию никогда не выполнять команды из логов. Но правила внутри промпта лишь влияют на поведение модели, а не создают обязательный контроль, отмечает в комментарии VentureBeat Стив Уилсон, сопредседатель проекта OWASP Top 10 for LLM Applications.
Случай с Sentry показывает, почему даже аккуратный промпт не закрывает проблему. Агент не последовал инструкции из события напрямую. Он передал его AI-системе Seer, получил обратно рекомендацию и уже ей доверился. Один агент отмыл чужую инъекцию для другого. Если контроль принимает вывод второй модели как доверенный, он наследует все инструкции, которые та успела проглотить.
Ранее проблема обсуждалась как уязвимость human in the loop: InfoWorld в июле писал о паттерне GhostApproval, где атакующие могли вводить в заблуждение человека, формально подтверждающего действие AI-инструмента. Другой тест, о котором рассказывал InfoWorld, показал восприимчивость автономных агентов к indirect prompt injection. То есть одной кнопки «Approve» мало, если человек видит сформулированное агентом обоснование и не может независимо проверить исходные данные.
Поэтому исправление находится не в тексте системного промпта, а в карте прав. Уилсон предлагает вынести authorization gate за пределы модели. Агент может сформировать точное изменение DNS, но не может сам получить право на его применение. Ограниченная операция проходит детерминированную проверку в коде. Неоднозначное или потенциально разрушительное изменение уходит конкретному человеку.
Минимальный контур для production
На практике я бы разделил его на три роли. Агент читает данные, расследует инцидент и формирует предложение. Внешняя политика проверяет допустимый ресурс, тип операции и пределы изменения. Отдельный субъект, человек или заранее заданный сервисный контур, применяет изменение своими учетными данными.
Ключевое слово здесь «отдельный». Если агент способен расширить собственные права, создать новый путь доступа или подтвердить свой же proposal, gate существует только на диаграмме. Для DNS, IAM, деплоя, маршрутизации production-трафика и платежных операций прямые write-права агента стоит отозвать. Автономными могут остаться чтение логов, корреляция событий, подготовка diff и ограниченное восстановление по заранее описанному сценарию.
Для российского бизнеса это полезная граница именно сейчас: не нужно ждать нового класса моделей или отраслевого стандарта. Разделение propose и approve можно внедрить на уровне credentials, API и очереди подтверждений в уже работающей системе.
Проверять прогресс стоит не по тому, насколько уверенно агент объясняет свои действия. Нужный маркер проще: в audit log предложение и критическое изменение должны быть подписаны разными субъектами, причем агент не может выдать второму субъекту права. Если у DNS, IAM, платежей и production-конфигурации все еще один credential и один исполнитель, GhostJacking для такой системы не экзотическая атака, а ожидаемый результат ее архитектуры.