Before you enable Copilot云代理, it is good practice to set up your enterprise so you can be confident Copilot will operate within secure, predictable guardrails.
Learn about built-in protections
Copilot云代理 has a strong base of built-in security protections designed to protect against common risk points of AI agents. See GitHub Copilot云代理的风险和缓解措施.
Plan policy settings
Plan your policies for Copilot云代理 in advance. Policies allow you to set a baseline for restrictions at the enterprise level, which organization owners can restrict further if needed.
Some questions to ask are:
- Which organizations and repositories will Copilot云代理 be enabled in? See 管理对 GitHub Copilot 云代理的访问权限.
- Which MCP servers will you configure to give Copilot云代理 access to external tools? See 使用模型上下文协议（MCP）扩展GitHub Copilot云代理.
Which policies don't apply?
The following Copilot policies don't apply to Copilot云代理:
- Content exclusions
- Custom models (providing your own LLM API keys)
- Private MCP registries
Adapt rulesets
Copilot云代理 is already restricted from actions like pushing to a default branch or merging pull requests. You can build on these default protections in branch rulesets. Copilot云代理 is subject to rulesets just like human developers.
To adapt your rulesets for Copilot云代理:
- Consider whether additional rules are required in repositories where agents will operate, such as requiring results from code scanning or Code Quality. If you have identified the organizations or repositories where Copilot云代理 will be enabled, you can apply a custom property to them so they're easy to target in a ruleset.
- Consider whether Copilot云代理 will be blocked by any of your existing rulesets. Copilot can sign its commits, but it may not be able to follow other rules that restrict commit metadata.
- Protect important Copilot and MCP configuration files with a
CODEOWNERSfile, and enable the "Require review from Code Owners" rule, so that edits to these files must be approved by specific teams. For filepaths to target, see Copilot自定义备忘单.
Set up your GitHub Actions environment
Copilot云代理 operates on GitHub Actions runners. Set up your runners and policies so that Copilot operates securely.
Store data and secrets
Continue to store data and tokens that you don't want Copilot to access as GitHub Actions variables or secrets. Copilot won't be able to access these in its sessions or environment setup steps.
If you need to provide data and secrets that Copilot云代理 does need, you'll be able to do this in a specific copilot environment.
Configure runners
Decide which runners you will use for Copilot云代理. We recommend using GitHub-hosted runners, so that each Copilot云代理 runs on a fresh virtual machine. If you use self-hosted runners, we recommend using ephemeral runners.
Organization owners can restrict the Copilot云代理's runners to a specific runner label, to be used automatically in all repositories. See 为组织中的 GitHub Copilot 云代理配置运行器.
Configure workflow policies
Decide whether GitHub Actions workflows should be blocked from running in pull requests that Copilot云代理 creates. See 配置 GitHub Copilot 云代理的设置.
By default, workflows are blocked from running until someone with write access approves them. Repository administrators will be able to disable this feature, so communicate with them in advance about your preferred setting.
Review default permissions
Review the default permissions for the GITHUB_TOKEN in your enterprise. See 在企业中强制实施GitHub Actions策略.
This policy does not affect the token that Copilot will receive for its sessions, but the GITHUB_TOKEN is used in environment setup steps defined in copilot-setup-steps.yml workflow files.
Bear in mind that developers will be able to set their own permissions in these workflow files, and you should encourage them to use the minimum required permissions in all workflows.
Next steps
When you're ready to enable Copilot云代理, see 在企业中管理GitHub Copilot云代理.