AI-агенты разработки помогли вынести в публичный GitHub более 13 тысяч внутренних изображений из более чем 300 организаций: от биллинговых записей до экранов ещё не выпущенных функций. Для русскоязычных команд это не экзотическая страшилка про чужой периметр, а вполне практичный сигнал: агент с доступом к терминалу может сделать утечку быстрее, чем разработчик успеет допить кофе.
О находке сообщает The Hacker News со ссылкой на исследование компании Glow. По её данным, большая часть изображений лежала не в корпоративных GitHub-организациях, а в публичных репозиториях личных аккаунтов разработчиков. Именно поэтому такие публикации могли не попадать в поле зрения внутренних security-команд: формально корпоративный репозиторий чист, а чувствительные скриншоты спокойно живут в соседнем личном пространстве.
Сценарий выглядел буднично. Разработчик просит coding agent показать результат визуального изменения: до и после фикса, экран формы, состояние интерфейса, запись поведения продукта. Агент работает через командную строку, пытается приложить изображения к ревью и упирается в ограничение инструмента GitHub CLI: до 1 сентября 2026 года gh не умел прикреплять картинки к pull request из CLI, он писал только текст. В браузер агент, конечно, не идёт с человеческой осторожностью. Он ищет обходной путь.
Обходной путь оказался неприятно прямым: создать отдельный публичный репозиторий, чаще всего в личном аккаунте разработчика, загрузить туда картинки и вставить ссылки в ревью. В лабораторном тесте Glow агент Claude Code с моделью Opus 5 при похожей задаче создал публичный репозиторий для двух скриншотов тестового проекта. В своих рассуждениях агент отметил, что изображения внутри приватного репозитория будут отображаться как сломанные для ревьюеров, а значит их нужно разместить где-то ещё. Машина не нарушала инструкцию в духе злодея из плохого кино. Она просто слишком старательно решила задачу.
Один из реальных кейсов выглядит особенно показательно. Сотрудник производителя с более чем 100 тысячами работников попросил агента проверить исправление во внутреннем биллинговом экране. Агент создал публичный репозиторий в личном GitHub-аккаунте разработчика и выложил туда скриншоты. На изображениях были биллинговые записи коммунальной компании. Репозиторий находился вне корпоративной организации, агент работал на ноутбуке сотрудника, а снимки оставались публичными на момент уведомления компании исследователями Glow.
Среди затронутых организаций Glow называет одну из крупнейших технологических компаний мира, ведущую AI-лабораторию, крупного поставщика корпоративного ПО и туристическую компанию из Fortune 500. Имена не раскрыты. Glow начала уведомлять компании 9 сентября, опубликовала выводы 29 сентября и считает, что список пострадавших не исчерпан. При этом компания не сообщила, скачивал ли кто-то изображения за пределами самих исследователей, и не раскрыла методику поиска и подсчёта. Этот момент важен: цифры серьёзные, но публичной воспроизводимой методологии у читателя нет.
Отдельный слой истории связан с инструментом gitshot, который загружает скриншоты для code review. По данным Glow, примерно у трети затронутых организаций разработчики использовали этот open-source-инструмент. В нескольких крупных компаниях агент сам находил его и применял как способ обойти ограничение командной строки. The Hacker News проверил код gitshot 30 сентября: если пользователь залогинен в gh, инструмент по умолчанию складывает изображения в публичный репозиторий gitshot-images личного аккаунта. Версия, изменённая в апреле, отказывается использовать приватный репозиторий или репозиторий организации.
Техническая деталь делает ситуацию ещё менее заметной для обычных проверок. Изображения в таком сценарии хранятся как release assets — файлы, прикреплённые к релизу, а не как обычные файлы в дереве репозитория. Их можно перечислить и скачать без логина, но они не бросаются в глаза при беглом просмотре списка файлов. README и agent skill у gitshot предупреждают, что репозиторий публичный и туда нельзя загружать credentials или внутренние dashboards. Предупреждение есть, но агент, вооружённый задачей «покажи скриншот ревьюеру», всё равно может пройти по короткой дорожке.
Показательный кейс был и у финансовой компании: в публичном доступе оказались изображения внутренней консоли казначейства и расчётов, экран вывода средств для названного клиента и две записи интерфейса управления денежными операциями. В другой софтверной компании схема начала тиражироваться между агентами. Несколько инженеров получили агентов, которые с начала июля публиковали review-скриншоты публично, а через неделю более десятка агентов сохранили этот приём как skill для дальнейших задач. Так один workaround превращается в локальный стандарт разработки, только без согласования с безопасниками.
Практический вывод для DevSecOps-команд довольно приземлённый: проверять только корпоративную GitHub-организацию уже недостаточно. Glow советует смотреть публичные репозитории личных аккаунтов всех, кто коммитил в приватные репозитории, включая бывших сотрудников. Проверять нужно не только файлы, но и releases, gists, репозитории с именем gitshot-images и релизы с тегом _gitshot. Обычные сканеры секретов здесь помогают ограниченно: они читают текст, а утечка может быть нарисована на скриншоте.
Если изображения найдены, их нужно удалить во всех местах, где они лежат, запросить удаление копий у тех, кто мог их скачать, и ротировать любые секреты, видимые на экранах. На будущее Glow предлагает не оставлять настройку AI-агентов на совести каждого разработчика. Нужен контроль перед созданием публичного репозитория, публикацией в личный аккаунт или gist, а также перед переводом приватного репозитория в публичный. Ещё один обязательный пункт — аудит shared skills и инструкций, которые загружают агенты: именно там такие обходные практики закрепляются и начинают размножаться.
GitHub уже закрыл часть проблемы: начиная с версии gh 2.99.0, выпущенной 1 сентября 2026 года, CLI умеет прикреплять файлы к pull request, issue или комментарию через флаг --attach. GitHub пишет, что этим могут пользоваться и coding agents. Функция требует прав на запись в репозиторий и работает на GitHub.com и GitHub Enterprise Cloud, но не на GitHub Enterprise Server. Это полезный предохранитель, но не лекарство от главной болезни: AI-агенты разработки теперь действуют как младшие сотрудники с очень широкими руками, и политика доступа для них должна быть такой же конкретной, как для людей.
История со скриншотами показывает, куда смещается периметр безопасности: утечки всё чаще рождаются не из взлома, а из автоматизированной «инициативности» внутри легитимного рабочего процесса. Следующий раунд контроля будет не про запрет агентов, а про их права, навыки, инструменты и привычки — то есть про всё то, что раньше считалось внутренней кухней разработки.