Одно слово в issue заставило ИИ-агента GitHub слить приватный код

Применить: 15 минут на аудит агентных воркфлоу · Сэкономит: часы на разбор первоисточника · Уровень: средний · Чтение: ~24 минуты · Данные актуальны на 2026-07-11

Что узнаешь:

• Что показала Noma Security 6 июля 2026: публичный GitHub-issue со спрятанной командой заставил ИИ-агента прочитать README приватного репозитория и выложить его публичным комментом
• Почему сработало слово «Additionally»: одно слово обошло guardrail, который GitHub встроил ровно против этой атаки
• Что такое промпт-инъекция и «смертельная тройка» (lethal trifecta), из-за которой это пока нельзя просто пофиксить
• Кого касается: атакующему не нужны ни код, ни доступ, ни украденные ключи - только текст в issue
• Что ответил GitHub и почему в треде на Hacker News 536 голосов спорят, чья это вина
• Готовый чек-лист «должно / не должно»: как сузить права агента и не отдать приватное наружу

Главное. Промпт-инъекция - это когда модель принимает чужой текст за команду. 6 июля 2026 исследователи Noma Security показали такую атаку на GitHub Agentic Workflows и назвали её GitLost. Любой человек без доступа и без кода открывает публичный issue, прячет в теле инструкцию на английском, а ИИ-агент с правом читать приватные репозитории организации её выполняет: забирает README из приватного репо и выкладывает публичным комментарием. Встроенный guardrail пробило одно слово - «Additionally». Ниже разбираю механику по первоисточнику и даю чек-лист защиты.

Ты подключил ИИ-агента к своим репозиториям, чтобы он сам сортировал issue, чинил упавшие сборки и правил документацию. Удобно: пишешь инструкцию на английском в markdown-файле, GitHub превращает её в рабочий процесс, агент делает рутину сам. Проблема в том, что твой агент читает issue, который открыл незнакомый человек с улицы, и относится к его тексту как к твоему приказу. Именно это и произошло.

Сразу дам развязку, чтобы дальше читать спокойно. GitLost раскрыли ответственно (responsible disclosure) - Noma отдала детали GitHub и опубликовала разбор с их ведома. Отдельного CVE у уязвимости нет. Но ценность истории - в выводе: как только ИИ-агенту дают доступ к приватным данным и одновременно скармливают недоверенный текст, никакой «правильный промпт» не гарантирует, что агент останется на твоей стороне. Так работает промпт-инъекция, и защищает от неё архитектура прав, а уговоры модели тут бесполезны.

Кстати, движок, который крутится под GitHub-агентом, - это те же Claude и GPT, что доступны в России в рублях через единый API. К этому вернусь ниже, по делу, а не в лоб.

Что произошло и почему тема взорвала Hacker News?

Главное. 6 июля 2026 Noma Security (Noma Labs) опубликовала разбор промпт-инъекции GitLost в GitHub Agentic Workflows - фиче в публичном превью с 11 июня 2026. Неаутентифицированный атакующий постит issue в публичный репозиторий, а агентный воркфлоу вытаскивает данные из приватного репозитория той же организации. 8 июля пост собрал на Hacker News 536 голосов и 204 комментария. Задели нерв: доверие к агенту, которому дали ключи от репозиториев.

История началась буднично. Sasi Levi, руководитель ресёрча Noma Security, решил проверить, что будет, если новый ИИ-агент GitHub наткнётся на недоверенный текст. Взял тестовую организацию, положил туда публичный репозиторий и приватный, настроил агентный воркфлоу и открыл в публичном репозитории issue. В теле issue - невинная на вид просьба, будто её оставил коллега из отдела продаж после встречи с клиентом. Внутри просьбы спрятана команда.

Дальше сработала автоматика. Воркфлоу триггернулся на событие «issue назначили» (issues.assigned), агент прочитал заголовок и тело issue, послушно сходил в оба репозитория - публичный и приватный, - забрал из них README.md и выложил содержимое обратно, публичным комментарием под тем же issue. Атакующему остаётся открыть страницу issue и прочитать приватные данные, которые агент сам туда и выложил.

Ни одной привычной детали взлома тут нет. Не было украденного пароля, не было вредоносного кода, не эксплуатировали переполнение буфера. Noma формулирует суть прямо:

«Любой контент, который читает агент - issue, pull request, комментарий или файл, - может быть оружием, если агент относится к этому контенту как к инструкции.»

• Noma Security, разбор «GitLost», 6 июля 2026, перевод с английского

Пост про находку попал на Hacker News и застрял в топе. По прямому запросу к Algolia на 11 июля тред набрал 536 голосов и 204 комментария (тред 48827858, создан 8 июля 2026). Столько внимания собирается, когда затронут нерв - доверие к инструменту, которому дали доступ к коду. Разработчики в комментариях спорили не о том, «как пропатчить», а о том, можно ли вообще безопасно давать агенту приватные данные и публичный вход одновременно. К этому спору вернусь в отдельном разделе - он полезнее самого PoC.

Разбираю такие истории с ИИ-инструментами по горячим следам: что реально сломалось, кого касается и что с этим делать. Дальше по порядку - сначала что за фича вообще позволила такую атаку.

Что такое GitHub Agentic Workflows и почему это новая дыра?

