Угон идентичности workflow превращает корпоративный AI-процесс в прокси с чужими правами: достаточно отправить обычный запрос через публичную точку входа вроде support-почты или веб-формы. Для русскоязычных команд, которые уже прикрутили LLM к Jira, почте, CRM и внутренним базам, это неприятное напоминание: проблема может быть не в модели, а в том, под чьей учеткой она ходит за данными.
О новом сценарии атаки 9 сентября 2026 года сообщает Dark Reading со ссылкой на исследователей Noma Labs. Они назвали технику workflow identity hijacking: злоумышленник не ломает модель и не обязательно использует классический prompt injection, а эксплуатирует разрыв между личностью пользователя, который запускает workflow, и правами сервисного аккаунта, который выполняет дальнейшие действия.
Типовой пример выглядит почти скучно, поэтому и опасен. В компанию приходит письмо на публичный адрес поддержки: внешний пользователь спрашивает что-то про свой аккаунт и добавляет безобидную на вид просьбу, например уточнить, что финансовый директор написал в последнем письме. AI-workflow читает входящее сообщение, понимает запрос, идет искать нужные данные и отправляет ответ туда же, откуда пришло письмо. Если цепочка построена плохо, наружу уходит внутренняя переписка, хотя отправитель не проходил аутентификацию и не имел права видеть эти данные.
Ключевая деталь здесь не в том, что LLM стала слишком послушной. По словам Sasi Levi, руководителя security research в Noma, pipeline выполняет ровно то, для чего его спроектировали: читает входные данные, интерпретирует задачу и вызывает следующий инструмент. Ошибка в другом: система не проверяет, имел ли инициатор право просить это действие. В итоге AI-workflow начинает действовать с правами разработчика, владельца интеграции или сервисного аккаунта, а не с правами внешнего пользователя.
Это важное отличие от prompt injection, вокруг которого последние пару лет крутится большая часть разговоров об AI-безопасности. Там атакующий пытается переубедить модель, подсунуть ей конфликтующую инструкцию или заставить раскрыть скрытый контекст. Здесь модель может вообще не быть обманута. Morey Haber, chief security adviser в BeyondTrust, формулирует проблему проще: незнакомец попросил систему выполнить действие, а workflow сделал это под чужой идентичностью, потому что права не были ограничены принципом наименьших привилегий.
Особенно неприятно, что уязвимыми оказываются не только модные агентные системы, которые сами выбирают инструменты и строят план действий. Noma Labs отдельно разделяет agentic workflows и обычные AI-workflows. Первые более автономны: агент решает, куда идти и какие инструменты подключать. Вторые обычно выглядят безопаснее, потому что это фиксированная цепочка шагов: принять тикет, классифицировать, поискать данные, подготовить ответ. Но угон идентичности workflow как раз бьет по таким предсказуемым цепочкам, если между шагами нет нормальной авторизации.
Для разработчиков и платформенных команд вывод довольно практичный. Нельзя считать LLM-ответ доверенным просто потому, что он появился внутри корпоративного pipeline. После шага, где модель преобразовала письмо, тикет или документ в команду, нужен отдельный authorization checkpoint: кто исходный пользователь, что он может читать, какие операции разрешены, какой инструмент вызывается и с каким scope. Если такой проверки нет, фильтры на входе и DLP на выходе будут выглядеть как красивая сигнализация на двери, рядом с которой оставили открытое окно.
Noma Labs предлагает уходить от статических административных API-ключей в AI-workflow и использовать короткоживущие токены делегирования, привязанные к аутентифицированному пользователю. Еще одна мера — разделять каналы: workflow, который читает чувствительные внутренние данные, не должен напрямую делить execution path с автоматической отправкой ответа во внешний канал. Это звучит менее эффектно, чем очередной guardrail для модели, зато ближе к реальной инженерной гигиене.
Ram Varadarajan, CEO Acalvio, предлагает добавить к защите deception-подход: размещать в среде приманки вроде фальшивых executive-тредов или honeytoken-записей, к которым легитимный workflow не должен обращаться. Если внешний запрос вдруг провоцирует обращение к такой записи, команда безопасности получает сигнал о пересечении границы, которую обычные фильтры могли бы пропустить.
Главный риск для бизнеса в том, что такие атаки плохо похожи на атаку. Нет взломанного VPN, нет подозрительного бинарника, нет драматичного jailbreak в логах. Есть нормальный запрос, нормальный workflow и нормальный ответ, только данные ушли не тому человеку. Чем активнее компании связывают LLM с почтой, issue-трекерами, файловыми хранилищами и BI, тем важнее проектировать AI-интеграции как систему идентичностей и полномочий, а не как умную форму ввода. Угон идентичности workflow показывает, что следующий фронт AI security пройдет не только через модели, но и через скучные на вид сервисные аккаунты, scopes и delegation tokens.