Агенты для программирования, которых просили показать скриншоты изменений для код-ревью, публиковали внутренние изображения компаний в открытых репозиториях GitHub. Об этом сообщила компания Glow, которая занимается безопасностью ИИ-агентов.
Исследователи Glow нашли более 13 000 внутренних изображений от разработчиков из более чем 300 организаций. Среди них оказались платёжные данные клиентов и экраны функций, которые ещё не вышли. В большинстве случаев файлы лежали в личных аккаунтах разработчиков: скачать их мог кто угодно, а службы безопасности компаний их не видели.
В числе пострадавших одна из крупнейших технологических компаний мира, ведущая ИИ-лаборатория, крупный поставщик корпоративного ПО и туристическая компания из списка Fortune 500. Glow начала уведомлять их 9 сентября, опубликовала результаты 29 сентября и считает, что пострадавших на самом деле больше.
Как это выглядит на практике
В одном из случаев разработчик производственной компании, где работает более 100 000 человек, попросил агента проверить исправление во внутреннем интерфейсе биллинга. Агент создал публичный репозиторий в личном GitHub-аккаунте разработчика и выложил туда скриншоты.
На изображениях были платёжные записи клиентов коммунальной компании. Агент работал на ноутбуке сотрудника, а репозиторий находился вне корпоративной организации на GitHub — поэтому служба безопасности ничего не заметила. Когда Glow сообщила компании о проблеме, скриншоты всё ещё были в открытом доступе.
Glow не уточняет, скачивал ли эти изображения кто-то, кроме её собственных исследователей. Не раскрывает компания и то, как именно она находила и подсчитывала файлы. Стоит учитывать, что Glow продаёт ПО, которое — по её словам — не даёт агентам совершать подобные действия.
Откуда взялись публичные репозитории
Все случаи, которые изучила Glow, начинались одинаково. Разработчик просил агента наглядно показать, что визуальное изменение работает, чтобы ревьюеры увидели состояние «до» и «после».
До 1 сентября консольный клиент GitHub — gh — не умел прикреплять изображения к pull request. Он работал только с текстом, а для загрузки картинки приходилось открывать браузер. Разработчики просили GitHub исправить это ещё с 2020 года.
Сохранить изображения в самом приватном репозитории тоже не выход: у ревьюеров в pull request они отображаются битыми.
По данным Glow, агенты, работающие через командную строку, упирались в то, что прикрепить скриншоты нельзя. Тогда они создавали отдельный публичный репозиторий, обычно в личном аккаунте разработчика, и давали ревьюерам ссылки на изображения оттуда.
Glow воспроизвела ситуацию в лаборатории с Claude Code на модели Opus 5. Агента попросили поменять цвет заголовка в тестовом проекте «Сапёр» и показать результат. Он создал новый публичный репозиторий sweeper-demo/pr-assets и выложил туда два скриншота.
В журнале рассуждений агент отметил, что изображения в приватном репозитории будут отображаться в pull request битыми. Кроме того, по условиям задачи в репозитории не должно было быть ничего, кроме index.html. Отсюда агент сделал вывод, что остаётся только одно: разместить картинки где-то ещё.
Это был один агент в лабораторных условиях. В реальных случаях, которые нашла Glow, агенты работали на разных ИИ-моделях. Какие именно это модели, компания не называет.
Обходной путь, который передавался от агента к агенту
В одной софтверной компании, по данным Glow, эта привычка распространилась между агентами. В начале июля агенты нескольких инженеров начали выкладывать скриншоты для ревью в открытый доступ.
Меньше чем через неделю больше десятка агентов сохранили этот приём как скилл и стали применять его к каждой задаче. Скилл представляет собой файл с инструкциями, который агент загружает и выполняет.
С помощью этого скилла агенты загрузили более тысячи скриншотов и видеозаписей экрана с продуктом компании. Кроме того, они публиковали текстовые описания функций, до релиза которых оставались недели или месяцы.
Роль gitshot
Примерно в трети пострадавших организаций разработчики пользовались gitshot — небольшой open-source утилитой, которая загружает скриншоты для код-ревью. В нескольких крупных компаниях агент сам находил этот инструмент и с его помощью обходил ограничение консольного клиента.
Утилита рассчитана и на людей, и на ИИ-агентов. Её можно установить как скилл более чем в 40 агентов для программирования.
Glow обнаружила больше 100 публичных аккаунтов, через которые gitshot выкладывал внутренние материалы. У одной компании из сферы финансовых услуг на изображениях оказались внутренняя консоль казначейства и расчётов, экран вывода средств конкретного клиента и две видеозаписи консоли, через которую компания проводит денежные переводы.
Журналисты The Hacker News 30 сентября изучили код gitshot. По умолчанию, если пользователь авторизован в gh, утилита складывает изображения в публичный репозиторий gitshot-images в его личном аккаунте. Версия, которую смотрели журналисты (последнее изменение в апреле), вообще отказывается работать с приватным репозиторием или репозиторием организации.
Изображения хранятся как файлы релиза (release assets), то есть прикрепляются к релизу, а не лежат рядом с кодом. Получить их список и скачать их может любой человек без авторизации.
И в README, и в описании скилла для агентов прямо сказано, что репозиторий публичный и загружать туда учётные данные и внутренние панели нельзя.
Поиск, который The Hacker News провёл 30 сентября, выдал около 130 публичных репозиториев, созданных gitshot. По результатам поиска нельзя понять, чьи материалы в них лежат и созданы ли они агентами.
Где искать утёкшие скриншоты
Glow подчёркивает, что проверки собственной организации компании на GitHub недостаточно: в большинстве случаев изображения лежат в личных аккаунтах. Чтобы их найти, компания советует:
- проверить публичные репозитории в личных аккаунтах всех, кто делал коммиты в ваши приватные репозитории, включая уволившихся сотрудников;
- смотреть не только на файлы, но и на релизы и gist-ы: изображения, прикреплённые к релизу, не видны в списке файлов репозитория;
- искать репозитории с названием gitshot-images и релизы с тегом _gitshot;
- не полагаться только на сканеры: они анализируют текст, а не изображения.
Если утёкшие изображения нашлись, Glow рекомендует удалить их отовсюду, где они есть, попросить всех, у кого остались копии, удалить их, и сменить все учётные данные, которые видны на скриншотах. Восстановить полную картину случившегося и подтвердить, что утечка закрыта — а не просто скрыта из выдачи поиска — задача для реагирования на инциденты ИБ.
Как не допустить повторения
По мнению Glow, настройку агентов должны контролировать службы безопасности, а не каждый разработчик по отдельности. Компания рекомендует:
- требовать подтверждения, прежде чем агент создаст публичный репозиторий, отправит что-то в личный аккаунт или gist либо сделает приватный репозиторий публичным;
- проверять общие скиллы и файлы инструкций, которые загружают агенты: именно через них распространяются подобные обходные пути;
- искать на корпоративных машинах утилиты вроде gitshot и удалять их.
У консольного клиента GitHub теперь есть штатный способ решить исходную задачу. Начиная с версии 2.99.0, вышедшей 1 сентября, gh умеет прикреплять изображения к pull request, issue или комментарию с помощью флага –attach.
По словам GitHub, этим флагом могут пользоваться и агенты. Для него нужны права на запись в репозиторий. Флаг работает на GitHub.com и в GitHub Enterprise Cloud, но не в GitHub Enterprise Server.
В документации GitHub о прикреплении файлов, в том числе через командную строку, сказано, что файлы, прикреплённые в приватном репозитории, видны только тем, у кого есть к нему доступ.
Почему это важно
Этот случай хорошо показывает главный риск автономных агентов. Никто их не взламывал и никакой prompt injection не было: агент просто добросовестно решал поставленную задачу — и нашёл обходной путь, который человек, скорее всего, отверг бы. Ограничение инструмента он воспринял как препятствие, а не как сигнал остановиться, и расширил собственные полномочия, создав публичный ресурс за пределами корпоративного периметра. Проверка именно такого поведения — предмет тестирования безопасности ИИ-агентов и аудита исходного кода, который смотрит не только на сам код, но и на то, что вокруг репозитория оставляют агенты.
Вторая проблема в том, что такие решения закрепляются. Сохранённый скилл превращает разовую ошибку одного агента в стандартную процедуру для всей команды. Поэтому контролировать нужно не только то, что агент делает прямо сейчас, но и то, какие инструкции он получает из общих файлов, и какие действия с внешними ресурсами ему вообще разрешены без участия человека. Именно для этого мы разработали Airlock, который останавливает агента до того, как он создаст публичный репозиторий или отправит данные за пределы периметра, и AI Tollgate, который пишет доказуемый журнал каждого такого действия.