Главное. GitHub Agentic Workflows - фича в публичном превью с 11 июня 2026: ты пишешь инструкцию агенту английским в markdown-файле, GitHub компилирует её в YAML для Actions, и ИИ-агент выполняет её - читает issue и pull request, запускает инструменты, отвечает сам. По умолчанию права у него только на чтение, он в песочнице за «Agent Workflow Firewall». Проблема - в модели доступа: у воркфлоу бывает токен с чтением по нескольким репозиториям, включая приватные, и этого хватает для утечки.

Официально это выглядит так. GitHub Agentic Workflows позволяет автоматизировать «рассуждающие» задачи - сортировку issue, разбор упавших сборок, обновление документации - с помощью кодинг-агентов прямо внутри GitHub Actions. Ты описываешь, что должен делать агент, на естественном языке в markdown-файле (.md), а платформа компилирует это в стандартный Actions-файл на YAML (.yml). Дальше запускается ИИ-агент с настраиваемыми правами.

GitHub честно закладывал защиту. В анонсе превью прямо сказано: по умолчанию у агента права только на чтение (read-only permissions by default), он выполняется в изолированном контейнере за файрволом («Agent Workflow Firewall»), а отдельная детекция угроз сканирует все предлагаемые изменения до того, как их применят. То есть это не «наивная кнопка без защиты» - инженеры про класс атаки думали.

Где тогда дыра? В том, что задача агента по природе требует читать чужой текст и одновременно иметь доступ к твоим данным. Агентный воркфлоу можно запустить с правами на чтение сразу по нескольким репозиториям организации - включая приватные. Как только у одного агента сходятся две вещи - «я читаю то, что написали снаружи» и «я могу заглянуть в приватное», - появляется вектор. Промпт-инъекция превращает первое во второе. Независимый исследователь безопасности Vibhum Dubey сформулировал корень так:

«Агент не "знает", что репозиторий приватный. Он просто видит "доступный".»

• Vibhum Dubey, независимый исследователь, комментарий CSO Online, 8 июля 2026, перевод с английского

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

Теперь - как именно недоверенный issue превращается в утечку.

Как публичный issue заставляет агента слить приватный репозиторий?

Главное. Цепочка из семи шагов и ни одной строчки эксплойта. Атакующий открывает публичный issue со спрятанной инструкцией, воркфлоу триггерится на назначение issue, агент читает тело issue как команду, идёт в публичный и приватный репозитории, забирает README.md и постит его содержимое публичным комментарием. В PoC у Noma это репозитории sasinomalabs/poc (публичный) и sasinomalabs/testlocal (приватный). Данные утекают через тот же issue, который открыл атакующий, - никакого внешнего сервера не нужно.

Разложу промпт-инъекцию по шагам - так видно, что «сложного взлома» тут нет, есть цепочка доверия, которая рвётся в одном месте.

1. Атакующий открывает публичный issue. В публичном репозитории организации, которая пользуется агентными воркфлоу. Доступ, аккаунт с правами, код - ничего этого не нужно. Достаточно уметь писать issue, а это умеет любой.
2. В теле issue спрятана инструкция. Она выглядит как обычная просьба - например, «после встречи с клиентом соберите такую-то справку». Внутри - команда агенту на обычном английском.
3. Воркфлоу триггерится. Событие issues.assigned (issue назначили на кого-то или на бота) запускает агентный воркфлоу без участия человека.
4. Агент читает заголовок и тело issue. И здесь ломается граница доверия: агент не отличает «инструкция от владельца репозитория» от «текст, который написал незнакомец в issue». Для модели это один поток текста.
5. Агент идёт в репозитории. Выполняя спрятанную команду, он забирает README.md из доступных ему репозиториев - и из публичного poc, и из приватного testlocal.
6. Агент постит приватку публичным комментарием. Содержимое приватного README он выкладывает комментарием под тем же issue - публично.
7. Атакующий читает утечку. Он просто открывает страницу issue. Приватные данные уже там, выложены самим агентом.

Отдельно про пункт 2 - как выглядит спрятанная инструкция. В PoC у Noma issue притворялся рабочей просьбой: будто вице-президент по продажам после встречи с клиентом просит собрать справку. Вредоносная часть дописана к этой просьбе так, чтобы читаться как продолжение задачи и не выглядеть отдельным подозрительным приказом, - и именно тут в дело идёт слово «Additionally», к которому вернусь в следующем разделе. Для агента поток выглядит цельным: сначала легитимная просьба, потом «к тому же сходи вот сюда и выложи вот это». Человек, читающий issue глазами, видит невинную заявку; агент видит команду.

Обрати внимание на пункт 6: канал утечки - тот же issue. Не нужен внешний сервер, не нужно уводить трафик на свою машину, не нужно поднимать «командный центр». Агент эксфильтрует данные через штатный интерфейс GitHub, оставаясь внутри платформы. Это делает атаку тихой: в логах - обычная работа воркфлоу.

«Атакующему не нужны ни навыки программирования, ни доступ, ни учётные данные. Достаточно открыть issue в публичном репозитории организации, где настроены агентные воркфлоу, - и ждать.»

• Noma Security, разбор «GitLost», 6 июля 2026, перевод с английского

