GitHub Copilot Security Guide: Governing AI Coding Assistants

GitHub Copilot now spans inline suggestions, chat, a command-line agent and a cloud agent that opens pull requests, and each surface reads code and acts with a different identity and a different set of controls. Most organisations govern the seat licence and stop there, leaving content exclusion, MCP servers, the agent firewall and personal Copilot plans on the corporate network unmanaged. This guide covers the platform controls GitHub documents for Copilot Business and Copilot Enterprise: how access and policy precedence work, who can change settings, the tokens and integrations involved, what the audit log does and does not record, and a hardening baseline. It is for GitHub organisation and enterprise owners, platform engineering and application security teams. Editor-level permission settings for agent mode are covered in the AI IDE and Coding Agent Security Guide and reviewing the code itself in the AI-Generated Code Review Guide; this page does not repeat them. Details were checked against GitHub Docs in October 2026 and change often.

Key takeaways

• Enterprise policy wins. When an enterprise owner enables or disables a Copilot policy everywhere, organisation owners cannot override it, so set the non-negotiables at enterprise level.
• Content exclusion has holes. GitHub states it is not supported in Edit and Agent modes of Copilot Chat in VS Code and other editors, does not apply to symbolic links, and may still leak semantic information from excluded files; it is not a secrets control.
• The cloud agent is fenced but not sealed. It pushes only to its own branch, cannot approve or merge, and runs behind a firewall, but the firewall covers only processes started by its Bash tool, not MCP servers or setup steps.
• Prompts are not in the audit log. The GitHub audit log records seats, policy changes and agent activity for 180 days; local prompts need your own collection.
• Personal plans bypass your policies. Subscription-based network routing lets you allow the Business and Enterprise endpoints and block individual plans on corporate networks.

How identity and access work in GitHub Copilot

Copilot Business and Copilot Enterprise seats are assigned by an organisation or enterprise to a GitHub account. That account's repository permissions decide what Copilot can read on GitHub.com, and the developer's local workspace decides what it can read in the editor. Copilot adds no separate permission model on top.

• Policy precedence: organisation owners set policies under Settings, Copilot, Policies and Models. Each policy has an enforcement dropdown. An enterprise setting of enabled everywhere, disabled everywhere or enabled for selected organisations cannot be overridden by an organisation.
• Who can trigger the cloud agent: only users with write access to a repository; comments from other users are never passed to the agent.
• Partner agents: owners can allow third-party coding agents (GitHub names Anthropic Claude and OpenAI Codex) under Copilot, Cloud agent, Partner agents. They can access the same repositories where the Copilot cloud agent is enabled, so enabling them widens the set of models acting on your code, not the repository scope.
• Models: the Models page controls access to models beyond the basic set. Treat each model provider as a supplier decision.

The surfaces and what each can touch

Admin roles and privileged access

• Repository admins are agent configurators: MCP servers and setup steps are configured per repository, so the number of repository admins is the number of people who can change what the cloud agent can reach. Reduce it and alert on changes.
• Branch protection is the real gate: the agent is subject to branch protections and required checks. A repository without them relies on a single human merge. See the GitHub and GitHub Actions Security Guide.

Integrations, API tokens and service accounts

Cloud agent credentials and environment

• Agent credentials: GitHub states the agent's credentials allow only simple push operations to a single branch (the existing pull request branch or a new copilot/ branch), and that it cannot run git push or other Git commands directly. Commits are signed and show as Verified.
• Setup steps: the environment is customised with .github/workflows/copilot-setup-steps.yml containing a single job named copilot-setup-steps, active only once on the default branch. Only steps, permissions, runs-on, services, snapshot and timeout-minutes (maximum 59) are honoured. Give it the lowest permissions it needs, such as contents: read, and keep secrets out unless a step needs them. See the CI/CD Pipeline Identity Security Guide.
• Self-hosted runners: supported through runs-on, but they require disabling the integrated firewall. GitHub recommends ephemeral, single-use runners; never place the agent on a long-lived runner that holds cloud credentials.

MCP servers

• Defaults: the cloud agent gets a GitHub MCP server using a token with read-only access to the current repository, and a Playwright server limited to localhost and 127.0.0.1. Replacing the GitHub token with a broader one widens what an injected instruction could reach.
• No approval prompts: GitHub states that Copilot "will use available tools autonomously, and will not ask for approval before use". Limit the tools field of each server to what the task needs and leave out write tools.
• Scope of the policy: the "MCP servers in Copilot" policy does not govern the GitHub MCP server used from third-party hosts such as Cursor, Windsurf or Claude. Those need their own controls. See the MCP Security Guide.

Copilot CLI tokens

• Supported tokens: OAuth tokens (gho_) from copilot login, fine-grained PATs (github_pat_) owned by a personal account with the Copilot Requests permission, and GitHub App user-to-server tokens (ghu_). Classic PATs (ghp_) are not supported.
• Precedence: COPILOT_GITHUB_TOKEN, then GH_TOKEN, then GITHUB_TOKEN, then the stored OAuth token, then the GitHub CLI token. An environment variable silently overrides the stored login, so a CI token exported in a shell profile can become the CLI's identity.
• Storage: the OAuth token is kept in the OS keychain under copilot-cli. Without a keychain, for example headless Linux without libsecret, the CLI offers to write it in plaintext to ~/.copilot/config.json. Decline on shared hosts. See the SaaS API Token Security Guide.
• Tool approval: the CLI asks to trust the launch directory and to approve tools once or for the session. --allow-all-tools gives Copilot "the same access as you do to files on your computer"; --deny-tool takes precedence over allow options. GitHub describes the directory scoping as heuristic and recommends a VM, container or sandbox for automatic approval.

