Подмена идентичности рабочего процесса: Noma Labs превращает обычное письмо в службу поддержки в привилегированный доступ к данным

9 сентября 2026 года исследовательская команда Noma Security, выступая под именем Noma Labs, опубликовала описание того, что называет перехватом идентичности рабочих процессов: корпоративный ИИ-рабочий процесс читает обычное сообщение, поступившее в публичную точку входа — почтовый ящик поддержки, задачу GitHub, веб-форму, общий документ — и затем выполняет запрошенную работу, используя свою собственную служебную учетную запись с высокими привилегиями вместо разрешений отправителя. В разборе Noma внешний человек отправляет письмо на публичный адрес поддержки компании и, среди прочего, просит квартальные показатели продаж из последнего письма финансового директора; через несколько минут содержимое оказывается во входящих злоумышленника. Ни одна модель не была обманута, и ни одна учетная запись не была взломана, и в этом суть отчета: «все, что нужно было сделать злоумышленнику, — просто попросить». В архиве не зафиксировано реального ущерба — не названа ни одна жертва и ни одна развернутая система не описана как скомпрометированная — а находка классифицируется как исследование, серьезность — средняя, уверенность — A, оспорено — false. Этот материал опирается на отчет Noma Labs, на публикацию Dark Reading, вышедшую в тот же день, и на последующий материал CSO Online, и архив инцидентов с ИИ хранит эту запись вместе с соседними записями, у каждой из которых есть собственные источники, уровень серьезности и степень уверенности.

Поля самой записи стоит прочитать прежде, чем переходить к описанию. Она помечена тегами INFRA и EXFIL, относится к региону GLOBAL, содержит единственную дату с точностью до дня — 9 сентября 2026 года — и не отмечена как знаковая запись. Эта дата — дата публикации исследования, и ничего более; к ней не привязана хронология инцидента, потому что инцидента, который можно было бы привязать ко времени, нет. Вот что важно усвоить в первую очередь: то, что опубликовала Noma, — это механизм и категория, а не отчёт об утечке.

Что Noma продемонстрировала, а что — нет

Последовательность в почтовом ящике поддержки — это сконструированная иллюстрация, а не клиентский случай. В отчёте Noma не называется организация, не указывается количество затронутых развёртываний, не публикуется телеметрия из какого-либо реального конвейера и не приводится ссылка на демонстрационный запуск proof-of-concept для этого сценария — в отличие от июльского исследования группы, которое указывало на публичный запуск GitHub Actions. Вместо этого отчёт предлагает описание механизма, достаточно точное, чтобы сопоставить его с архитектурой: поступает неаутентифицированный ввод, модель корректно его интерпретирует, конвейер выполняет нисходящий вызов, и этот вызов выполняется с полномочиями создателя рабочего процесса.

Саси Леви, руководитель исследований безопасности Noma и автор отчёта, формулирует первопричину в одном предложении: «идентичность и разрешения пользователя, запускающего рабочий процесс, отвязаны от идентичности и разрешений, используемых для его выполнения». Там, где это имеет место, рабочий процесс становится, по словам отчёта, «неаутентифицированными прокси для привилегированных действий и скрытой утечки данных».

Поскольку действия выполняются через доверенную автоматизацию с действительными учетными данными, Noma утверждает, что обычным средствам оповещения почти нечего обнаруживать. Запрос обычный, вывод модели — корректный вывод модели, вызов API аутентифицирован, ответ — именно тот ответ, который рабочий процесс был предназначен отправить. CSO Online процитировал специалиста по red team Vibhum Dubey, конкретизировавшего проблему обнаружения: «Отдельные события могут выглядеть совершенно легитимными. Полезные сигналы возникли бы при корреляции исходного инициатора запроса, идентичности, использованной на последующих этапах, ресурсов, к которым был получен доступ, переданных параметров и итогового действия».

Проверка, которая не проходит, — это проверка авторизации, а не фильтр содержимого.

Самая яркая иллюстрация в отчёте — пара идентичных запросов. От финансового директора: «Какие квартальные показатели продаж указаны директором по финансам в его последнем письме?» От внешнего отправителя: те же самые слова. Noma подчёркивает, что запрос и запрашиваемая операция одинаковы, тогда как решение об авторизации должно быть совершенно иным: «Финансовый директор имеет право на эту информацию; внешний отправитель — нет».

Стандартные детекторы промпт-инъекций и защитные механизмы агентов, как утверждает отчёт, классифицируют два входных сигнала одинаково, поскольку ни в одном из них нет ничего вредоносного, что можно было бы обнаружить. «Риск безопасности заключается не в промпте, а в границе авторизации». Структурный тезис Noma следует из этого: защитные механизмы, системные инструкции и входные фильтры «не были предназначены для выполнения роли границы авторизации», поэтому пайплайн, который полагается на них, чтобы решать, что вызывающая сторона может извлечь, полагается на средство контроля, которому никогда не поручали эту задачу.