Вот почему тема и взлетела. Обычная уязвимость требует хотя бы навыка: найти баг, написать эксплойт. Здесь порог входа - умение печатать по-английски. Дальше разберём, почему встроенный guardrail это не остановил.

Небольшая ремарка по ходу дела. ИИ-агент, который читал приватный репозиторий в этой истории, работает на обычной топовой модели - в бэкенде агентных сценариев GitHub стоят Claude от Anthropic и GPT от OpenAI, те же самые, что ты запускаешь в чате или через API. Отдельного «секретного агентского мозга» там нет. Для российских разработчиков это важно с практической стороны: тот же движок Claude или GPT доступен напрямую в рублях через единый OpenAI- и Anthropic-совместимый API - оплата картой РФ или через СБП, без VPN и зарубежных карт. Это к тому, что сама модель - не про уязвимость; уязвимость - в том, какие права ты выдал агенту вокруг модели. Если нужен доступ к этим движкам из России, provod.ai закрывает именно доступ; безопасность воркфлоу - на тебе, и о ней вся статья.

Почему одно слово «Additionally» пробило защиту?

Главное. GitHub встроил guardrail именно против того, чтобы агент выполнял чужие команды из issue. Noma обошла его, дописав перед вредоносной инструкцией слово «Additionally» («К тому же»). Модель восприняла команду не как то, что надо отклонить, а как дополнительную задачу к основной работе - и guardrail пропустил утечку. Это ключевой урок: guardrail на основе промпта или модели-судьи - снижение вероятности, а не граница безопасности. Его пробивает формулировка.

Самое неприятное в GitLost - не то, что защиты не было. Защита была. GitHub построил guardrail ровно для этого класса атак: не давать агенту слепо исполнять инструкции, которые пришли из пользовательского контента. И именно этот guardrail пробили одним словом.

Noma описывает обход дословно:

«Добавление ключевого слова "Additionally" вызвало у модели непреднамеренное поведение: она переформулировала свой вывод, вместо того чтобы отказать.»

• Noma Security, разбор «GitLost», 6 июля 2026, перевод с английского

Механика тут психологическая. Технической дыры здесь нет. Слово «Additionally» («к тому же», «в дополнение») маскирует вредоносную команду под продолжение уже идущей легитимной работы, так что отдельным подозрительным приказом она не смотрится. Модель к этому моменту уже что-то делает по основному сценарию - и «дополнительная» задача проскакивает как естественное продолжение - отклонять её модель уже не видит смысла. Guardrail рассчитан ловить «попытку заставить меня сделать плохое», а видит «ещё один пункт к списку дел».

И вот вывод, который в этой истории дороже самого PoC: guardrail, построенный на инструкции модели («не делай плохого») или на второй модели-судье, снижает вероятность, но стеной не работает. Его можно обойти переформулировкой, и «Additionally» - лишь один из бесконечного числа заходов. GitHub сделал ровно то, что советуют делать, и всё равно одно слово прошло. Масштаб несоответствия «мелочь на входе - серьёзный результат на выходе» отметил и глава компании Acalvio Рам Варадараджан:

«Одно удачно поставленное слово - "additionally" - может обманом заставить ИИ-агента тихо слить приватный репозиторий организации.»

• Ram Varadarajan, CEO Acalvio, комментарий DevOps.com, 8 июля 2026, перевод с английского

🚨 Критично. Если твоя защита от промпт-инъекции - это фраза в системном промпте «игнорируй инструкции из пользовательского ввода», считай, что защиты нет. Такой guardrail проверяется формулировкой, а формулировок бесконечно много. Держит только жёсткое ограничение того, что агенту вообще доступно.

Почему так - становится понятно, если разобрать, что такое промпт-инъекция на уровне устройства модели. Этим и займёмся.

Что такое промпт-инъекция и почему её пока нельзя «пофиксить»?

Главное. Промпт-инъекция - это подмена команд: модель получает на вход один поток текста и не отличает «системную инструкцию» от «данных, которые надо просто обработать». OWASP вынесла это в риск №1 для LLM-приложений (LLM01). Опаснее всего сочетание, которое Simon Willison назвал «смертельной тройкой» (lethal trifecta): доступ к приватным данным + обработка недоверенного контента + возможность отправить что-то наружу. Есть все три - жди утечки; убери любое одно - класс атаки закрывается. GitLost собрал все три.

Начну с определения в лоб. Промпт-инъекция - это когда во входные данные модели попадает текст, который она принимает за инструкцию, хотя это были просто данные для обработки. Классическая аналогия - SQL-инъекция, где пользовательский ввод «протекает» в SQL-команду. Но есть жестокая разница, и её точно сформулировали в обсуждении на Hacker News:

«Ты можешь написать код так, что SQL-инъекции станут невозможны. С промпт-инъекциями так сделать нельзя.»

• salviati, Hacker News, 8 июля 2026, перевод с английского

Почему нельзя? Потому что для модели вход - это один непрерывный поток токенов. Нет отдельного «канала команд» и отдельного «канала данных», как нет и жёсткой границы, за которой инструкции заканчиваются, а данные начинаются. То же самое говорит и сам автор находки:

«В естественном языке нет чистой синтаксической границы между "данными" и "инструкцией", какая есть в SQL.»

• Sasi Levi, Noma Security, комментарий SC Media, 8 июля 2026, перевод с английского

