Каждый третий PR пишет агент: как защитить секреты

По данным GitHub, сегодня в каждом третьем pull request участвует AI-агент, а год назад таких было меньше одного из десяти.

Если темп сохранится (это экстраполяция, а не прогноз GitHub), через два года большую часть кода в GitHub будет писать агент, и человек прочитает его не целиком.

Для секретов отсюда следует, что защита должна срабатывать до коммита и без участия человека на каждом шаге.

Поводом служит разбор GitHub о масштабировании защиты секретов и серия анонсов вокруг него.

Раньше утечка секрета была редким событием на человеческой скорости.

Разработчик забывал ключ в конфиге, сканер ловил его после пуша, кто-то вручную отзывал и перевыпускал.

Схема работала, пока кода писалось ограниченно много и каждую строку кто-то видел. Агент ломает оба допущения.

Он создаёт больше изменений за час, и часть из них никто не читает построчно.

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

Классический secret scanning ищет по шаблонам: у ключа облачного провайдера есть узнаваемый префикс и длина. У пароля к базе данных в переменной `db_pass` шаблона нет, поэтому такие находки проходили мимо. GitHub анонсировал специально обученную модель для поиска утёкших секретов.

Она читает окружающий код и по контексту определяет вероятные учётные данные, включая пароли без узнаваемого формата.

Модель планируют подключить в трёх местах: в alerts secret scanning, в push protection (блокировка пуша с секретом) и в security review внутри Copilot.

Наибольший эффект ждём от третьей точки.

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

Исправление в этот момент стоит дешевле всего.

Детектор срабатывает после того, как секрет появился в коде, а песочница уменьшает шанс, что он появится. Local sandboxing в GitHub Copilot вышел в GA для Copilot CLI, приложения Copilot и сессий VS Code с Agent Host.

Команды и инструменты, которые запускает Copilot, получают ограниченный доступ к файловой системе, сети и учётным данным.

Политику задаёт разработчик или организация.

Внутри работает Microsoft eXecution Container (MXC): он переводит единую политику песочницы в средства изоляции конкретной операционной системы.

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

Если у агента нет доступа к `~/.aws` и сетевого выхода наружу, украсть или выложить ему нечего.

Такой принцип мы считаем обязательным минимумом для любого агентного контура.

В AI-native разработке для клиентов мы исходим из трёх слоёв. 1. Секрет не попадает к агенту.

Токены с минимальными правами, короткий срок жизни, доступ через выделенный прокси. Ключ, которого нет в контексте модели, не окажется и в коммите. 2. Среда исполнения ограничена.

Песочница для файлов, сети и учётных данных, как в MXC.

Для серверных агентов тот же результат даёт контейнерная изоляция и egress-фильтрация. 3. Трафик к моделям идёт через одну точку. В LLM & Security Gateway запросы к внешним и локальным моделям проходят через единый шлюз, где маскируются секреты и персональные данные и ведётся аудит.

Доступ агентов к корпоративным системам через MCP-серверы получает отдельные права на каждый инструмент.

Детектор на уровне репозитория работает четвёртым слоем и страхует от остаточных ошибок.

Полагаться на него одного опасно: любая модель обнаружения даёт ложные срабатывания и пропуски. GitHub пока говорит о планах, поэтому сроки подключения к конкретным функциям стоит сверять с документацией.