Уязвимость AgentForger в ChatGPT: как URL создавал опасного агента
Zenity показала, как специально подготовленная ссылка могла создать и запустить Workspace Agent с уже подключёнными сервисами. OpenAI исправила проблему 8 июня.
По состоянию на 23 июля 2026 года AgentForger — исправленная уязвимость в ChatGPT Workspace Agents. Специально подготовленный URL мог в сессии вошедшего пользователя создать и запустить управляемого атакующим агента с доступом к уже подключённым корпоративным сервисам. Компания Zenity сообщила о проблеме OpenAI 4 июня, а 8 июня уязвимость была закрыта.
Для атаки требовался клик по ссылке, доступ пользователя к Workspace Agents и хотя бы один ранее авторизованный коннектор. Новых OAuth-разрешений уязвимость не выдавала. Исследователи не сообщали о массовом применении AgentForger в реальных атаках.
Ценность показанного сценария — в устройстве цепочки. Один URL запускал создание системы, которая могла работать по расписанию, читать почту и файлы, отправлять сообщения и получать новые команды без повторных действий пользователя.
Как работала цепочка AgentForger
Исследователи Zenity отнесли AgentForger к CSRF, то есть к подделке межсайтового запроса. Уязвимость находилась в конструкторе Workspace Agents: параметры template_name и initial_assistant_prompt позволяли передать шаблон и начальную инструкцию через URL. Второй параметр автоматически отправлял эту команду конструктору.
Дальше Builder выполнял цепочку как обычную задачу: создавал агента, подключал доступные интеграции, менял правила подтверждения действий, публиковал конфигурацию и добавлял расписания. Полную вредоносную инструкцию и рабочую ссылку мы не приводим: для понимания риска достаточно разобрать границы доверия.
| Этап | Необходимое условие | Практический риск | Подтверждение |
|---|---|---|---|
| Переход по URL | Пользователь вошёл в ChatGPT и сам нажал подготовленную ссылку | Builder открывался в его активной сессии | Zenity, часть 1 |
| Запуск Builder | В URL были параметры шаблона и начальной инструкции | Команда атакующего автоматически отправлялась конструктору | Zenity, часть 1 |
| Подключение сервисов | Почта, Slack, Drive, SharePoint или Teams уже были разрешены пользователем | Агент получал существующий доступ без нового окна OAuth | Zenity; OpenAI |
| Изменение подтверждений | Builder мог исполнять команды, связанные с настройками безопасности | Для доступных действий режим Always ask менялся на Never ask | Zenity; OpenAI |
| Работа по расписанию | Агент публиковался с несколькими часовыми расписаниями, сдвинутыми на пять минут | В исследовательском стенде он фактически запускался каждые пять минут | Zenity, часть 1 |
По данным Zenity, OpenAI устранила первопричину через четыре дня после сообщения: параметр, позволявший автоматически запускать инструкцию из URL, был удалён до публичного раскрытия 23 июля.
Почему это не обычная prompt injection
В prompt injection вредная инструкция обычно попадает в контекст уже работающей модели через письмо, документ или веб-страницу. AgentForger начинался раньше: URL заставлял конструктор создать новую конфигурацию в авторизованной сессии пользователя. Термин CSRF или cross-site agent forgery точнее описывает этот механизм, чем классическая подмена промпта.
Разница влияет на защиту. Фильтрация входящего текста агента не решает проблему, если атакующий может управлять самим этапом создания, набором инструментов, правилами подтверждения и расписанием. И наоборот, режимы защиты от prompt injection нельзя объявлять универсальным лекарством от AgentForger. В отдельном материале мы разбирали, как OpenAI ограничивает высокорисковые действия и prompt injection, но компания не заявляла, что Lockdown Mode был специальной защитой от этой цепочки.
Что мог делать созданный агент
После публикации почта становилась каналом команд. Агент искал письма от заданного адреса с темой, начинающейся на TASK, выполнял инструкции через подключённые сервисы и отправлял результат обратно. Несколько расписаний обеспечивали повторный запуск без новых кликов.
Во второй части исследования Zenity показала несколько сценариев на тестовом рабочем пространстве. Агент собирал карту сотрудников и проектов по почте, календарю, Slack и Teams; искал чувствительные документы в Drive и SharePoint; находил пароли в сообщениях; отправлял внутренние фишинговые сообщения и готовил сценарий компрометации деловой переписки.
Zenity проводила эти демонстрации на исследовательском стенде; подтверждённого отчёта о взломе реальной компании нет. Стенд показал, как один агент объединяет данные и действия из разных сервисов. По отдельности каждый коннектор выглядел легитимным, а вместе они давали удобный маршрут от разведки до отправки сообщения от имени сотрудника.
Какие пользователи находились в зоне риска
AgentForger не давала доступ к произвольной компании и не работала без участия человека. Для успешной цепочки одновременно требовались четыре условия:
- активная сессия ChatGPT;
- доступ к Workspace Agents;
- клик по подготовленной ссылке;
- хотя бы один ранее авторизованный корпоративный сервис.
Workspace Agents предназначены для повторяемых рабочих процессов. По текущей документации OpenAI, их можно связывать с приложениями и инструментами, запускать по расписанию и через API, публиковать для команды и подключать к Slack. В мае OpenAI также добавила административную аналитику и ролевое управление. Контекст продукта подробнее разобран в нашем материале о том, как устроены Workspace Agents в ChatGPT.
Уязвимость возникла в пути, по которому внешняя ссылка могла инициировать создание агента и изменить чувствительные настройки без осознанного подтверждения пользователя. Штатные функции автономности лишь увеличивали последствия.
Нужно ли отключать Workspace Agents сейчас?
Оснований для общего призыва отключить Workspace Agents нет: уязвимость исправлена 8 июня 2026 года, за шесть недель до публичного раскрытия. Zenity и OpenAI не сообщали о массовой эксплуатации AgentForger.
Исправление URL-параметра, однако, не заменяет аудит конфигураций. Компаниям полезно проверить, какие агенты созданы, кто ими владеет, какие приложения к ним подключены, какие действия разрешены без подтверждения и какие расписания активны. В актуальной документации OpenAI для записывающих действий по умолчанию указан режим Always ask; Never ask и пользовательские правила требуют отдельного внимания.
Что проверить администраторам и владельцам агентов
Ниже — редакционный чеклист на основе исследования Zenity и действующей документации OpenAI. Он предназначен для минимального аудита после раскрытия; данных об активной атаке у нас нет.
- Просмотреть список созданных Workspace Agents и найти незнакомые названия, владельцев или недавние публикации.
- Проверить все расписания, особенно несколько похожих запусков со сдвигом по времени.
- Сверить список подключённых приложений и удалить те, которые не нужны для конкретной задачи агента.
- Вернуть Always ask для отправки, изменения, публикации и удаления данных, если автоматическое действие не обосновано рабочим процессом.
- Для общих подключений завести сервисные учётные записи, выдать им минимальные права и не использовать личные аккаунты.
- Проверить журналы запусков, необычные поисковые запросы, обращения к нескольким хранилищам сразу и неожиданные исходящие письма или сообщения.
OpenAI отдельно предупреждает, что общие подключения могут позволить другим пользователям действовать от имени владельца учётной записи. В документации компания рекомендует принцип минимальных прав, ограничение аудитории и регулярный аудит конфигураций. Эти меры полезны и после устранения AgentForger, потому что снижают последствия любой ошибки в логике агента или его настройках.
AgentForger показала практическую границу: защита автономного агента начинается до первого запуска. Контролировать нужно создание, инструменты, подтверждения, расписания и журнал действий как одну систему. Похожие риски возникают и в других продуктах, где AI-агенты становятся целью атак через инструкции.