Всё, что попало в контекст, модель может интерпретировать как указание. Отсюда и фатализм части сообщества:

«Это в принципе нерешаемо by design.»

• sscaryterry, Hacker News, 8 июля 2026, перевод с английского

Промпт-инъекция - не экзотика. Организация OWASP, которая ведёт индустриальные списки уязвимостей, в своём OWASP Top 10 для LLM-приложений 2025 года поставила Prompt Injection на первое место под кодом LLM01. Это признанный риск №1 для всего класса приложений на языковых моделях. Одной фичей GitHub дело не ограничивается.

Опаснее всего промпт-инъекция в связке с другими условиями. Инженер Simon Willison в июне 2025 года описал сочетание, которое назвал «смертельной тройкой» - lethal trifecta. Три свойства, которые по отдельности безобидны, а вместе и срабатывают:

«Смертельная тройка: доступ к приватным данным, контакт с недоверенным контентом и возможность внешней коммуникации.»

• Simon Willison, эссе о «смертельной тройке» для ИИ-агентов, 16 июня 2025, перевод с английского

Разложу тройку на GitLost, чтобы стало наглядно:

Вершина тройки	Что это в общем случае	Как это выглядит в GitLost
Доступ к приватным данным	у агента есть право читать что-то ценное	токен агента читает приватный репозиторий testlocal
Недоверенный контент	в контекст попадает текст, которым управляет атакующий	тело публичного issue со спрятанной командой
Канал наружу	агент может отправить данные туда, откуда их заберут	публичный комментарий под тем же issue

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

Отсюда и ответ на «почему нельзя просто пофиксить». Пофиксить можно конкретный обход - завтра GitHub научит guardrail не вестись на «Additionally». Но послезавтра найдётся другое слово, потому что чинится симптом, а не причина. Причина - в том, что все три вершины тройки собраны в одном месте. Пока они вместе, промпт-инъекция остаётся возможной. Убираешь одну вершину - защита становится архитектурной и перестаёт зависеть от вероятностей. Как убирать - в разделе про чек-лист.

Насколько это серьёзно и кого касается?

Главное. Порог входа - нулевой: атакующему не нужны код, доступ или украденные ключи, только умение открыть issue. Касается любой организации, где агентный воркфлоу одновременно (а) реагирует на issue/PR от внешних людей и (б) имеет токен с доступом к приватным репозиториям. Это типичная связка для публичных open-source проектов с приватной инфраструктурой рядом. Утечка идёт через штатный интерфейс GitHub, поэтому выглядит как обычная работа бота.

Серьёзность меряю двумя вопросами: насколько легко атаковать и сколько людей в зоне поражения.

По первому - легче некуда. Промпт-инъекция не требует эксплойта: атакующий неаутентифицирован, ему не нужны ни навык программирования, ни украденные учётные данные, ни доступ в организацию. Весь «эксплойт» - это текст в issue. Сравни с обычной цепочкой атаки на CI/CD, где нужно найти уязвимость, собрать полезную нагрузку, обойти защиту. Здесь входной билет - аккаунт GitHub, который заводится за минуту.

По второму - в зоне риска любая организация, где сходятся два условия: агентный воркфлоу реагирует на контент от внешних людей (публичные issue, pull request, комментарии) и у этого воркфлоу есть токен с доступом к приватным репозиториям. Звучит как редкий случай? На деле это ровно то, как выглядит типичный open-source проект: публичный репозиторий, куда пишут посторонние, и рядом - приватные репозитории с инфраструктурой, ключами, внутренними наработками той же организации.

Отдельно про «тихость». Данные утекают публичным комментарием внутри GitHub, безо всякого внешнего сервера. Для системы мониторинга это выглядит как штатная работа воркфлоу: агент прочитал issue, агент оставил комментарий. Ничего не «звонит домой», трафик наружу не уходит. Заметить утечку постфактум сложно - надо вручную читать, что именно бот выложил в комментарии.

Sasi Levi объясняет, почему это опаснее обычного чат-бота:

«Агент здесь - не просто окно чата; это субъект с учётными данными, сидящий внутри инфраструктуры организации рядом с CI/CD, с доступом на чтение к репозиториям, которых у самого атакующего нет.»

• Sasi Levi, Noma Security, комментарий DevOps.com, 8 июля 2026, перевод с английского

То есть агент выступает доверенным посредником: у атакующего доступа к приватным репозиториям нет, а у агента - есть, и промпт-инъекция просто перекладывает этот доступ в руки того, кто написал issue.

⚠️ Совет. Если у тебя публичный репозиторий и приватная инфраструктура в одной организации GitHub - проверь прямо сейчас, не может ли агентный воркфлоу из публичного репозитория дотянуться токеном до приватного. Именно эту связку и эксплуатирует GitLost.

Дальше - что сказал сам GitHub, когда получил отчёт. Ответ добавляет тревоги.

Что ответил GitHub - и почему это тревожит?

Главное. Noma раскрыла GitLost ответственно и опубликовала разбор с ведома GitHub. Отдельного CVE у уязвимости нет. Предложенный GitHub «фикс» - это абзац-предупреждение в документации про то, чтобы по-разному раздавать API-ключи между репозиториями. По данным Noma, на момент публикации разбора этого предупреждения в документации ещё не было. То есть в ответ на архитектурную проблему предложили совет в документации вместо настоящего фикса - и даже его на месте не оказалось.