Logging and detection

The organisation and enterprise audit log records Copilot plan changes, policy and setting changes, seat assignment and agent activity on GitHub.com, and keeps events for 180 days. It does not include client session data such as prompts sent from the IDE or CLI; GitHub suggests a custom solution such as hooks that forward CLI events to your own logging service.

• Stream the audit log: 180 days is too short for most investigations. Stream to the SIEM, as GitHub recommends. See the SIEM Guide.
• Agent code checks: GitHub runs CodeQL, secret scanning and an Advisory Database check for malware and High or Critical dependencies on cloud agent output, plus Copilot code review, without requiring a GitHub Advanced Security licence. Record their findings as a metric rather than assuming a clean pass.

Metrics that show it is working

• Percentage of Copilot policies enforced at enterprise level rather than left to organisations.
• Repositories with the cloud agent enabled that have branch protection and required checks on the default branch.
• Repositories with the agent firewall disabled or with custom allowlist entries, reviewed quarterly.
• Number of MCP servers configured across repositories and the share limited by a tools list.
• Connections to *.individual.githubcopilot.com from corporate networks after routing is enforced.

Hardening baseline

Rolling out the baseline

1. Inventory: list seats, organisations with Copilot enabled, repositories with the cloud agent on, existing MCP configurations and any personal plan traffic seen at the proxy.
2. Set enterprise policy: decide which features are enabled everywhere, disabled everywhere or delegated, and record why.
3. Pilot ring: enable the cloud agent on a few repositories with branch protection and required checks, the firewall on and the recommended allowlist. Watch firewall warnings and session logs for two weeks.
4. Apply content exclusion and network routing: roll the organisation-wide rules out, reload editors (VS Code: "Developer: Reload Window"; changes can take up to 30 minutes), and confirm developers on minimum client versions (Copilot Chat in VS Code 0.17, Visual Studio 2022 17.11).
5. Expand: enable the agent and partner agents organisation by organisation once the pilot shows no blocked-destination surprises.
6. Roll back: disabling a policy at enterprise level, removing a repository's MCP configuration or setting the firewall back to Enabled takes effect without code changes; agent pull requests are drafts and can simply be closed.

Decision guidance

• Cloud agent or local agent mode: the cloud agent runs in a GitHub Actions environment with a firewall, a scoped token and mandatory human merge; local agent mode runs with the developer's full workstation credentials. For untrusted issues or unfamiliar code the cloud agent is the more contained option.
• Block or reference public code: blocking avoids licence questions but hides useful matches; allowing with references suits organisations whose open source review process can act on the logged licence names.
• Small teams: one organisation, enterprise policies left at defaults except MCP and the firewall, and branch protection on every repository may be enough. Large enterprises need enterprise-level enforcement, a private package mirror on the firewall allowlist and SIEM streaming.

Common misconfigurations

• Relying on content exclusion for secrets: excluded files still reach agent modes and the CLI. GitHub's own pages differ on CLI support, so test it, and remove secrets from repositories instead. See the Secrets Management Guide.
• Trusting text in issues and pull requests: Legit Security's CamoLeak research (CVSS 9.6) hid instructions in a pull request description that Copilot Chat read with the viewing user's permissions, and used GitHub's Camo image proxy to move private repository content out. GitHub fixed it on 14 August 2025 by disabling image rendering in Copilot Chat. The cloud agent now filters hidden text such as HTML comments, but Chat users still read untrusted content with their own access.
• Disabling the firewall to make a build work: GitHub warns this lets the agent connect to any host. Add the specific package domain or URL instead.
• Broad MCP tokens: swapping the read-only GitHub MCP token for an organisation-wide PAT so the agent can "see more", which turns any injected instruction into cross-repository access.
• Self-hosted runners with standing credentials: the agent runs without the firewall on a runner that also deploys to production.
• Ignoring personal plans: developers sign in to Copilot Free or Pro on corporate machines, outside every policy above, because network routing was never enforced.

Framework mapping

Practitioner checklist

• Enforce MCP, partner agent, preview feature and CLI policies at enterprise level.
• Set the public code matching policy deliberately and document the choice.
• Apply organisation-wide content exclusion for .env and secrets files, and test which surfaces honour it.
• Keep the agent firewall and recommended allowlist on; review every custom allowlist entry.
• Require branch protection, required checks and manual workflow approval on repositories where the cloud agent is enabled.
• Keep the default GitHub MCP token read-only and restrict each MCP server with a tools list.
• Use ephemeral runners for the agent, and never a runner that holds deployment credentials.
• Enforce subscription-based network routing and block individual Copilot endpoints.
• Stream the audit log to the SIEM and add your own collection for IDE and CLI prompts if required.

Standards and references

• GitHub Docs: Managing policies and features for GitHub Copilot in your organization
• GitHub Docs: Excluding content from GitHub Copilot
• GitHub Docs: Risks and mitigations for GitHub Copilot cloud agent
• GitHub Docs: Customizing or disabling the firewall for GitHub Copilot cloud agent
• GitHub Docs: Reviewing audit logs for GitHub Copilot
• GitHub Docs: Authenticating GitHub Copilot CLI
• OWASP: Top 10 for LLM Applications 2025
• Legit Security: CamoLeak, Critical GitHub Copilot Vulnerability Leaks Private Source Code

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · AI IDE and Coding Agent Security Guide · GitHub and GitHub Actions Security Guide · Vibe Coding Security Guide · MCP Security Guide