Доступ AI-агентов к репозиториям: least privilege для GitLab и GitHub

Самый частый способ подключить code-агента — вставить в его конфиг personal access token разработчика. Агент получает всё сразу: чтение всех групп, push в main, изменение CI-переменных, управление участниками. Один неверный вызов — и «помощь с рефакторингом» становится force-push в прод-ветку.

Почему токен разработчика — перебор прав

Токен человека отражает его должность, а не задачу агента. Разработчик состоит в десяти группах — агент наследует все десять, хотя чинит баг в одном репозитории. Промпт «не пушь в main» — не контроль: модель читает неструктурированный текст и решает сама, а scope токена разрешает всё. Как отмечают в обзоре OAuth-проблем, over-scoping — дефолт: разработчики просят широкие права «чтобы работало», и эти права живут годами после потери смысла.

Три уровня доступа

Read — клонирование, чтение файлов, поиск по коду, чтение MR и issues. Достаточно для review-агентов и Q&A по кодовой базе.
MR-only — плюс создание веток и MR, запуск pipeline. Агент предлагает изменения, человек их принимает. Целевой уровень для большинства code-агентов.
Scoped write — запись только в обозначенные репозитории и ветки, без прав на настройки, участников и секреты CI. Только для доверенных автоматизаций с владельцем.

Уровень выбирается под задачу, а не под агента «вообще». Review-боту не нужен write, а релиз-автоматизации не нужен доступ ко всем группам.

Scope токенов под агента

GitLab — project access token вместо personal: read_repository для read-уровня, плюс write_repository для MR-only, привязка к конкретным проектам, ротация и expiry. Групповые токены — только если агент обслуживает всю группу осознанно.
GitHub — fine-grained PAT или GitHub App с contents: read, pull_requests: write на выбранные репозитории. Классический PAT с repo-scope — аналог личного токена, агенту его давать нельзя.
Запрет на секреты — агент не должен видеть CI/CD-переменные и deploy-токены. Маскируйте их на шлюзе: агент вызывает «запустить pipeline», не читая переменные.

Отдельный service account на агента, а не shared-токен команды: иначе отзыв ломает всех, а аудит не различает кто вызвал.

Branch protection как последний рубеж

Даже с узкими scope держите технические барьеры в самом GitLab/GitHub:

main и релизные ветки — protected, push запрещён всем кроме мейнтейнеров-людей;
MR требует approve от человека и зелёный pipeline;
force-push запрещён везде, где агент имеет write;
signed commits для автоматизаций со scoped write.

Тогда ошибка агента останавливается платформой, а не надеждой на промпт.

Аудит каждого изменения

Для каждого действия агента фиксируйте: agent_id × human_delegator × repo × ref × commit × результат. Вопросы «кто создал эту ветку», «чей MR смержил бот» и «что агент менял в CI-конфиге за 90 дней» должны закрываться одним запросом к журналу, а не опросом команды.

Где Codenik

Codenik выносит секрет из конфига агента: токен GitLab/GitHub хранится на сервере, агент вызывает разрешённые инструменты — «прочитать файл», «открыть MR», «запустить pipeline». Push в защищённые ветки невозможен технически: такого инструмента у агента просто нет. Отзыв — одна операция в шлюзе, а не поиск токена по ноутбукам и .env.

Короткий вывод

Агенту к репозиторию — отдельный service account, минимальный scope, MR-only по умолчанию и branch protection как страховка. Токен разработчика в конфиге агента — это доступ человека без ответственности человека.