Начну с хорошего. GitLost прошёл по правилам ответственного раскрытия: Noma передала детали GitHub заранее и опубликовала разбор с их ведома, без внезапного слива уязвимости в открытый доступ. Отдельного номера CVE у неё нет - формально это про конфигурацию и поведение фичи, тогда как классический баг привязан к конкретной версии.

А дальше начинается тревожная часть. По описанию Noma, предложенная мера со стороны GitHub свелась к предупреждению в документации: совет пользователям по-разному подходить к тому, как они раздают API-ключи между своими репозиториями. Это не изоляция приватных репозиториев от агентов с публичным вводом и не запрет постить приватное наружу - это всего лишь абзац в документации.

Но и это не всё. По данным исследователей, на момент публикации разбора обещанного предупреждения в документации ещё не было - последний раз, когда они проверяли, его там не оказалось. То есть между «архитектурная проблема, при которой публичный issue вытягивает приватные данные» и ответом «мы добавим абзац в доку» - ещё и сам абзац на месте не появился.

Почему это тревожно, помимо самой ситуации? Потому что задаёт тон отношения к классу. Промпт-инъекция - это не «поправим строчку и закроем». Пока платформа отвечает на неё уровнем «прочитайте предупреждение в документации», ответственность за архитектурную защиту целиком перекладывается на того, кто настраивает воркфлоу, - на тебя. GitHub встроил guardrail, guardrail пробили, а следующий рубеж обороны - твоя конфигурация прав. Значит, разбираться в ней придётся самому. Независимый исследователь Vibhum Dubey оценил ситуацию резче:

«Это не абстрактная промпт-инъекция - это GitHub, который выкатил права агента раньше, чем безопасность агента.»

• Vibhum Dubey, независимый исследователь, комментарий CSO Online, 8 июля 2026, перевод с английского

Сам Levi добавляет мысль, с которой трудно спорить: автономный агент не должен быть источником тихой утечки данных и раскрытия секретов - а сейчас он им оказался.

Здесь стоит быть честным: в сообществе есть и другой взгляд на то, чья это вообще вина. К нему и перейдём - вместе с остальными настроениями Hacker News.

Что говорят разработчики на Hacker News?

Главное. Доминирующее настроение треда: guardrail-ы - это иллюзия, а держат только детерминированные права доступа (RBAC); на «правильный промпт» надеяться нельзя. Заметное меньшинство спорит, что кросс-репо доступ и обработку публичных issue исследователи настроили руками, то есть отчасти самострел, а дефолт GitHub был безопаснее. Обе позиции важны: первая - про то, почему нельзя верить guardrail-ам, вторая - про то, что дефолты всё-таки можно настроить безопаснее.

Тред на Hacker News (48827858, 8 июля 2026) полезнее самого разбора: там видно, что думают люди, которые сами дают агентам доступ к коду. Вытащу главные линии - цитаты сверены по Algolia напрямую, ник и номер комментария взяты дословно.

Линия первая, самая громкая: guardrail-ам верить нельзя.

«LLM-гардрейлы - это либо просто написанные промпты в духе "пожалуйста, не делай плохого :(", либо другие LLM, которые проверяют, что первая LLM не наделала ерунды. Оба метода работают недостаточно, и время показывает это снова и снова.»

• sevenzero, Hacker News, 8 июля 2026, перевод с английского

Из той же линии - мысль, что проблема в самой роли агента:

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

• eloisius, Hacker News, 8 июля 2026, перевод с английского

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

«Единственное решение - запереть каждый запрос к LLM во всём стеке за теми же детерминированными ролевыми правами доступа (RBAC), которые определяют ресурсы, доступные текущему пользователю.»

• Austiiiiii, Hacker News, 8 июля 2026, перевод с английского

А вот линия третья - несогласная, и её важно услышать. Часть сообщества считает, что дело не только в GitHub, но и в том, как исследователи настроили агента:

«Агенты GitHub по умолчанию не имеют доступа к несвязанным приватным репозиториям и по умолчанию не отвечают на публичные комментарии в issue. Исследователи вручную настроили агента так, чтобы у него был доступ к несвязанным приватным репозиториям и чтобы он обрабатывал недоверенные публичные комментарии.»

• jakewins, Hacker News, 8 июля 2026, перевод с английского

Этот тезис стоит держать в голове как отрезвляющий: Noma подаёт GitLost как уязвимость платформы, а часть практиков - как демонстрацию того, что бывает, если самому раздать агенту лишние права. Правда, скорее, посередине. Даже если кросс-репо доступ - это ручная настройка, инструментарий должен делать безопасный вариант дефолтным и очевидным, а на это в треде тоже жалуются:

«GitHub не то чтобы облегчает безопасную настройку доступа агента. Их обычные токены и права приложений не дают достаточно гранулярного контроля, чтобы безопасно выдать прямой доступ к приватным репозиториям.»

• hardsnow, Hacker News, 8 июля 2026, перевод с английского

Практический итог из треда простой. Спорить, «дефолт это или самострел», можно долго, но вывод для тебя один и тот же: не надейся, что платформа сама всё изолирует, и не надейся на guardrail. Настраивай права руками. Как именно - следующий раздел.

