{"meta":{"title":"Building guardrails for GitHub Copilot cloud agent","intro":"Configure your enterprise so that Copilot cloud agent will operate in a secure, compliant environment.","product":"GitHub Copilot","breadcrumbs":[{"href":"/en/copilot","title":"GitHub Copilot"},{"href":"/en/copilot/tutorials","title":"Tutorials"},{"href":"/en/copilot/tutorials/cloud-agent","title":"Cloud agent"},{"href":"/en/copilot/tutorials/cloud-agent/build-guardrails","title":"Build guardrails"}],"documentType":"article"},"body":"# Building guardrails for GitHub Copilot cloud agent\n\nConfigure your enterprise so that Copilot cloud agent will operate in a secure, compliant environment.\n\nBefore you enable Copilot cloud agent, it is good practice to set up your enterprise so you can be confident Copilot will operate within secure, predictable guardrails.\n\n## Learn about built-in protections\n\nCopilot cloud agent has a strong base of built-in security protections designed to protect against common risk points of AI agents. See [Risks and mitigations for GitHub Copilot cloud agent](/en/copilot/concepts/agents/cloud-agent/risks-and-mitigations).\n\n## Plan policy settings\n\nPlan your policies for Copilot cloud agent in advance. Policies allow you to set a baseline for restrictions at the enterprise level, which organization owners can restrict further if needed.\n\nSome questions to ask are:\n\n* Which organizations and repositories will Copilot cloud agent be enabled in? See [Managing access to GitHub Copilot cloud agent](/en/copilot/concepts/agents/cloud-agent/access-management).\n* Which MCP servers will you configure to give Copilot cloud agent access to external tools? See [Configure MCP servers for your repository](/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-mcp-servers).\n\n### Which policies don't apply?\n\nThe following Copilot policies don't apply to Copilot cloud agent:\n\n* Content exclusions\n* Custom models (providing your own LLM API keys)\n* Private MCP registries\n\n## Adapt rulesets\n\nCopilot cloud agent 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 cloud agent is subject to rulesets just like human developers.\n\nTo adapt your rulesets for Copilot cloud agent:\n\n* **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 cloud agent will be enabled, you can apply a custom property to them so they're easy to target in a ruleset.\n* **Consider whether Copilot cloud agent 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.\n* **Protect important Copilot and MCP configuration files** with a `CODEOWNERS` file, 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 customization cheat sheet](/en/copilot/reference/customization-cheat-sheet).\n\n## Set up your GitHub Actions environment\n\nCopilot cloud agent operates on GitHub Actions runners. Set up your runners and policies so that Copilot operates securely.\n\n### Store data and secrets\n\nContinue 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.\n\nIf you need to provide data and secrets that Copilot cloud agent *does* need, you'll be able to do this by configuring Agents secrets and variables at the organization or repository level. For more information, see [Configure secrets and variables for Copilot cloud agent](/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/configure-secrets-and-variables).\n\n### Configure runners\n\nDecide which runners you will use for Copilot cloud agent. We recommend using **GitHub-hosted runners**, so that each Copilot cloud agent runs on a fresh virtual machine. If you use self-hosted runners, we recommend using ephemeral runners.\n\nOrganization owners can restrict the Copilot cloud agent's runners to a specific runner label, to be used automatically in all repositories. See [Configuring runners for GitHub Copilot cloud agent in your organization](/en/copilot/how-tos/administer-copilot/manage-for-organization/configure-runner-for-coding-agent).\n\n### Configure workflow policies\n\nDecide whether **GitHub Actions workflows should be blocked from running** in pull requests that Copilot cloud agent creates. See [Configuring settings for GitHub Copilot cloud agent](/en/copilot/how-tos/use-copilot-agents/cloud-agent/configuring-agent-settings#allowing-github-actions-workflows-to-run-automatically-when-copilot-pushes).\n\nBy 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.\n\n### Review default permissions\n\nReview the default permissions for the `GITHUB_TOKEN` in your enterprise. See [Enforcing policies for GitHub Actions in your enterprise](/en/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#workflow-permissions).\n\nThis 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.\n\nBear 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."}