GitLost легко раздуть до паники и так же легко недооценить. Это не история о том, что любой private repository на GitHub теперь можно украсть через public issue. Но это хороший пример нового риска: AI-агент одновременно видит приватные данные, читает чужой ввод и может писать наружу.

AI-агент и граница доверия между публичными issues и приватными репозиториями

Noma Labs опубликовала исследование GitLost 6 июля. Целью были GitHub Agentic Workflows, preview-функция, где repository automation описывается в Markdown, а AI-агент запускается внутри GitHub Actions. Он может читать issues и pull requests, вызывать инструменты и отвечать через разрешённые outputs. В документации GitHub делает упор на защиту: read-only tokens по умолчанию, sandboxing, safe outputs и threat detection перед публикацией результата.

Это полезные меры. Но они не убрали главный риск. В PoC Noma публичный issue в public repository организации заставил агента прочитать данные из private repository и опубликовать результат в public comment. По описанию Noma и The Hacker News, атакующему не нужны были украденные credentials или доступ к приватному репозиторию. Опасной была сама связка: агент читает public input, имеет широкий read access к private repos и может отвечать в публичный канал.

Вот это и важно. Не паника, не лозунг "GitHub сломан", а более точный вывод: если AI-агент слушает внешних людей, читает внутренние данные и пишет наружу, prompt становится управляющим интерфейсом.

Что произошло в GitLost

GitHub Agentic Workflows стартовали как technical preview в феврале, а сейчас в документации проекта описаны как public preview. Идея понятная: вместо сложного YAML команда пишет Markdown workflow на естественном языке, gh-aw CLI компилирует его в GitHub Actions, а агент занимается triage, pull requests, CI failures, документацией или maintenance-задачами.

Для продукта это выглядит как automation. Для security это service account с языковым интерфейсом.

В уязвимой конфигурации Noma workflow срабатывал при назначении issue. Он читал title и body, а затем отвечал через add-comment output. При этом у агента был read access к другим репозиториям организации, включая private repos. Issue выглядел как обычная бизнес-просьба. После запуска агент достал README из public и private repositories и вставил содержимое в публичный комментарий.

Точную prompt-формулировку не стоит превращать в инструкцию. Но один факт важен: Noma и The Hacker News сообщили, что небольшое изменение формулировки помогло пройти guardrail, который должен был остановить публикацию. Это не "магическое слово", а напоминание: фильтр не является границей безопасности.

Масштаб ограничен, но риск реальный

GitLost не означает, что любой public issue достанет любой private repo. Нужна конкретная комбинация: включённый agentic workflow, public или attacker-controlled input, token или tool path с доступом к private repositories и output, который может публиковать результат наружу.

Но именно такие комбинации всё чаще появляются в бизнесе. Агент читает tickets, PR, support messages, Sentry events, Slack threads или issue comments. Потом собирает внутренний контекст. Потом публикует ответ. Польза возникает от соединения зон доверия. Риск возникает там же, если границы не спроектированы.

Read-only тоже часто понимают неправильно. Read-only token не может push'ить код, но он может читать секретную информацию. Если тот же агент может отправить текст во внешний канал, read-only уже достаточно для утечки.

Lethal trifecta здесь видна без натяжки

Модель Simon Willison про "lethal trifecta" хорошо объясняет GitLost: private data, untrusted content и external communication. Если все три элемента находятся внутри одного агента, prompt injection перестаёт быть смешным трюком и становится маршрутом утечки.

В GitLost private data — это содержимое репозитория. Untrusted content — публичный issue. External communication — публичный comment. Уберите один элемент, и риск сильно меняется. Public issue без доступа к private data гораздо менее опасен. Анализ private data без публичного output сложнее превратить в утечку. Бот, который пишет public comments, но не читает private repositories, имеет меньше возможностей навредить.

Вывод не в том, что agents нельзя использовать. Вывод в том, что зоны доверия должны совпадать. Public input не должен авторизовать доступ к private data. Private analysis не должен автоматически превращаться в public output.

Спор вокруг GitLost полезен

В HN-дискуссии видны три позиции. Одни говорят: это очевидная misconfiguration, зачем вообще давать public-issue workflow широкий доступ к private repos. Другие считают это проблемой agent security: модель не умеет надёжно отделять инструкции владельца от текста атакующего. Третьи видят старую историю: платформы быстро добавляют AI-функции, а controls для администраторов созревают позже.

Все три позиции частично верны. Token scope и triggers сделали утечку возможной. Агент принял untrusted text как actionable instruction. Продуктовые defaults и warnings влияют на то, как часто такие конфигурации появятся случайно.

Что проверить перед запуском агента

Есть три вопроса: что агент может читать, кто может писать в его context и куда он может отправить результат.

Если ответы такие: private repositories, любой автор public issue и public comment, workflow надо остановить. Это не безобидная автоматизация, а потенциальный канал exfiltration.

Scope токенов должен быть минимальным. Workflow для triage одного public repo почти никогда не нуждается в org-wide read access к private repos. Если нужен cross-repo context, лучше сделать отдельный workflow, отдельную identity и review перед выходом результата наружу.

Public-facing и private-facing agents стоит разделять. Агент, который отвечает на public issues, не должен быть тем же actor, который читает sensitive internal repositories. Агент, который делает private analysis, не должен напрямую публиковать public comment.

Практические меры

Используйте per-repo или per-purpose tokens вместо broad organization-level tokens. Предпочитайте short-lived credentials. Не давайте агентам personal access token разработчика, если задачу можно решить через узкую service identity.

Ограничивайте triggers. Public issues и comments не должны автоматически запускать агента с private access. Нужны labels, membership checks, trusted authors, maintainer approval или внутренний handoff.

Держите private data внутри private workflow. Отчёт, собранный на основе private repositories, должен попадать в private issue, internal channel или PR для нужной группы. Публикация наружу должна быть отдельным reviewed action.

Логи должны быть пригодны для incident response: какой issue запустил run, какие repos читались, какой token использовался, какой output предложил агент и кто его утвердил.

Что нужно от vendors

Поставщики не должны сваливать всё на пользователя. Agent platforms нужны явные trust labels. Контент из public issues, external PRs, logs, web pages и MCP tools должен сохранять происхождение. Политика должна уметь сказать: этот текст можно использовать для анализа, но он не может авторизовать private read или public write.

Permissions должны быть понятными. "Read-only" недостаточно, если агент читает private data и может писать публично. "Autonomous" недостаточно, если администратор не видит tools, repositories, outputs и network paths.

Preview features требуют жёстких warnings. В документации GitHub уже есть предупреждения про prompt injection, malicious repository content и compromised tools. Следующий шаг — сделать опасные cross-boundary комбинации сложными для случайного создания.

Главное без паники

GitLost не причина отказаться от AI automation. Это причина перестать воспринимать агентов как chat windows.

AI-агент в developer workflow — credentialed actor. Он читает, делает выводы и действует с теми правами, которые ему выдали. Намерения модели менее важны, чем граница вокруг неё.

Практическое правило простое: не соединяйте public input, private data и public output в одном unattended agent. Если границу нужно пересечь, сделайте это узко, явно, с review и логами.