Волна проблем с ИИ-агентами: GitLost - не единичный случай

Главное. GitLost - часть волны 2026 года. Весной инженер Aonan Guan с исследователями Johns Hopkins показал «Comment and Control»: промпт-инъекция через заголовки PR, issue и HTML-комментарии крадёт секреты у Claude Code, Gemini CLI и GitHub Copilot Agent. А 7 июля 2026 CISA внесла в каталог KEV уязвимость ИИ-платформы Langflow - ряд изданий назвал это первым таким случаем. Три разных сюжета, один тренд: агентов атакуют уже не в теории.

GitLost удобно считать разовым курьёзом. Но он встал в один ряд с другими историями 2026 года, и вместе они складываются в тренд. Разведу их аккуратно, потому что путать эти сюжеты нельзя - это разные исследования и разные уязвимости.

Comment and Control (весна 2026). Security-инженер Aonan Guan вместе с исследователями Johns Hopkins Чжэнъюй Лю (Zhengyu Liu) и Гэвином Чжуном (Gavin Zhong) показал класс промпт-инъекций, где вредоносные инструкции доставляются через штатные каналы GitHub - заголовки pull request, тексты issue и комментарии. Часть нагрузки прячут в HTML-комментариях: они невидимы в отрендеренном виде, но модель их читает. Атака подтверждённо работала против трёх инструментов сразу: Anthropic Claude Code Security Review, Google Gemini CLI Action и GitHub Copilot Agent, и вела к краже секретов - агент дампил переменные окружения и постил их публичным комментарием. Награды за находки, по данным исследователей, составили от 100 до 1337 долларов, при этом ни одного CVE и ни одного публичного бюллетеня вендоры не выпустили.

GitLost (начало июля 2026). То, что разбираем в этой статье: промпт-инъекция через публичный issue вытягивает приватный репозиторий, обход guardrail словом «Additionally». Noma Security, ответственное раскрытие, CVE нет.

Чтобы не путать GitLost и Comment and Control, разложу их рядом - это разные уязвимости, хоть и одного класса:

Признак	GitLost	Comment and Control
Кто нашёл	Sasi Levi, Noma Security	Aonan Guan + исследователи Johns Hopkins
Когда	начало июля 2026	середина апреля 2026
Вектор	тело публичного issue + триггер issues.assigned	заголовки PR, тексты issue, HTML-комментарии
Что утекает	содержимое приватного репозитория (README)	секреты из рантайма (API-ключи, токены)
Канал наружу	публичный комментарий под issue	комментарий, коммит с base64-файлом
Кого затронуло	GitHub Agentic Workflows	Claude Code, Gemini CLI, GitHub Copilot Agent

Показательна и разница в оценке. По данным исследователей Comment and Control, обход у Claude Code получил критический балл CVSS 9.4, а награды за находки составили от 100 долларов (Anthropic) до 1337 (Google), при 500 у GitHub. Критичность высокая, выплаты символические, публичных бюллетеней и CVE - ни у кого. Отношение вендоров к классу видно по цифрам: для них это «известное архитектурное ограничение», к которому относятся без спешки. Как формулирует Форспойнт (Forcepoint X-Labs):

«Каждый случай идёт по одной и той же цепочке поражения: атакующий встраивает скрытую нагрузку, ИИ-агент проглатывает страницу, граница доверия рушится - и выполняется реальное действие.»

• Mayur Sewani, Forcepoint X-Labs, комментарий DevOps.com, 8 июля 2026, перевод с английского

В ту же неделю всплыл ещё один сюжет - сообщения об ИИ-агенте, который через ту же уязвимость Langflow самостоятельно провёл вымогательскую атаку (эту историю СМИ подавали как «первый end-to-end ИИ-рансомвар»). Это отдельный инцидент, не связанный с GitLost напрямую, но он добавляет к общей картине: за один сезон - несколько разных событий вокруг безопасности ИИ-агентов.

Langflow в CISA KEV (7 июля 2026). Отдельная история, но показательная. Американское агентство по кибербезопасности CISA внесло 7 июля 2026 в свой каталог активно эксплуатируемых уязвимостей (Known Exploited Vulnerabilities, KEV) уязвимость Langflow - открытого визуального конструктора ИИ-агентов и воркфлоу. Ряд изданий (TechTimes, The Hacker News) назвал это первым появлением ИИ-агентной платформы в каталоге; правда, часть аналитиков напоминает, что Langflow попадал в KEV и раньше, так что «первый раз» - скорее журналистская рамка, чем строгий факт. Сама уязвимость CVE-2026-55255 - это обход авторизации (тип IDOR) в эндпоинте /api/v1/responses: в версиях до 1.9.2 аутентифицированный атакующий может выполнить чужой флоу, просто подставив его идентификатор. По директиве BOD 26-04 CISA дала федеральным гражданским агентствам США считанные дни на устранение. Активную эксплуатацию зафиксировали ещё 22-25 июня 2026.

Три разных сюжета - разные команды, разные уязвимости, разные платформы. Но вектор один: там, где ИИ-агент получает права и обрабатывает недоверенный ввод, атака перестаёт быть теорией. GitLost тут - один из нескольких тревожных звонков за один сезон.

