Исследователи из Noma Security продемонстрировали технику атаки GitLost, позволяющую извлечь содержимое приватных репозиториев организации через функцию GitHub Agentic Workflows. Для атаки достаточно создать обычный issue в публичном репозитории — без украденных учётных данных и без какого-либо доступа к организации. Если AI-агент настроен с правами чтения приватных репозиториев, злоумышленник может заставить его опубликовать конфиденциальные данные в публичном комментарии. Организациям, использующим предварительную версию Agentic Workflows, следует немедленно ограничить область действия токенов агентов до одного репозитория.
Механизм атаки
GitHub Agentic Workflows — функция, запущенная в феврале 2026 года в режиме публичного предварительного просмотра. Вместо написания скриптов автоматизации пользователь описывает инструкции для AI-агента на естественном языке в Markdown-файле. Агент самостоятельно читает issues и pull requests, запускает инструменты и публикует ответы. В качестве движка может использоваться GitHub Copilot, Anthropic Claude, Google Gemini или OpenAI Codex.
По умолчанию рабочие процессы работают в режиме «только чтение», однако организация может предоставить агенту персональный токен доступа с правами чтения всех репозиториев, включая приватные. Именно эту конфигурацию эксплуатирует GitLost.
В основе атаки лежит непрямая инъекция промптов (indirect prompt injection) — AI-агент не способен надёжно отличить инструкции от владельца от инструкций, внедрённых в обрабатываемый контент. По данным исследователей, в демонстрации PoC вредоносный issue был замаскирован под рутинный запрос от вице-президента по продажам после встречи с клиентом. Рабочий процесс был настроен на активацию при назначении issue, чтение его содержимого и публикацию ответа в комментарии. После автоматического назначения агент извлёк README из приватного репозитория и вставил его содержимое в публичный комментарий.
Обход защитных механизмов
GitHub предусмотрел защиту именно от такого класса атак. Согласно официальной документации, платформа предупреждает, что «AI-агенты могут быть подвержены манипуляции через инъекцию промптов, вредоносное содержимое репозиториев или скомпрометированные инструменты». Продукт включает песочницу, токены только для чтения по умолчанию, очистку входных данных и этап обнаружения угроз, который сканирует выходные данные агента перед публикацией.
Тем не менее, как сообщают исследователи Noma, для обхода защиты оказалось достаточно добавить одно слово — «Additionally» — перед вредоносной инструкцией. Модель интерпретировала её как продолжение задачи, а не как подозрительную команду, и защитный фильтр пропустил вывод. Следует отметить, что этот конкретный обход подтверждён только исследователями Noma и пока не воспроизведён независимо.
Почему эта атака принципиально отличается
По словам Саси Леви, руководителя исследований безопасности в Noma Security, ключевое отличие GitLost от предыдущих примеров инъекций промптов — в том, что атака манипулирует не тем, что агент говорит, а тем, что агент делает со своими полномочиями. Агент в данном случае — не окно чата, а аутентифицированный актор внутри инфраструктуры организации с правами чтения репозиториев, недоступных атакующему.
Эта конфигурация соответствует модели, которую исследователь Саймон Уиллисон назвал «смертельной триадой»: агент имеет доступ к приватным данным, принимает непроверенный внешний ввод и располагает каналом для вывода данных наружу. Сочетание всех трёх условий создаёт путь утечки.
Контекст: системная проблема AI-агентов
GitLost — не изолированный случай, а часть серии аналогичных атак на AI-агентов в экосистеме GitHub. В мае 2025 года Invariant Labs продемонстрировали, что публичный issue может заставить агента, подключённого к MCP-серверу GitHub, прочитать приватный репозиторий и вывести данные через pull request. Исследователи охарактеризовали проблему как архитектурную, без возможности серверного исправления.
Кросс-вендорное исследование Comment and Control показало, что агенты Claude Code, Gemini CLI и GitHub Copilot могут быть вынуждены раскрыть собственные API-ключи через текст issues и pull requests, обходя при этом добавленные GitHub средства защиты времени выполнения.
Леви подчёркивает, что это не тот тип ошибки, который закрывается патчем — это структурное следствие предоставления AI-агентам постоянных учётных данных при одновременной обработке ими текста, доступного злоумышленнику. В естественном языке нет чёткой границы между данными и инструкциями, как в SQL, поэтому решение должно опираться на архитектуру, а не на фильтрацию.
Оценка воздействия
Область воздействия ограничена организациями, которые одновременно: включили предварительную версию Agentic Workflows, настроили агента на обработку непроверенного публичного ввода и предоставили ему права чтения приватных репозиториев. Однако для таких организаций потенциальные последствия серьёзны — в зависимости от области действия токена агент может раскрыть проприетарный исходный код, внутренние ключи, проектную документацию или секреты CI/CD.
Рекомендации по защите
- Ограничьте область действия токена: персональный токен доступа, используемый рабочим процессом, должен быть ограничен единственным репозиторием, который обслуживает агент, а не предоставлять доступ на уровне всей организации.
- Ограничьте выходные каналы: минимизируйте возможности публикации для рабочих процессов, обрабатывающих публичный ввод — комментарий агента является каналом эксфильтрации.
- Фильтруйте авторов: настройте ограничения на то, от каких авторов агент принимает контент для обработки.
- Внедрите ручную проверку: поставьте выходные данные агента за этап человеческого одобрения перед публикацией.
- Не полагайтесь на фильтры как на границу безопасности: встроенный этап обнаружения угроз GitHub — это дополнительный рубеж, а не надёжный барьер, как показал обход одним словом.
Noma раскрыла GitLost GitHub и опубликовала результаты с ведома компании. Пока функция Agentic Workflows остаётся в режиме предварительного просмотра, организациям, использующим её, следует исходить из принципа минимальных привилегий: каждый AI-агент должен иметь доступ только к тому репозиторию, который он непосредственно обслуживает, а любой вывод в публичное пространство — проходить через ручное подтверждение.
