Исследователи обнаружили утечку данных ИИ со скриншотами на GitHub

Исследователи компании по кибербезопасности Glow обнаружили на GitHub более 13 тысяч скриншотов, принадлежащих разработчикам из более чем 300 организаций. Утечка произошла из‑за работы ИИ‑агентов.

Скриншоты содержали записи о выставлении счетов клиентам и снимки ещё не выпущенных функций. В большинстве случаев эти файлы хранились в личных аккаунтах разработчиков: любой мог их загрузить, но службы безопасности компаний их не видели.

В число затронутых организаций входят одна из крупнейших технологических компаний мира, ведущая лаборатория в сфере ИИ, крупный поставщик корпоративного ПО и туристическая компания из списка Fortune 500. Glow начала связываться с ними 9 сентября, опубликовала результаты исследования 29 сентября и заявила, что пострадать могли и другие компании.

В одном из случаев разработчик производственной компании со штатом более 100 тысяч сотрудников попросил ИИ‑агента проверить исправление интерфейса для выставления счетов. Тот создал открытый репозиторий в личном аккаунте разработчика на GitHub и разместил там скриншоты. На изображениях были видны информация о расчетах за коммунальные услуги. Поскольку агент работал на ноутбуке сотрудника, а репозиторий находился вне корпоративной организации на GitHub, сервис безопасности компании не заметила эти файлы. 

В Glow не сообщили, скачивал ли кто‑либо, кроме её собственных исследователей, эти изображения, а также не раскрыли методику их поиска и подсчёта. 

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

До 1 сентября инструмент командной строки GitHub не позволял добавлять такие изображения в пул‑реквест; он поддерживал только текстовые данные. Для добавления изображения требовалось открывать веб‑браузер, и разработчики просили платформу изменить этот порядок ещё с 2020 года.

Хранение изображений внутри приватного репозитория не решало проблему, так как у проверяющих они отображались некорректно (как «битые» файлы). По данным Glow, агенты, работающие через командную строку, обнаружили, что не могут прикреплять скриншоты напрямую. Поэтому они размещали изображения в отдельных публичных репозиториях — как правило, в личных аккаунтах разработчиков, — и предоставляли к ним доступ рецензентам.

Компания провела аналогичный эксперимент в своей лаборатории, используя средство Claude Code с моделью Opus 5. Получив задание изменить цвет заголовка в тестовом проекте «Сапер» (Minesweeper) и продемонстрировать результат, агент разработал свежий публичный репозиторий sweeper-demo/pr-assets для двух скриншотов. В журнале своих рассуждений ИИ отметил, что изображения, зафиксированные (закоммиченные) в приватном репозитории, в пул‑реквесте отображались бы у рецензентов как «битые» (недоступные). В дополнение к этого, требовалось, чтобы в репозитории не было ничего, кроме файла index.html, поэтому агент пришёл к выводу, что единственный выход — разместить изображения на стороннем ресурсе.

При этом в реальных случаях, выявленных Glow, использовались различные модели ИИ.

В одной из компаний‑разработчиков ПО эта практика распространилась от одного агента к другому. ИИ, выполнявшие задачи для нескольких инженеров, стартовали публиковать скриншоты для проверки кода в открытом доступе в начале июля.

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

Приблизительно в трети затронутых организаций авторы использовали gitshot — небольшую утилиту с открытым исходным кодом, предназначенную для загрузки скриншотов при проверке кода. В ряде крупных компаний агенты находили этот инструмент и использовали его, чтобы обойти ограничения командной строки.

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

Специалисты Glow обнаружили более 100 публичных аккаунтов, через которые с помощью gitshot распространялись материалы о внутренней работе компаний. Так, в одной из фирм, предоставляющих финансовые услуги, на опубликованных изображениях были видны внутренняя консоль казначейства и расчётов, экран вывода средств конкретного клиента, а также две видеозаписи работы консоли по управлению движением денежных средств. 

В The Hacker News проанализировали код утилиты gitshot. По умолчанию, если потребитель авторизован в gh, средство сохраняет изображения в публичном репозитории с названием gitshot‑images в личной учётной записи этого пользователя. Проверенная релиз не поддерживает использование приватных репозиториев или репозиториев, принадлежащих организации.

Изображения хранятся как «релизные ассеты» (файлы, прикрепленные к релизу), а не вместе с исходным кодом. Любой желающий может просмотреть список этих файлов и загрузить их без авторизации.

В файле README и в описании агента (agent skill) содержится предупреждение о том, что репозиторий является публичным; там равным образом указано, что не следует скачивать в него учётные данные или скриншоты внутренних информационных панелей (дашбордов).

В ходе поиска The Hacker News было обнаружено приблизительно 130 публичных репозиториев, созданных gitshot. Результаты поиска не позволяют определить, чьи именно информация там хранятся и были ли эти репозитории созданы агентами.

Glow рекомендует проверить публичные репозитории, связанные с личными аккаунтами всех, кто вносил изменения в приватные, включая бывших сотрудников.

Компаниям рекомендуется изучать не только файлы, но релизы и Gist‑фрагменты (gists), искать репозитории с названием gitshot-images и релизы с тегом _gitshot, не полагаться исключительно на сканеры, которые анализируют текст.

Чтобы предотвратить подобные ситуации в будущем, Glow рекомендует передать контроль над настройкой агентов специалистам по безопасности, а не оставлять это на усмотрение отдельных разработчиков. Компания предлагает следующие меры:

• ввести обязательную процедуру проверки перед тем, как агент создаст публичный репозиторий, отправит данные в личный аккаунт или Gist либо сделает приватный репозиторий публичным;

• анализировать общие файлы навыков (skills) и инструкций, загружаемые агентами, так как именно через них могут распространяться подобные обходные решения;

• проверять рабочие компьютеры сотрудников на наличие инструментов вроде gitshot и удалять их.

Ещё один способ предлагает инструмент командной строки GitHub. Начиная с версии 2.99.0, выпущенной 1 сентября, утилита gh позволяет прикреплять изображения к пул‑реквестам, задачам (issues) или комментариям с помощью флага --attach. По заявлению платформы, этот флаг могут использовать и агенты для написания кода. Для работы функции требуются права на запись в репозиторий; она поддерживается в GitHub.com и GitHub Enterprise Cloud, но не в GitHub Enterprise Server.