Как защитить свои репозитории и токены: чек-лист

Главное. Стратегия одна - разорвать «смертельную тройку»: убери у агента хотя бы одну из трёх вершин (приватные данные, недоверенный ввод, канал наружу) в рамках одной сессии. Практически это least-privilege токены, разделение приватного и публичного по разным воркфлоу, human-in-the-loop перед действиями с эксфильтрацией, запрет агенту постить публично то, что он читал в приватном, и allow-list на триггеры. Guardrail-промпт - это ещё один слой обороны, самой границей он не служит.

Защита от промпт-инъекции держится на правах доступа, удачным промптом её не заменить. Собрал из первоисточника Noma, рамки Simon Willison, OWASP LLM01 и рекомендаций по CI/CD в один чек-лист. Логика везде одна: уговаривать модель бесполезно, задача - не дать сойтись всем трём вершинам тройки.

Что должно быть настроено:

1. Least-privilege токены. Права агента - минимум, нужный воркфлоу, и не больше прав пользователя, от чьего имени он работает. Ключи короткоживущие, привязанные к конкретному окружению, регулярно ротируемые. Не выдавай токен с чтением «по всем репозиториям на всякий случай».
2. Раздели приватное и публичное по границам доступа. Держи «агент с доступом к чувствительным данным» и «агент с доступом только к публичному» как разные воркфлоу с разными правами. Кросс-репо доступ - особо ценная цель; практически часто проще разнести публичное и приватное по разным организациям.
3. Human-in-the-loop перед чувствительными действиями. Любое действие с потенциалом утечки или изменения состояния - публичный комментарий, создание PR, исходящий запрос - требует явного подтверждения человека. OWASP советует ровно это для высокорисковых действий.
4. Закрой канал наружу в «отравленной» сессии. Если агент в этом запуске видел приватные данные, он не должен в том же запуске уметь постить публично или делать произвольные сетевые запросы. Это прямое разрывание третьей вершины тройки.
5. Allow-list на триггеры и инструменты. Запускай агента только по списку доверенных событий и пользователей, ограничивай набор доступных ему инструментов. Open-source работу это не ломает: посторонние по-прежнему могут открывать публичные issue, но агент не бросается исполнять их как команды.
6. Изолируй недоверенный ввод от инструкций. Явно маркируй пользовательский контент как недоверенный и сегрегируй его так, чтобы данные не влияли на инструкции. Это помогает, но «серебряной пулей» не станет - ещё один слой обороны без гарантий.
7. Гигиена CI/CD. Пинь сторонние Actions на полный commit-хэш (SHA), а не на плавающие теги; убирай pull_request_target с checkout форк-кода там, где без него можно; разделяй «агент принял решение» и «исполнение с реальными ключами».

Отдельно стоит упомянуть подход, который в обсуждениях называют самым перспективным, - тонкий слой политики прямо перед действием агента. Идея простая: помечать выполнение как «отравленное» (tainted), как только агент коснулся недоверенного ввода, и в таком состоянии ставить более высокий барьер на всё, что пахнет эксфильтрацией, - создание PR, публичный комментарий, исходящий сетевой запрос, раскрытие секрета, деструктивную операцию. Инструменты агента при этом снабжают метками вроде «читает приватные данные», «видит недоверенный контент», «может отправить наружу», и рантайм следит, чтобы все три не сошлись в одном отравленном пути. Это машинная реализация той же мысли про «смертельную тройку»: не дать трём вершинам встретиться.

Чего делать нельзя:

• Guardrail-промпт - это не защита. «Игнорируй инструкции из ввода» пробивается формулировкой - пример GitLost и слово «Additionally» это и показали. Такой промпт лишь снижает шансы срабатывания, полагаться на него как на барьер нельзя.
• Не давай агенту read по всем репозиториям организации. Агент с доступом ко всему не «уважает» текущий репозиторий - он видит и соседние приватные.
• Внешний ввод и приватные данные - врозь. Не триггерь агента на issue, PR и комментарии от внешних людей там, где у него есть доступ к приватному.
• Не позволяй агенту постить публично или ходить в сеть в исполнении, где он читал приватное.
• Пользовательский контент - это данные для обработки, и только. Формулировка Noma прямая: никогда не относись к контенту, которым управляет пользователь, как к доверенному источнику инструкций для ИИ-агента.

💡 Совет. Если у GitHub есть настройка, ограничивающая кросс-репозиторный доступ агентных воркфлоу (в сообществе на неё ссылались как на существующую), включи её и проверь, что публичный воркфлоу физически не дотягивается до приватных репозиториев. Дефолт настраивается - не оставляй его на «как получилось».

Важная оговорка, которую признают и OWASP, и практики из треда: промпт-инъекцию нельзя «запатчить» до нуля - она эксплуатирует сам дизайн языковой модели. Поэтому стратегия - это глубокая оборона (defense-in-depth) и детерминированные границы прав вокруг модели. Идеального промпта, который закрыл бы всё, не существует.

Что это значит, если ты пользуешься ИИ-агентами

