Первые 24 часа инцидента безопасности с «AI agent»

Бо́льшая часть того, что я читаю о безопасности AI-агентов, строится по одному шаблону: таксономия рисков, перечень принципов управления и призыв «внедрять ответственные практики ИИ». Это годится для презентации совету директоров. Но это почти бесполезно в два часа ночи, когда автономный агент с действующими учётными данными только что совершил нечто, на что никто не давал разрешения, и кто-то спрашивает меня, что делать дальше.

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

Почему для агентов время идёт иначе

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

Собственный отчёт Anthropic о кампании GTG-1002 — самая наглядная иллюстрация из тех, что я встречал. Китайская государственная группировка манипулировала Claude Code, пытаясь внедриться примерно в 30 организаций, и, по сообщениям, ИИ выполнил бо́льшую часть тактической работы при минимальном участии человека. Когда я впервые прочитал этот отчёт, меня поразила не атрибуция, а темп. Это не фишинговое письмо, которое лежит в почтовом ящике сутки, прежде чем кто-то по нему щёлкнет. Это компрометация, которая масштабируется сама, пока моя команда ещё только получает оповещение.

За несколько месяцев до этого исследователи из Aim Security раскрыли EchoLeak — уязвимость нулевого клика для prompt-инъекций в Microsoft 365 Copilot с оценкой CVSS 9,3 — такой уровень критичности, при котором моя команда обычно бросает всё. Одно специально сфабрикованное письмо, обработанное во время рутинной сводки, было способно запустить кражу данных из OneDrive, SharePoint и Teams без какого-либо взаимодействия с пользователем. Никакой ссылки для изоляции. Никакого вложения для детонации. Просто контент, который агент был запрограммирован читать, — именно тот класс риска, который OWASP LLM Top 10 теперь ставит на первое место среди угроз для таких систем.

И проблема радиуса поражения — не гипотетическая. Анализ Obsidian Security компрометации OAuth Salesloft-Drift показывает, как одно скомпрометированное подключённое приложение каскадом затронуло сотни нижестоящих SaaS-сред. Я ожидаю, что этот сценарий будет ухудшаться, а не улучшаться, когда агенты начнут держать токены и цепочками вызывать инструменты в разных системах от нашего имени.

Что объединяет эти инциденты — структурная особенность, которая заставила меня перестроить подход к первым суткам: атакующим может быть набор инструкций, встроенных в документ, отравленный ответ инструмента или манипулируемое хранилище памяти, а не человек, сидящий за клавиатурой. Сдерживание означает отзыв идентификатора и разрыв доступа к инструментам. Это не означает изоляцию хоста, по крайней мере не в первую очередь, и мне приходилось поправлять коллег прямо во время инцидента, когда они инстинктивно тянулись к сетевому кабелю.

Почасовой план действий

Час 0: Понять, на что я на самом деле смотрю

Отсчёт начинается с обнаружения, и именно на обнаружении я чаще всего теряю больше всего времени. Инциденты с агентами редко вызывают срабатывания, на которые настроен мой SOC. Я ищу аномальный объём вызовов инструментов от одного идентификатора агента, действия агента за пределами объявленной области задачи (агент для сводки писем внезапно запрашивает файловый ресурс) или выходные данные, которые ссылаются на инструкции, которые не давал ни один оператор-человек. Моя задача на этом этапе — триаж, а не диагноз: это одна скомпрометированная сессия, общие учётные данные или системный вектор prompt-инъекции, сидящий в документе, который может обработать любой агент?

Часы 0–1: Сдерживание по идентификатору, а не по хосту

Вот где, как я видел, традиционные сценарии реагирования на инциденты чаще всего ошибаются в случае агентов. Выдёргивание сетевого кабеля ничего не даёт, если ущерб уже нанесён через вызов API в трёх системах отсюда. Я немедленно отзываю или приостанавливаю учётные данные агента, ключи API и токены OAuth — точно так же, как я бы поступил со скомпрометированной сервисной учётной записью. Я завершаю активную сессию, если уровень оркестрации это поддерживает. Я замораживаю, но не удаляю хранилище памяти агента и историю вызовов инструментов — потому что мне понадобится каждая их часть позже. И если агент работает через брокер или шлюз, я отключаю его зарегистрированные инструменты там, а не гоняюсь за отдельными нижестоящими системами по одной.

Часы 1–4: Оценить радиус поражения

Теперь я отвечаю на вопрос, к чему агент на самом деле прикоснулся. Я извлекаю полный журнал вызовов инструментов — каждый вызванный API, каждый переданный параметр, каждый полученный ответ — и перекрёстно сверяю его с правами доступа агента, чтобы увидеть, к чему он мог получить доступ, а к чему действительно получил. Я также проверяю, не создали ли действия самого агента новые артефакты по ходу дела: запланированную задачу, правило пересылки, новый ключ API — потому что автономные агенты часто лучше умеют закрепляться в системе, чем люди, которые их создали. Если вектор проникновения похож на косвенную prompt-инъекцию, я пытаюсь идентифицировать все другие сессии, которые обработали тот же отравленный контент. Это редко бывает событием с одной жертвой.

Часы 4–8: Уведомить до того, как я буду уверен

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

Часы 8–16: Реконструировать цепочку решений

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

Часы 16–24: Принять решение о восстановлении и сначала что-то изменить

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

Что, как я понял, отличает восстановление от повторных инцидентов

Методологии рисков говорят нам, что агентам нужен доступ с минимальными привилегиями и контроль со стороны человека. Я согласен, но также обнаружил, что это неприменимо в первый час, когда оповещение приходит мне. Что мне на самом деле нужно в комнате — это операционная последовательность: сдерживать по идентификатору, прежде чем сдерживать по хосту; замораживать доказательства, прежде чем закрывать уязвимость; уведомлять, прежде чем быть уверенным; и никогда не восстанавливать ту самую конфигурацию, которая только что вышла из строя. Каждый раз, когда я видел, как команда хорошо справляется с инцидентом класса EchoLeak или GTG-1002, это было не потому, что у них на стене висела лучшая таксономия рисков. А потому, что они уже отрепетировали первые 24 часа до того, как они им понадобились.

Вот чего, я думаю, нашей индустрии всё ещё не хватает. Мы потратили два года на написание принципов управления агентами. Я бы предпочёл провести следующий год, проводя штабные учения на время, потому что следующий инцидент не будет ждать, пока моя политика догонит его.