Перед тем как вы начнёте Copilot cloud agent, рекомендуется организовать бизнес так, чтобы вы были уверены Copilot , что вы будете работать в безопасных и предсказуемых условиях.
Узнайте о встроенных защитах
Copilot cloud agent имеет прочную базу встроенных систем защиты, предназначенных для защиты от типичных точек риска агентов ИИ. См . раздел AUTOTITLE.
Параметры политики плана
Планируйте свои полисы Copilot cloud agent заранее. Политики позволяют установить базовый уровень ограничений на уровне предприятия, которые владельцы организаций могут дополнительно ограничить при необходимости.
Некоторые вопросы, которые стоит задать:
- В каких организациях и репозиториях будет Copilot cloud agent включено? См . раздел AUTOTITLE.
- Какие MCP-серверы вы настраиваете так, чтобы они предоставляли Copilot cloud agent доступ к внешним инструментам? См . раздел AUTOTITLE.
Какие политики не применяются?
Следующие Copilot правила не применяются к Copilot cloud agent:
- Пользовательские модели (предоставление собственных LLM-API-ключей)
- Частные реестры MCP
Правила адаптации
Copilot cloud agent уже ограничен в действиях, таких как push на стандартную ветку или слияние pull request. На основе этих стандартных защит можно строить в наборах правил ветвь. Copilot cloud agent подчиняется правилам, как и человеческие разработчики.
Чтобы адаптировать ваши наборы правил для Copilot cloud agent:
- Рассмотрим, требуются ли дополнительные правила в репозиториях, где агенты будут действовать, например, требование результатов из code scanning или Code Quality. Если вы определили организации или репозитории, где Copilot cloud agent будет включено, вы можете применить к ним пользовательское свойство, чтобы их было легко таргетировать в наборе правил.
- Подумайте, будет Copilot cloud agent ли блокировка какой-либо из ваших существующих правил. Copilot может подписывать свои коммиты, но может не следовать другим правилам, ограничивающим метаданные коммита.
- Защитите важные Copilot и MCP-конфигурационные файлы
CODEOWNERSс помощью файла и включите правило «Требуется проверка от владельцев кода», чтобы правки в этих файлах должны были быть одобрены конкретными командами. Для целевых путей файлов см. Шпаргалка для кастомизации Copilot.
Настройте свою GitHub Actions среду
Copilot cloud agent Действует на GitHub Actions бегунах. Настройте свои полисы и полисы так, чтобы они Copilot работали безопасно.
Храните данные и секреты
Продолжайте хранить данные и токены, к которым _не_Copilot хотите обращаться как GitHub Actions к переменным или секретам. Copilot не смогу получить доступ к ним в сессиях или этапах настройки среды.
Если вам нужно предоставить данные и секреты, которые Copilot cloud agent_действительно_ нужны, вы сможете сделать это, настраивая секреты и переменные агентов на уровне организации или репозитория. Дополнительные сведения см. в разделе Настройте секреты и переменные для облачного агента Copilot.
Настройка раннеров
Решите, какие бегуны вы будете использовать для Copilot cloud agent. Мы рекомендуем использовать GitHub-hosted runners, чтобы каждый Copilot cloud agent работал на новой виртуальной машине. Если вы используете самостоятельные бегунки, мы рекомендуем использовать эфемерные бегуны.
Владельцы организаций могут ограничивать Copilot cloud agent's runners определённой меткой, которая будет использоваться автоматически во всех репозиториях. См . раздел AUTOTITLE.
Настройка политик рабочего процесса
Решите, стоитGitHub Actions ли блокировать рабочие процессы для запуска в pull requests, которые Copilot cloud agent создают. См . раздел AUTOTITLE.
По умолчанию рабочие процессы блокируются до тех пор, пока кто-то с доступом к записи не одобрит их. Администраторы репозиториев смогут отключить эту функцию, поэтому заранее сообщите им о своих предпочтениях.
Просмотр стандартных разрешений
Проверьте стандартные права для GITHUB_TOKEN вашего предприятия. См . раздел AUTOTITLE.
Эта политика не влияет на токен, который Copilot будет получен за сессии, но GITHUB_TOKENиспользуется в этапах настройки среды, определённых в copilot-setup-steps.yml файлах рабочего процесса.
Имейте в виду, что разработчики смогут настраивать свои права permissions в этих файлах рабочих процессов, и вам следует поощрять их использовать минимальные требования разрешений во всех рабочих процессах.