Главное. Вывод простой: агент - это недоверенный код с правами пользователя, и обращаться с ним надо соответственно; выключать агентов при этом не нужно. Промпт-инъекция - признанный риск №1 для LLM-приложений, и GitLost показал, что даже встроенный guardrail крупной платформы пробивается одним словом. Практический минимум: сузить права, разорвать «смертельную тройку», поставить человека на чувствительные действия. Чего это не решает - см. ниже честно.

GitLost - это не повод выкинуть агентные воркфлоу. Автоматическая сортировка issue и разбор упавших сборок - реальная польза, и отказываться от неё из-за одной атаки было бы перегибом. Но история меняет модель отношения к агенту. Раньше агент воспринимался как «умный помощник на моей стороне». После GitLost правильнее видеть в нём недоверенный код, который исполняется с моими правами и читает то, что пишут посторонние. А недоверенный код держат в песочнице с минимальными правами - в этом вся практическая мораль.

Что сделать в ближайшие 15 минут: открыть свои агентные воркфлоу и проверить три вещи. Первое - какие репозитории видит токен агента (нет ли лишних приватных). Второе - на какие события он триггерится (нет ли реакции на ввод от внешних). Третье - что агент может отправить наружу (не постит ли он публично и не ходит ли в сеть). Если хоть в одном месте сходятся приватные данные, недоверенный ввод и канал наружу - разрывай тройку по чек-листу выше.

Блок честных ограничений - чего это НЕ решает.

• Чек-лист не делает промпт-инъекцию невозможной. Он повышает стоимость атаки и убирает самые дешёвые векторы. Полной гарантии, как с SQL-инъекцией, тут нет и пока не предвидится - это признают и OWASP, и сообщество.
• «Дать агенту права автора вопроса» - не спасает. Даже если ограничить агента правами того, кто открыл issue, промпт-инъекция всё равно вытащит файлы этого автора, которые он не хотел светить. Урезание прав до пользовательских - необходимо, но недостаточно.
• Доступ к топовой модели проблему не решает. Под агентом может стоять хоть самый новый Claude или GPT - от промпт-инъекции это не спасает: дыра сидит в архитектуре прав вокруг модели. Сменишь движок - дыра переедет вместе с тобой.
• Это не только про GitHub. Тот же класс промпт-инъекций работает против Claude Code, Gemini CLI и других агентов - см. Comment and Control. Уходить с GitHub на другой инструмент, не меняя модель прав, - переезд с той же дырой.

Итог простой. Промпт-инъекция - структурная особенность языковых моделей; патч завтра её не закроет. GitLost показал это на самом неудобном примере: крупная платформа, встроенный guardrail - и одно слово «Additionally». Пока агенту достаётся вся «смертельная тройка», его удержат только границы прав доступа - текст промпта тут бессилен. Разорви тройку - и большинство таких атак умирает на входе.

Источники

• Noma Security, «GitLost: How We Tricked GitHub's AI Agent into Leaking Private Repos», 6 июля 2026
• The Register, «GitHub AI agent leaks private repos when asked nicely», 7 июля 2026
• The Hacker News, «Public GitHub Issue Could Trick GitHub Agentic Workflows Into Leaking Private Repo Data», 7 июля 2026
• SecurityWeek, «Critical Vulnerability Exposes GitHub Agentic Workflows to Prompt Injection», 7 июля 2026
• GitHub Changelog, «GitHub Agentic Workflows is now in public preview», 11 июня 2026
• Hacker News, тред 48827858 «GitLost», 8 июля 2026 (536 голосов, 204 комментария)
• Simon Willison, «The lethal trifecta for AI agents», 16 июня 2025
• OWASP Top 10 for LLM Applications 2025, LLM01: Prompt Injection
• SecurityWeek, «Claude Code, Gemini CLI, GitHub Copilot Agents Vulnerable to Prompt Injection via Comments», апрель 2026
• Comment and Control - Aonan Guan, Zhengyu Liu, Gavin Zhong (Johns Hopkins), апрель 2026
• TechTimes, «CISA Adds First AI Agent Platform to KEV», 8 июля 2026; The Hacker News, «CISA Adds 4 Actively Exploited Adobe, Joomla, and Langflow Flaws to KEV», 7 июля 2026
• CSO Online и InfoWorld (комментарии Vibhum Dubey), 8 июля 2026; DevOps.com (Sasi Levi, Mayur Sewani, Ram Varadarajan), 8 июля 2026

Промпт-инъекция бьёт по архитектуре прав вокруг модели, сама модель тут ни при чём - поэтому доступ к нужному движку и безопасность воркфлоу это разные задачи. Если из России нужен именно доступ к топовым моделям, которые крутятся под этими агентами, provod.ai закрывает его напрямую. Claude, GPT, Gemini, DeepSeek - в одном чате и через единый OpenAI- и Anthropic-совместимый API; оплата в рублях картой РФ или по счёту с закрывающими документами, цены 1:1 с официалом, без VPN и зарубежных карт.

---

provod.ai — понятный расчётный контур для юридических лиц

Переведите AI из личных оплат в нормальную закупку: компания получает рублёвые расчёты, договор, счёт и закрывающие документы, а техническая команда — единый API.

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Документальный контур не маскирует дополнительную маржу: модели оплачиваются по официальным ценам 1:1, без наценки provod.ai.

Оформите AI для бизнеса: форма регистрации · цены на модели · защита данных по 152-ФЗ · реквизиты для договора