Copilot firewall: check the process before expanding internet access

A blocked dependency is a diagnosis, not permission to open a domain

Before widening internet access for a Copilot cloud-agent task, identify which process attempted the download. GitHub's current documentation says the agent firewall applies to processes started by the agent via its Bash tool, but not directly to configured Copilot setup-step processes or Model Context Protocol (MCP) server processes. An enabled firewall therefore does not establish coverage for every network operation associated with the task. [2]

The organization-level controls are older context: GitHub announced them on 3 April 2026. The announcement described organization-wide firewall and recommended-allowlist settings, custom entries, and control over repository additions, with repository choice preserved by default. This briefing uses that historical announcement alongside documentation checked on 7 October; it does not report a new October launch. [1][2]

Separate Bash, setup steps and MCP server processes

MCP use is not a blanket exemption: the documentation explicitly keeps other agent-process requests subject to the firewall while an MCP server is in use. Conversely, changing the agent allowlist is not an established repair for a download made by an excluded setup-step or MCP server process. Trace that failure before changing this control. [2]

At both organization and repository levels, Copilot's Internet access page has separate sections for cloud agent and code review. Inspect the cloud-agent section for this decision. Separate configuration does not prove that code review shares the process coverage in the table; the cited limitations describe the agent firewall. [2]

A narrower new rule may leave a broader inherited grant intact

GitHub says organization custom entries apply to all repositories, cannot be deleted at repository level, and combine with repository rules. If the organization already permits a whole domain, adding a project-specific URL in a repository does not narrow that inherited permission. Inspect the organization entries as well as the proposed addition. [2]

The organization can also prevent repository custom rules and lock firewall or recommended-allowlist settings. Repository administrators can change the latter settings only when the organization selects Let repositories decide, and can add custom rules only when Allow repository custom rules is Enabled. A repository-only plan may therefore need an organization owner's decision. [2]

A custom entry is not the entire allowed-traffic policy. The documentation says hosts used for GitHub interaction are always allowed, and a recommended dependency allowlist is enabled by default. Include those settings and inherited entries in the review rather than treating one narrow custom rule as proof of a narrow effective boundary. [2]

How to assess a dependency-access request

GitHub documents a blocked-request warning in a new pull request's body or a comment on an existing pull request. It includes the blocked address and the command that attempted the request. Those details are a useful starting point, not a warning we observed in an account. The following is our proposed decision procedure. [2]

• Identify the command and its execution path. If the failure belongs to setup steps, an MCP server process or another environment, investigate that path's applicable controls instead of assuming this firewall caused it. [2]
• Establish why the dependency needs the destination and which scheme, host and path are required. Keep any additional destination requirements unresolved until there is evidence for them.
• Inspect Copilot → Internet access in organization and repository Settings, using the cloud-agent section. Check the firewall, recommended allowlist, custom-rule permission and all inherited custom entries. [2]
• If a custom entry is justified, propose the smallest documented destination scope that meets the requirement. A path-specific URL is narrower than a domain entry under GitHub's matching rules, but it cannot revoke an applicable broader grant. [2]
• Have the responsible owner assess the effective configuration and confirm the dependency outcome in an authorized workflow. Keep configuration, expected behavior and observed behavior separate; pause the dependent task if a mandatory boundary remains unresolved.

Hypothetical decision: a project registry path, not the whole domain

Assume a team's agent-started Bash command needs files only under https://packages.contoso.corp/project-1/ and receives a firewall warning for that destination. The host, task and warning are illustrative assumptions; no command, download or settings change was performed for this example.

After confirming the command's process and required endpoint, the team proposes https://packages.contoso.corp/project-1/ rather than packages.contoso.corp. Under the documented matching rules, the URL confines this entry to the HTTPS host and project path subtree; the domain also permits subdomains. The proposed decision is to request the project URL, subject to the effective configuration and any evidenced additional dependency destinations. This is not a guarantee that one URL suffices for every installation. [2]

Now assume the organization already allows packages.contoso.corp. The repository URL does not remove that inherited domain grant. If the task requires a project-only boundary, the completed decision is to pause reliance on that boundary and ask the organization owner to review the broader entry. Recording the new URL alone as least privilege would misstate the combined rules. [2]

If the failed download instead came from configured setup steps or an MCP server process, the team would not treat the agent allowlist as the established fix. It would identify the relevant environment or tool controls and the actual failure first. The same destination can require a different diagnosis when a different process makes the request. [2]

What the documentation cannot establish

GitHub warns that sophisticated attacks may bypass the firewall and says it should not be considered a comprehensive security solution. The April announcement's protection rationale is not a guarantee against prompt injection or data exfiltration. Neither an enabled setting nor a successful dependency download would establish universal protection. [1][2]

Both sources belong to GitHub's own evidence chain. They establish the documented controls and limitations, not independent effectiveness, account availability or enforcement in your repository. The Docs publication and update dates were not established, so their October 7 observation does not date a product change. No administrator configuration, network experiment or customer outcome was checked for this briefing.

The bounded recommendation is to attribute the request, inspect inherited permissions, and justify the destination before expanding access. If the required process coverage or effective boundary cannot be established, keep that part of the task paused while its owner resolves the gap; do not disable the agent firewall as a catch-all dependency fix.