Более 20 тысяч аккаунтов Instagram, включая неактивный аккаунт Белого дома времен Обамы, захватили без эксплойтов и без подбора паролей. Атакующим хватило вежливо попросить AI-помощника Meta привязать к чужому аккаунту их почту и отправить туда ссылку для сброса пароля. Для тех, кто строит AI-сервисы, автоматизирует саппорт или подключает агентов к CRM и платежам, это неприятное, но полезное напоминание: безопасность AI-агентов рушится не на уровне модели, а там, где в коде так и не появились обязательные проверки.
О схеме сообщает Stack Overflow Blog. По описанию инцидента, AI-ассистент Meta действовал ровно так, как ему разрешили: менял recovery email и запускал сброс пароля. Ошибка была не в «галлюцинации» модели и не в том, что она якобы «взломала» систему. Критическая проверка должна была подтвердить, что новый email привязывает владелец аккаунта, но этот шаг просто не сработал. Иначе говоря, система рассчитывала на здравый смысл человека в саппорте, а когда на его место поставили агента, выяснилось, что никакого программного барьера там не было.
Это важная разница, которую рынок до сих пор любит игнорировать. Когда человек в поддержке видит просьбу перенаправить восстановление доступа для заметного аккаунта на чужой адрес, он может насторожиться и отказать. У него есть контекст, интуиция, подозрительность и страх сделать глупость. У агента ничего этого нет. Он получает текст, превращает его в последовательность разрешенных вызовов и выполняет их. Если право на действие завязано на самом факте, что агент умеет вызвать функцию, а не на том, кто именно запросил операцию, то это уже не защита, а декорация.
В терминах security это классическая проблема confused deputy, «запутавшегося посредника». Привилегированный процесс делает что-то от имени того, кто на самом деле не имел на это прав. История старая, но в случае с LLM она получает новый интерфейс: естественный язык. API-запрос хотя бы несет с собой идентичность вызывающей стороны. Фраза в чате сама по себе не несет ничего. Если перед вызовом инструмента система заново не привязывает действие к проверенному principal, агент действует на своей собственной авторизации. Для атакующего это почти идеальный расклад: не нужно ломать защиту, достаточно убедить того, у кого уже есть доступ.
У этой истории есть и второй слой. AI-агенты плохо различают инструкцию и данные. Для модели все, что попало в контекст, потенциально выглядит как команда: сообщение пользователя, письмо, документ, заметка из CRM, фрагмент веб-страницы. Поэтому проблема не ограничивается чатом поддержки, где кто-то напрямую просит сбросить пароль. Если агент обрабатывает загруженный файл, суммирует переписку или читает тикет, вредная инструкция может приехать туда как часть контента. В материале это описано как следующий, более опасный класс атак: не грубое «сделай вот это», а команда, спрятанная в данных, которые агенту поручили разобрать.
Плохая новость в том, что радиус поражения быстро растет. В случае с Instagram ущерб был серьезный, но все же ограниченный перехватом аккаунтов. Проблема становится заметно дороже, когда агент умеет не только отвечать в чате, но и работать с бизнес-системами. Stack Overflow Blog напоминает: на той же неделе, когда Meta отключила проблемный инструмент поддержки, компания запустила Business Agent, который может записывать клиентов, квалифицировать лиды, закрывать продажи, принимать оплату и работать с системами вроде Shopify и Zendesk. Если ту же логику «запутавшегося посредника» перенести в платежи, заказы и клиентские записи, последствия уже другие: возврат уходит не тому человеку, заказ перенаправляется, цена меняется без права на скидку, карточка клиента редактируется на основании убедительной, но ложной команды.
На этом фоне цифра Gartner звучит не как красивый прогноз, а как ускоритель будущих инцидентов. Аналитики ожидают, что к концу 2026 года 40% корпоративных приложений будут включать task-specific AI agents, тогда как в начале года таких систем было меньше 5%. Это означает простую вещь: многие компании сейчас массово вставляют агента туда, где раньше сидел сотрудник, но не формализуют его проверки в коде. Они автоматизируют действие, не автоматизируя суждение, на котором действие раньше держалось. А потом удивляются, что агент «слишком послушный».
Именно поэтому разговоры о том, что «нужна модель получше», бьют мимо цели. Более сильная модель в той же архитектуре отдала бы те же аккаунты, только более вежливо и, возможно, с лучшей формулировкой ответа. Авторизация не должна жить в промпте, потому что промпт контролирует атакующий. Она не должна жить и в самой модели, потому что модель интерпретирует вход, а не устанавливает права. Решение скучное и старомодное: каждый чувствительный вызов должен проверять, кто именно инициирует действие, откуда пришел запрос и имеет ли этот принципал право менять конкретный ресурс. Если проверка ownership не проходит, операция не выполняется, как бы убедительно ни выглядел диалог.
Отсюда и практический вывод для разработчиков, продактов и ИТ-руководителей. Если агенту выдали постоянный широкий доступ, он рано или поздно попробует воспользоваться всем, что допускают его токены. Значит, права должны быть короткоживущими и узкими: токен на чтение открытых тикетов не должен годиться для возврата денег или изменения email восстановления. Необратимые действия вроде удаления, платежей, смены прав и восстановления аккаунта лучше выносить за отдельный барьер, который агент не может пройти одной лишь правильной формулировкой. И еще один момент, о котором обычно вспоминают после инцидента: каждое действие агента должно быть привязано к сессии, пользователю и конкретному запросу, чтобы аномалии было видно сразу, а не через шесть недель, как в истории с Instagram.
Для рынка это, пожалуй, самый неприятный, но самый полезный урок года: AI-агенты не ломают вашу модель безопасности, они показывают, где ее никогда не было. Пока компании будут переносить в автоматизацию только кнопки и API-вызовы, оставляя человеческую осторожность «где-то между строк», подобных историй станет больше. Вопрос уже не в том, пустят ли агента в критичные процессы, а в том, успеют ли команды превратить человеческое «это выглядит подозрительно» в конкретные проверки, правила и журналы действий до следующей волны внедрений.