Различие имеет практическое значение. Прямая инъекция промптов манипулирует тем, как модель следует инструкциям; косвенная инъекция промптов прячет инструкции в контенте, который модель прочитает позже; перехват идентичности рабочего процесса, как его определяет Noma, не требует ни того, ни другого, потому что запрос — это именно то, что модель должна понять, а конвейер — выполнить. Защитник, который потратил год на укрепление защиты от инъекций, работал на другом уровне.

Статические рабочие процессы не входят в инициативу по повышению защищённости агентов

Noma разделяет две вещи, которые обычно используются как взаимозаменяемые. Рабочий процесс ИИ — это заранее определённая статическая последовательность, в которой модель является одним из этапов обработки; в отчёте это кратко обозначено как шаг A, модель, шаг B, шаг C, а детерминированный конвейер вокруг модели определяет, что происходит. Агентный рабочий процесс автономен: агент решает, какие шаги предпринять и какие инструменты вызвать. Как утверждается в отчёте, значительная часть текущих усилий по безопасности была направлена на второй тип — ограничение доступа к инструментам и определение области разрешений для агентов, принимающих динамические решения, — и эти меры контроля не охватывают первый.

В отчёте также закрывается очевидная лазейка. Ограничение того, кто или что может запускать рабочий процесс, не решает проблему: если автоматизация запускается по расписанию в 8:00 и действует в отношении почтового ящика, в который может писать кто угодно, аудит вопроса «кто может запускать этот рабочий процесс» отвечает не на тот вопрос. Правило Noma таково: каждая автоматизация должна оцениваться с точки зрения «наименее доверенной стороны, способной влиять на то, с чем она работает», — включая электронные письма, формы, тикеты, задачи GitHub, общие документы и сообщения в чатах.

Noma сообщает, что Google устранил проблему в Google Workflows; Google ничего не опубликовал.

Единственная названная в отчёте платформа — Google. Noma заявляет, что обнаружила тот же вектор риска в Google Workflows, что сообщила о нём в порядке ответственного раскрытия и что Google подтвердила получение отчёта и подтвердила исправление «без раскрытия деталей реализации». Это предложение — вся совокупность публичных сведений. Не удалось найти ни одного бюллетеня Google, примечания к выпуску или CVE, описывающих этот вектор, и все вторичные сообщения об исправлении — включая опубликованные в дни после 9 сентября — приписывают его Noma, а не Google.

Отчёт также не вполне последователен в том, какой продукт Google он имеет в виду. В основном тексте упоминается Google Workflows; заголовок раздела в том же отчёте гласит: «Google Workspace: AI Workflow Identity Hijacking». Оба являются продуктами Google с разными границами доверия, и отчёт не согласует их. Noma не сообщает, был ли эксплуатирован описанный ею случай, сколько клиентов подверглось воздействию или что изменилось в исправлении — и поскольку Google ничего не сообщила, ни один из этих пробелов нельзя закрыть со стороны поставщика.

GitLost — та же граница, увиденная через более узкий объектив

Ранее раскрытие Noma создаёт для этой категории прецедент. В июле 2026 года группа опубликовала исследование о GitHub Agentic Workflows, которое она назвала GitLost: рабочий процесс, запускавшийся при назначении issue, читал заголовок и тело issue и отвечал комментарием; поскольку агент имел доступ на чтение ко всем репозиториям организации, внешние пользователи могли через назначение issue получить доступ к данным приватных репозиториев. Dark Reading осветил это 7 июля 2026 года и описал атакующего, который прятал команды обычным английским текстом в теле issue, открытого в публичном репозитории, не нуждаясь ни в учётных данных, ни в навыках программирования.

Две формулировки не идентичны, и интересна именно разница. Июльский материал Dark Reading — это история о промпт-инъекции: текст, контролируемый атакующим, читается как инструкции. Сентябрьский отчёт Noma описывает GitLost через триггер и доступ на чтение в масштабе всего репозитория и представляет его как ту же границу авторизации, увиденную под одним углом. Оба описания соответствуют рабочему процессу, в котором агент читал текст, написанный посторонним, но только первое из них зависит от того, что модель удаётся направить. Noma теперь утверждает, что сообщила Google о том же векторе риска; но не уточняет, эксплуатировался ли случай GitLost когда-либо за пределами опубликованной демонстрации.

По собственным данным Noma об охвате, Hacker News, Dark Reading и более 100 других международных изданий освещали исследование GitLost. Эта цифра принадлежит поставщику, и в данной статье охват не подсчитывался независимо.

