Исследователи Noma Labs 7 июля 2026 года описали сценарий, в котором GitHub AI-агент вытаскивает содержимое приватного репозитория и публикует его в открытом комментарии. Для атаки, получившей имя GitLost, злоумышленнику не нужны ни доступ в организацию, ни токены, ни навыки разработки: достаточно завести issue в публичном репозитории компании и дождаться, пока агент услужливо сделает все сам. Для команд, у которых в одном GitHub-организации живут и open source, и закрытый код, это уже не академическая страшилка, а вполне прикладной риск.
О проблеме GitHub AI-агент сообщает The Register со ссылкой на исследование Noma Labs. Уязвимость нашли в Agentic Workflows — механике GitHub, где ИИ-агент на базе Claude или GitHub Copilot автономно выполняет задачи через GitHub Actions. По версии исследователей, критическая слабость связана с prompt injection: если агенту подсовывают сформулированную обычным языком инструкцию внутри issue, он может интерпретировать ее как валидное задание, сходить в другой репозиторий той же организации, забрать оттуда данные и вернуть их уже в публичное обсуждение.
Сценарий выглядит неприятно именно своей бытовой простотой. Исследователи создали правдоподобный issue якобы от вице-президента по продажам. В тексте попросили заодно проверить содержимое README в публичном репозитории и в другом, приватном. После этого автоматизация GitHub назначила issue, сработал событийный workflow, а агент вытащил README.md из обоих репозиториев и опубликовал их в комментарии под issue в публичном проекте. Иными словами, граница между public и private здесь ломается не через эксплойт в классическом смысле, а через доверчивого цифрового стажера, которому дали слишком широкий доступ и не объяснили, с кем нельзя разговаривать.
Название GitLost здесь тоже не для красного словца. Проблема не сводится к одному неудачному шаблону issue или неверной настройке одного action. Если агент имеет путь к приватным данным и умеет читать входящий текст как инструкцию, prompt injection превращается в системный класс риска. Руководитель исследований Noma Security Саси Леви прямо сказал The Register, что полностью закрыть такую дыру кодом нельзя. Это уже знакомый мотив всей волны «агентного» ИИ: продуктам обещают автономность, а потом выясняется, что автономность без жестких границ доступа слишком похожа на автоматизированную утечку.
Самое показательное в этой истории даже не техника атаки, а реакция платформы. По словам Леви, предложенный вариант исправления сводился хотя бы к документации: предупредить пользователей и рекомендовать иначе выстраивать совместное использование API-ключей и доступов между репозиториями. Но и этого, как отмечает The Register, на момент публикации 7 июля GitHub не сделал. Ответа на запрос издания у платформы тоже не было. Получается типичная для ИИ-инструментов картина: риск уже воспроизводится, proof-of-concept опубликован, исследователи раскрыли детали заранее, а в ответ тишина и надежда, что пользователи сами догадаются не давать агенту лишних полномочий.
Для корпоративной разработки здесь несколько неприятных выводов. Во-первых, публичный репозиторий организации больше нельзя считать безопасной песочницей просто потому, что в нем нет секретов. Если он связан общими workflow, токенами или агентами с приватной частью GitHub-организации, то через него можно дотянуться до закрытых данных косвенно. Во-вторых, стандартная логика «мы же не дали злоумышленнику учетку» больше не работает. В модели с агентами внешнему пользователю иногда достаточно возможности открыть issue или иным способом оставить текст, который система сочтет командой. В-третьих, многие команды до сих пор оценивают ИИ-помощников как улучшенный autocomplete, хотя по факту Agentic Workflows — это уже операционный субъект с доступом к Actions, репозиториям и, потенциально, секретам.
Что это меняет для команд
Если смотреть на GitLost глазами разработчика или DevSecOps-инженера, вопрос стоит не в том, «опасен ли ИИ вообще», а в банальной модели прав. Любой GitHub AI-агент, который работает в контуре организации, должен рассматриваться как высокопривилегированный сервисный аккаунт с крайне капризным интерфейсом управления. Он не просто запускает команды, а еще и принимает решения на основе текста, написанного кем угодно. Значит, аудит нужен сразу по нескольким линиям: какие репозитории доступны агенту, какие GitHub Actions он может запускать, какие секреты доступны этим workflow, что происходит при обращении из public repo к данным private repo, и может ли агент публиковать результаты наружу без ручного подтверждения.
Для бизнеса это тоже не узкоспециализированная история про безопасность «где-то там у инженеров». Во многих компаниях публичные репозитории используются для SDK, документации, примеров интеграции, вакансий и внешних инициатив. Приватные — для продукта, инфраструктуры и внутренних инструментов. Если между этими зонами появляется ИИ-агент с широкими полномочиями, любой небрежно настроенный workflow превращается в мост для утечки. Причем не обязательно секретов в буквальном смысле. Утечь может внутренний README, архитектурные заметки, названия сервисов, ссылки на окружения, служебные инструкции — все то, из чего потом собирается карта атаки уже руками человека.
Отдельный штрих: исследователи подчеркивают, что для эксплуатации не требовались ни кодинг, ни учетные данные. Это важная деталь для HR, руководителей разработки и фаундеров, которые любят измерять риск по порогу входа. Если атаку можно оформить на уровне «вежливо попросить в issue», значит ее масштабирование уже не требует редкого специалиста по эксплуатации CI/CD. Такого рода баги быстро становятся массовыми именно потому, что хорошо помещаются в шаблон действий: найти организацию с публичным репозиторием, понять, использует ли она Agentic Workflows, оставить правдоподобное сообщение и ждать. Для red team это почти лотерея с подозрительно высокими шансами на выигрыш.
История с GitLost бьет не только по GitHub, но и по всей идее автономных ИИ-агентов в разработке. Пока вендоры продают скорость, безопасность вынуждена напоминать старую скучную истину: любой агент полезен ровно до той минуты, пока его зона ответственности жестко ограничена. Как только инструмент начинает самостоятельно ходить по репозиториям, читать приватные данные и публично отвечать на запросы, он перестает быть «ассистентом» и становится полноценной поверхностью атаки. Подробности кейса и ссылка на первоисточник есть у . Главный вопрос теперь не в том, появится ли документация по GitLost, а в том, сколько компаний успеют пересмотреть права своих агентов раньше, чем кто-то вытащит из приватного репозитория не README, а что-нибудь заметно дороже.