# Предоставление облачному агенту GitHub Copilot доступа к ресурсам вашей организации Получите больше Copilot пользы, предоставив доступ к утверждённым серверам MCP и внутренним пакетам. Copilot облачный агент может подключаться к MCP-серверам, использовать приватные пакеты и получать доступ к внешним сервисам, но только если репозитории вашей организации настроены на это. Хотя большая часть приведённой ниже конфигурации реализуется на уровне репозитория, владельцы организаций контролируют ресурсы, которые находятся в области действия и кто может настроить к ним доступ. ## Пример сценария Ваша организация использует Sentry для отслеживания багов в приложении Node. Новые исключения появляются как проблемы на GitHub, и ваши разработчики хотят назначить эти проблемы на Copilot. Вы хотите Copilot : * Подключитесь к серверу Sentry MCP, чтобы он мог получить доступ к деталям вашего экземпляра Sentry * Устанавливайте зависимости, включая приватные пакеты, размещённые на GitHub, чтобы сформировать приложение и запускать тесты * Следуйте конвенциям вашей организации по устранению ошибок ## Безопасное хранение секретов По умолчанию Copilotобласть действия токена аутентификации ограничена репозиторием, в котором он выполняется. Это означает, что Copilot он не сможет аутентифицироваться во внешних системах или получить доступ к частным пакетам с организационным охватом. Для обеспечения Copilot доступа к секретам администраторы репозиториев могут настраивать секреты агентов. Владельцы организаций также могут добавлять секреты агентов на уровне организации для совместного использования конфигурации между несколькими репозиториями. Copilot может получить доступ к этим данным во время настройки и выполнения задачи. Он не сможет получить GitHub Actionsдоступ к , Codespacesили Dependabot к секретам и переменным. Дополнительные сведения см. в разделе [Настройте секреты и переменные для облачного агента Copilot](/ru/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/configure-secrets-and-variables). ### Пример: Сохранить секрет Администратор репозитория сохраняет токен аутентификации для экземпляра Sentry организации. 1. Перейдите в раздел **«Секреты и переменные** > **» Агенты** в настройках репозитория. 2. Сохраните токен доступа для вашего экземпляра Sentry в секрете под названием `COPILOT_MCP_SENTRY_ACCESS_TOKEN`. > \[!TIP] Нам не нужно сохранять токен для приватного GitHub Packages реестра, к которому мы получим доступ через стандартный GitHub Actions`GITHUB_TOKEN`. Однако, если вы используете внешний реестр пакетов, нужно сохранить токен аутентификации. ## Настройка доступа к серверам MCP Владельцы организаций и предприятий могут устанавливать политику, позволяющую пользователям настраивать доступ к серверам MCP. Если эта политика включена, пользователи могут настраивать MCP-серверы в Copilot облачный агент настройках репозитория или в пользовательских профилях агентов. Для согласованности на уровне всей организации мы рекомендуем создавать **индивидуальные профили агентов** на уровне организации или предприятия. Сессия с пользовательским агентом имеет доступ к MCP-серверам, настроенным **как** в настройках репозитория, так и в профиле агента. Однако чем больше случаев использования вы охватываете с пользовательскими агентами на уровне всей организации, тем меньше пользователям нужно будет настраивать ad hoc доступ к серверам MCP в настройках репозитория. Рекомендуем просмотреть [GitHub реестр MCP](https://github.com/mcp) , чтобы найти надёжные и высокооценённые варианты. ### Пример: Создать пользовательский агент Владелец организации создаёт профиль индивидуального агента для агента Senti. Он имеет доступ к серверу Sentry MCP и пользовательским инструкциям для управления ошибками организации. 1. Создайте репозиторий, который называется `.github-private` в вашей организации. Опционально, владелец предприятия может установить этот репозиторий в качестве исходного для всех пользовательских агентов в предприятии. 2. В репозитории добавьте `agent.md` файл с профилем, подобным следующему. Это включает конфигурацию для сервера MCP, который ссылается на сохранённый нами секрет. ```text --- name: sentry-error-fixer description: Proposed fixes for exception issues raised from Sentry mcp-servers: sentry: type: 'local' command: 'npx' args: ['@sentry/mcp-server@latest'] env: SENTRY_ACCESS_TOKEN: ${{ secrets.COPILOT_MCP_SENTRY_ACCESS_TOKEN }} --- You are an error resolution specialist. When you're assigned an issue created by our Sentry integration, check for error details and stack traces using the MCP server, then propose a fix. Make sure you check that your proposed fix works by building the site with `npm run build` and running the test suite in `npm test`. ``` 3. Когда разработчики приписывают проблему к Copilot, они могут выбрать пользовательский агент из выпадающего меню. ## Установка частных пакетов Лучший способ дать Copilot доступ к зависимостям проекта — установить их в `copilot-setup-steps.yml` файл рабочего процесса. Этот файл определяет, как настроена среда до Copilot начала работы. Чтобы рабочий процесс мог получать ваши приватные пакеты с организационным охватом, вы обновите настройки пакетов, чтобы убедиться, что репозитории `GITHUB_TOKEN` имеют доступ к пакету. Это безопаснее, чем использование долгоживущего personal access token с разрешениями организации. ### Пример: зависимости от узлов установки Разработчик создаёт рабочий процесс для установки зависимостей узлов, определённых в файле `package-lock.json` репозитория. Это включает частные, структурируемые пакеты, размещённые на GitHub. 1. Разработчик создаёт `copilot-setup-steps.yml` файл в репозитории. 2. Они добавляют шаги для установки зависимостей проекта. Рассмотрим пример. ```yaml # ... jobs: copilot-setup-steps: # ... # You can define any steps you want, and they will run before the agent starts. # If you do not check out your code, Copilot will do this for you. steps: - name: Checkout code uses: actions/checkout@v6 - name: Set up Node.js uses: actions/setup-node@v4 with: node-version: "20" cache: "npm" - name: Install JavaScript dependencies run: npm ci ``` 3. Администратор организации гарантирует, что репозиторий имеет доступ к частным пакетам организации, предоставляя доступ к репозиторию в настройках каждого пакета. См [. раздел AUTOTITLE](/ru/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#github-actions-access-for-packages-scoped-to-organizations). > \[!TIP] Если вам нужно получить доступ к пакетам, которые размещены внутри вашей корпоративной сети, возможно, придётся запускать Copilot облачный агент на самостоятельных GitHub Actions платформах. ## Управление тем, кто может настраивать эти настройки Теперь, когда вы увидели, как контролируется доступ к ресурсам на уровне репозитория и организации, подумайте, сколько возможностей вы хотите предоставить пользователям для управления этими настройками. 1. **Выберите репозитории с доступом** к Copilot облачный агент. Если вас беспокоит конкретный репозиторий, вы можете заблокировать его для всех пользователей. 2. **Подумайте, кто получает администраторский доступ** к этим репозиториям. Вы можете контролировать это на уровне организации, создав команду с пользовательской **ролью администратора всех репозиториев** . Эти пользователи смогут управлять *настройками* конфигурации, такими как конфигурация MCP и секреты и переменные агентов, в каждом репозитории. 3. **Используйте наборы правил и файлы CODEOWNERS** для управления редактированием *конфигурационных файлов*, таких `copilot-setup-steps.yml`как , которые по умолчанию может редактировать любой человек с правом записи. 4. **Проверьте стандартный межсетевой экран**. Файрвол не влияет на подключение к серверам MCP или этапы настройки, `copilot-setup-steps.yml`но ограничивает Copilotдоступ к Интернету во время выполнения задач. См [. раздел AUTOTITLE](/ru/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/customize-the-agent-firewall).