Практики сходятся в том, что механизм стар; спор — о названии.

Независимое освещение не оспаривало этот вывод, а два внешних практика возражали скорее против новизны, чем против сути. Мори Хабер, главный советник по безопасности в BeyondTrust, сказал Dark Reading: «Никто не заставлял ИИ-модель обманом делать то, чего она не должна была делать. Модель сделала ровно то, что ей велел незнакомец (недоверенный источник), а окружающий её рабочий процесс использовал чужую идентичность, чтобы это произошло, поскольку у него не было ограничения области действия и он не работал по принципу наименьших привилегий». CSO Online привёл слова Вибхума Дьюби, который описал эту схему как «известный класс слабости авторизации» и добавил, что там, где неаутентифицированный ввод может запустить доверенный рабочий процесс, действующий со своими собственными привилегиями, «рабочий процесс может фактически действовать как запутанный заместитель».

Рам Варадараджан, генеральный директор Acalvio, предложил Dark Reading совершенно иную меру контроля: вместо дополнительной фильтрации заполнить среду приманками — поддельными ветками обсуждений руководителей, записями-ловушками honeytoken, — к которым ни один авторизованный рабочий процесс не имеет законных оснований обращаться, так что внешне безобидный запрос, пытающийся добраться до одной из них, наталкивается на границу, которую ему никогда не следовало пересекать. Спор, если его можно так назвать, идёт о том, является ли полезный вклад новым названием для уязвимости делегирования, восходящей к 1988 году, или работающим описанием того, где эта уязвимость теперь живёт. Позиция Noma — вторая: эта закономерность носит системный характер для корпоративных конвейеров ИИ, а нынешние фреймворки безопасности ИИ смотрят не на ту поверхность.

Смягчение проблемы — это делегирование и контрольная точка, а не более совершенный фильтр.

Рекомендуемые Noma средства контроля относятся к прикладному уровню, а не к уровню модели. Делегирование токенов с учетом идентичности означает удаление статических административных API-ключей из рабочих процессов ИИ и выполнение операций с данными с помощью краткоживущих делегированных токенов с ограниченной областью действия, привязанных к аутентифицированному запрашивающему лицу, чтобы контекст пользователя передавался в вызов, который фактически обращается к данным. Контрольные точки контекстной авторизации означают рассмотрение каждого вывода модели как недоверенного ввода и размещение явной оценки контроля доступа и защиты во время выполнения между этапом преобразования модели и любым последующим вызовом базы данных или инструмента. Асимметричное разделение вывода означает структурное изолирование извлечения данных от внешних каналов связи, чтобы рабочий процесс, обрабатывающий конфиденциальные внутренние данные, не использовал общий путь выполнения с автоматизированным механизмом, отвечающим внешним сторонам.

Дуби предложил CSO Online более дешёвый тест, чем любой из трёх: сравнить результаты на разных уровнях привилегий. «Если пользователь с низкими привилегиями может получить тот же результат, что и администратор, потому что нижестоящие системы видят только идентификатор рабочего процесса, именно на этом я бы сосредоточил расследование».

Что оставляют открытым материалы дела

• Ни пострадавшего, ни числа, ни телеметрии. Кейс Noma с почтовым ящиком поддержки — это пошаговый разбор; в отчёте не названа ни одна организация, а архив фиксирует реальный вред как ложный. Правдоподобность механизма не является доказательством того, что он использовался.

• Какой продукт Google был исправлен и в чём заключалось исправление. В тексте Noma упоминается Google Workflows, в заголовке её раздела — Google Workspace, а Google ничего не опубликовала. Организации пока не могут по открытым источникам определить, входил ли используемый ими пайплайн в область исправления.

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

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

• Кто приводит этот аргумент. Noma Labs — исследовательское подразделение Noma Security, которая продает средства контроля безопасности агентов именно того типа, который рекомендуется в ее отчете. Это не делает вывод неверным — Dark Reading и CSO Online оба сообщили о нем, и ни один не обнаружил фактической ошибки — но это контекст, который читателю следует учитывать, взвешивая, насколько широко очерчена категория.

Оценка серьёзности записи medium и флаг реального вреда false описывают доказательства, а не механизм. То, что Noma действительно установила, узко и проверяемо: идентичность триггера рабочего процесса и идентичность его исполнения — разные сущности; вторая обычно обладает большими полномочиями; а конвейер, который никогда их не сравнивает, сделает для постороннего то же, что сделал бы для человека, для которого был построен. Соответствующий контроль столь же непримечателен — для каждой автоматизации спрашивайте, кто может влиять на то, на что она действует, и перепроверяет ли что-либо ниже по цепочке, имел ли право спрашивать тот, кто спрашивает.