GitHub Copilot agents can do more than suggest code. Depending on the environment and permissions, they can inspect repository files, modify code, run commands, access external services, and create pull requests.
This makes them useful for development tasks, but it also creates an important security question: how much access should an AI agent have?
For example, a coding agent may need to read source files and install NuGet packages to fix a .NET issue. It probably does not need access to every repository in the organization, production credentials, or unrestricted internet access.
GitHub provides several controls to manage these permissions. Repository administrators and organization owners can decide which repositories can use Copilot agents, configure external tool access, manage secrets, and restrict internet connections.
This article explains how these controls work and how to configure them for a repository without giving an agent unnecessary permissions.
Understand the Different Types of Access
Before changing settings, understand that Copilot access is not controlled by one permission.
There are several separate access areas:
Access area | What it controls |
|---|
Repository access | Which repository the agent can work with |
GitHub permissions | What the agent can read or modify |
Secrets and variables | Which credentials and configuration values are available |
MCP servers | Which external tools and services the agent can use |
Internet access | Which external hosts the agent can connect to |
Development environment | Which commands and dependencies are available |
These controls work together, but changing one does not automatically change the others.
For example, allowing an agent to connect to an external package registry does not give it permission to read every private repository in the organization.
Similarly, configuring an MCP server can give the agent access to external tools even when its normal GitHub token is restricted to the current repository.
It is important to review each access path separately.
Control Which Repositories Can Use Copilot Agents
Organizations do not always want every repository to use AI agents.
A public sample project may be suitable for autonomous code changes, while a repository containing sensitive business logic or regulated data may require additional approval.
Organization owners can control which repositories have access to Copilot in the cloud.
Start by opening the organization settings:
Open GitHub and navigate to your organization.
Select Settings.
Open the Copilot settings.
Review the policies that control Copilot in the cloud.
Choose the repositories that are allowed to use the feature.
The available options depend on the organization's Copilot plan and administrative policies.
A practical approach is to begin with a small group of development repositories. Once the team has reviewed the agent's behavior, permissions, and pull request quality, access can be expanded.
For repositories that should never use the cloud agent, block access at the organization level rather than relying only on individual developers to avoid assigning tasks to it.
Understand the Default GitHub Permissions
Copilot cloud agent uses a specially scoped GitHub token by default.
The built-in GitHub MCP server connects with read-only access to the current repository. This allows the agent to inspect repository information without automatically receiving access to other private repositories.
When the agent is assigned a coding task, it can work on the targeted repository and create changes through its supported workflow.
The cloud agent also operates with constrained write access. It pushes changes to a dedicated branch rather than directly modifying the default branch.
For example, a task assigned through an issue can result in a branch such as:
copilot/fix-order-validation
The agent can then open a pull request for review.
This separation is important because generating a code change and approving that change are different responsibilities.
Do not assume that the agent has the same permissions as the repository administrator. Its access depends on the token, environment, and policies configured for the session.
Manage Secrets and Variables Separately
Some development tasks require authentication.
For example, an agent may need to download a private package, connect to a monitoring service, or access an internal development tool.
Storing credentials directly in source code is unsafe. Instead, GitHub provides Agents secrets and variables that can be configured at the repository or organization level.
These are separate from the secrets used by GitHub Actions, Codespaces, and Dependabot.
To configure them:
Open the repository on GitHub.
Select Settings.
Open Secrets and variables.
Select Agents.
Add the required secret or variable.
Configure its visibility and access scope.
For example, an organization might store an authentication token for an internal monitoring service:
Secret name:
COPILOT_MCP_SENTRY_ACCESS_TOKEN
Value:
Your monitoring service access token
The actual token should be entered through GitHub's secret management interface, not committed to a repository file.
There is an important environment distinction:
Agents secrets with the COPILOT_MCP_ prefix are available to MCP server configurations, including cloud sandbox sessions.
Other Agents secrets are available only when the agent runs in a GitHub Actions environment.
Do not assume that a secret available to a GitHub Actions workflow is automatically available to Copilot.
Also, Copilot does not receive the repository's ordinary Actions secrets simply because it can run commands in a repository. Only the specifically configured Agents secrets and variables are provided to the agent.
For private GitHub Packages, prefer granting the repository's GITHUB_TOKEN the required package access instead of creating a long-lived personal access token with broad organization permissions.
Restrict External Tools With MCP Configuration
Model Context Protocol (MCP) allows Copilot to communicate with external tools and services.
For example, a development team might connect Copilot to Sentry so that it can inspect error reports while fixing an application issue.
However, an MCP server can expose multiple tools. Some may only read information, while others can create records, update settings, or perform destructive operations.
This makes tool selection an important security decision.
Configure an MCP server
Repository administrators can configure MCP servers from:
Repository Settings
└── Code, planning, and automation
└── Copilot
└── MCP servers
The configuration uses JSON.
A simplified example looks like this:
{
"mcpServers": {
"sentry": {
"type": "local",
"command": "npx",
"args": [
"@sentry/mcp-server@latest"
],
"env": {
"SENTRY_ACCESS_TOKEN": "$COPILOT_MCP_SENTRY_ACCESS_TOKEN"
},
"tools": [
"list_issues",
"get_issue"
]
}
}
}
The tool names in this example are illustrative. Replace them with the exact tool names exposed by the MCP server you install.
The configuration starts a local MCP server and passes the authentication token through an environment variable.
The tools array controls which tools are available to Copilot.
For a monitoring integration, allowing tools that list and inspect issues is a safer starting point than enabling every available operation.
Why tool allowlisting matters
An important detail in GitHub's MCP configuration is that Copilot can use configured MCP tools autonomously without requesting approval before each call.
Therefore, configuring an MCP server does not mean the agent will ask permission every time it uses one of its tools.
For this reason, GitHub recommends allowing specific read-only tools where possible.
Avoid using:
"tools": ["*"]
unless the use case genuinely requires every tool exposed by the server and the associated risks have been reviewed.
Also, repository-level MCP configuration is shared with Copilot cloud agent and Copilot code review. If an MCP server should be available to the cloud agent but not to code review, use the separate code review setting to disable MCP tool usage there.
Control Internet Access With the Copilot Firewall
An agent may need internet access to install dependencies, download packages, or connect to approved services.
Unrestricted internet access creates a risk. Malicious instructions or unexpected agent behavior could cause sensitive source code or data to be sent to an external destination.
GitHub provides a firewall for Copilot cloud agent and Copilot code review.
The firewall restricts outbound connections and uses a recommended allowlist by default. This allowlist includes common package registries, operating-system repositories, container registries, and other hosts needed for development.
Configure repository-level firewall settings
Open the repository and navigate to:
Repository Settings
└── Code, planning, and automation
└── Copilot
└── Internet access
Depending on the organization policy, repository administrators can configure:
Whether the firewall is enabled.
Whether the recommended allowlist is enabled.
Which additional domains are allowed.
Whether repository-level custom rules are permitted.
For example, suppose a project uses an internal package registry:
packages.contoso.corp
An administrator can add this domain to the custom allowlist so that the agent can download the required packages.
You can also restrict access to a particular URL path:
https://packages.contoso.corp/project-1/
A path-specific rule is more restrictive than allowing the entire domain.
Do not disable the firewall unnecessarily
Disabling the firewall allows the agent to connect to any host.
This increases the possibility of source code or sensitive information being sent to an unauthorized destination.
Keep the firewall enabled unless there is a documented requirement that cannot be addressed through an allowlist.
There are also limitations to understand. The firewall applies to processes started through the agent's Bash tool inside its execution environment. It does not directly cover MCP server processes or configured setup steps. It should therefore be treated as one security control, not a complete data-loss prevention system.
Protect the Agent's Setup Workflow
Copilot cloud agent can use a copilot-setup-steps.yml workflow to prepare its development environment.
For example, a .NET repository may need a particular SDK and additional dependencies before the agent can build and test the application.
A setup workflow can install those dependencies:
name: "Copilot Setup Steps"
on:
workflow_dispatch:
jobs:
copilot-setup-steps:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v6
- name: Set up .NET
uses: actions/setup-dotnet@v5
with:
dotnet-version: "10.0.x"
- name: Restore dependencies
run: dotnet restore
This example demonstrates a basic setup. Use action versions approved by your organization and adjust the workflow to match the repository's actual build requirements.
The setup file is particularly important from a security perspective because it executes before the agent starts working.
A developer with write access may be able to modify this configuration. An unauthorized change could introduce unexpected commands or access to additional resources.
Protect the file with branch rules, rulesets, and CODEOWNERS.
For example, add the following entry to a CODEOWNERS file:
/.github/workflows/copilot-setup-steps.yml @your-org/platform-security
Replace the team name with the actual team responsible for reviewing development-environment changes.
CODEOWNERS alone does not enforce approval. Configure the relevant branch protection or repository ruleset to require code-owner review before merging changes to protected branches.
Apply Organization-Level Governance
Managing every repository separately becomes difficult when an organization has hundreds of projects.
Organization owners can establish shared policies for MCP servers, internet access, secrets, and repository administration.
A practical governance model includes:
Area | Recommended control |
|---|
Repository access | Enable agents only for approved repositories |
Secrets | Use repository or organization Agents secrets with limited scope |
MCP servers | Maintain an approved list of integrations |
MCP tools | Allow only the required operations |
Internet access | Keep the firewall enabled and use a narrow allowlist |
Setup workflows | Protect changes with CODEOWNERS and rulesets |
Administration | Limit configuration rights to trusted maintainers |
Enterprise administrators can also use managed settings to define approved MCP servers and plugin standards.
For custom agents, organization-level profiles can provide consistent instructions and integrations across repositories.
The goal is to make secure configuration the default rather than expecting every developer to understand and configure all security settings independently.
Test the Access Configuration
After configuring permissions, verify what the agent can and cannot access.
Use a test repository and assign a small task.
For example:
Inspect the order validation service.
Read the existing implementation and
identify possible validation problems.
Do not modify files.
Do not access external services unless
they are required for this review.
List the files and tools you used.
Check whether the agent can access the expected repository files and whether its external integrations behave according to the configured permissions.
Then test a task that requires dependency installation. Confirm that the firewall allows approved package sources and blocks destinations that are not on the allowlist.
Also verify that:
The agent cannot access unrelated private repositories through its default repository-scoped token.
Only the intended Agents secrets are available.
MCP tools are limited to the configured list.
Setup workflow changes require the expected review.
The agent creates changes through the intended branch and pull request process.
Do not test security by giving the agent production credentials or unrestricted access to sensitive systems.
Common Mistakes to Avoid
Using broad personal access tokens
A long-lived personal access token with organization-wide permissions can give an agent more access than it needs. Prefer the built-in scoped token, fine-grained credentials, or a GitHub App with limited permissions.
Enabling every MCP tool
MCP tools may perform write operations. Allow only the tools required for the task, especially when the agent can invoke them autonomously.
Assuming Actions secrets are available to Copilot
GitHub Actions secrets and Copilot Agents secrets are separate. Configure the required credentials in the correct location.
Disabling the firewall to fix dependency problems
First identify the blocked host and add a narrow allowlist entry. Disabling the firewall removes an important layer of protection.
Leaving setup files unprotected
Changes to copilot-setup-steps.yml can affect the commands executed before an agent session. Protect this file with ownership and required reviews.
Treating the firewall as complete protection
The firewall has scope limitations and does not cover every process or integration. Combine it with limited credentials, MCP tool restrictions, repository policies, and code review.
Summary
GitHub provides several ways to control what Copilot agents can access in a repository. These include repository-level access policies, scoped GitHub permissions, Agents secrets, MCP tool configuration, internet access restrictions, and protected setup workflows.
The most important principle is to give an agent only the access required for its task. A code-fixing agent may need source files, build tools, and package access, but it does not automatically need organization-wide repository permissions or production credentials.
Start with approved repositories, keep the firewall enabled, use narrowly scoped secrets, and allow only necessary MCP tools. Protect configuration files with CODEOWNERS and branch rules, then test the complete setup before using agents on sensitive projects.
These controls allow development teams to use Copilot agents while keeping repository access, external integrations, and security responsibilities under administrative control.
Join the conversation! Your thoughts help the community grow.