9 min read - Copilot content exclusions: test coverage before rollout

GitHub announced on 2 September 2026 that the Copilot app and CLI now respect administrator-defined content exclusions. The release covers Copilot Business and Enterprise customers and extends file-context restrictions to those clients. For a team that has held back terminal-based coding assistance because of sensitive repository content, this is a reason to revisit a pilot.

The decision still needs a workflow-level answer. A developer may move between an editor, a terminal session and a pull request without changing accounts. An approval that says only "Copilot is allowed" leaves the team guessing which of those activities the security review covered.

We recommend evaluating each client and mode against the files it should be able to use. Record the excluded paths, test the actual workflow with synthetic content, and assign another reviewer to any code the assistant must skip. The method below is our proposed acceptance exercise; it is not a report of tests run against GitHub or a claim about an Exceev customer deployment.

Read the release at the client level

GitHub's content-exclusion documentation still lists unsupported editor Edit and Agent modes, symlinks and remote filesystems. It also warns that IDE-provided semantic information can convey details from excluded files. Copilot code review skips excluded files.

Those limits make the client and mode part of the approval. If an engineer has permission to use one tested workflow, don't infer permission for another workflow from the shared product name. Write down what the developer opens, how the repository reaches that environment, and which assistant action starts the work.

For example, a policy decision could allow assistance on a local checkout through a tested client, while leaving a remote development setup pending. That is a proposed decision format, not a statement that every local workflow is covered. It gives the engineer a concrete instruction and gives the reviewer a scope they can reproduce.

Keep a dated copy of the relevant documentation beside that decision. Product coverage can change; an old screenshot of an enabled setting is weak evidence for a newly adopted mode.

Start with the files and the account

Suppose a small software team keeps an ordinary application, a restricted pricing module and customer debugging exports in the same working directory. This is a fictional example. The application needs coding help, the pricing module has a different disclosure rule, and the exports should stay outside the assistant's working environment altogether.

List those distinctions before writing exclusion patterns. For each class, record the reason for the restriction and the person who can approve a change. Avoid a broad pattern chosen only because its name sounds sensitive. A folder called internal might contain both public API types and confidential commercial rules; the team needs to decide which content belongs where.

GitHub's configuration guide distinguishes enterprise-wide rules from organization rules that follow seats assigned by that organization. Verify the test user's seat source as well as the repository. The same guide documents repository path lists such as this illustrative configuration:

- '/restricted-pricing/**'
- '/customer-debug-exports/**'

These names are examples, not a complete policy. Have a repository administrator enter the applicable rules in the documented settings and check inherited rules before testing. A policy file sitting in a repository does not establish that an administrator configured those settings.

For a team working across France and Morocco, keep one shared record of the approved accounts and workflows. Geography alone doesn't answer which files a tool may receive. Avoid translating an office location into an assumption about data processing or contractual permission.

Build a harmless coverage test

Use a disposable repository that resembles the intended layout. Put a random, harmless marker in an allowed file and a different marker in an excluded file. Generate the markers for the test and keep them out of the prompts. A unique marker makes a retrieved detail easier to distinguish from a plausible guess.

Start with a positive control: ask the assistant for a fact available only in the allowed file. If it cannot answer, fix the environment before interpreting silence on the excluded file. A disconnected client can look reassuringly restrictive.

Then ask an equivalent question whose answer exists only in the excluded file. Record the response and any available references or tool trace. The absence of the marker in an answer does not prove that no content reached a service; treat it as one observation alongside documented coverage and available diagnostic evidence. Don't paste real restricted content to make a test more convincing.

Use a table to preserve the conditions of each result. These are proposed test cases, not measured outcomes or a GitHub certification procedure.

Repeat the relevant cases after a directory move or a client upgrade that changes the workflow. Keep the fixture small enough that an engineer can explain every file in it. A large, realistic repository with unclear dependencies makes an unexpected answer harder to investigate.

Budget for the code review gap

The exclusion decision has a delivery consequence. If a team restricts its pricing module, someone still has to review changes there and changes that depend on it. Put that work into the release plan when approving the restriction.

Consider a hypothetical checkout change that updates rounding in the ordinary application while an excluded module owns the discount calculation. A reviewer needs to check the relationship between both pieces. A clean assistant review on the visible code should not close that question.

Ask the human reviewer to examine the excluded diff and the integration tests that exercise its public behaviour. Use synthetic examples at the boundary when the assistant can work on tests without receiving the restricted implementation. If even the interface is confidential, keep that testing workflow inside the approved environment as well.

Track review coverage separately from review findings. "No issues found" describes a result within the reviewed scope; it does not tell a release manager which files received scrutiny. A short note listing the excluded paths and their reviewer prevents that ambiguity without copying confidential code into the pull request discussion.

Our broader coding-assistant build-versus-buy guide helps frame procurement. This exclusion decision belongs in the narrower operational record for the chosen tool and repository.

Check tool permissions separately

OWASP's guidance on excessive agency recommends minimal tool permissions and authorization in downstream systems. That independent guidance supports a separate access review; it is not evidence that a particular Copilot release fails to enforce its exclusions.

For the pilot, inventory connected tools and the identities they use. If a connector can query a document store, decide which records that identity needs. If a shell runs under a developer account, review what that environment can reach. Do not assume that a file-context setting answers those questions.

Where your requirement is that the assistant process must have no access to a dataset, design the environment around that requirement. A restricted checkout and narrowly scoped credentials are options to assess. Test the selected arrangement under the actual account; writing "do not read" in a prompt is not evidence of an enforced permission.

Make the rollout decision reproducible

At the end of the exercise, keep a short record with the policy revision, client and mode, test identity, fixture revision and observed results. Include the open questions. Give each unresolved workflow a named owner rather than folding it into a broad approval.

GitHub documents the copilot.content_exclusion_changed audit action for repository and organization changes, including the saved exclusion paths. Link the relevant configuration evidence to the test record. It establishes what administrators changed; it does not prove what happened during every assistant interaction.

Set the acceptance condition before seeing the results. For example, approve the tested workflow only when ordinary assistance works, the exclusion behaviour matches the documented scope, and a reviewer owns the omitted code. If an observation contradicts the expected restriction, stop that workflow and investigate with the synthetic fixture. Preserve the last accepted configuration so the team can restore it without reconstructing the rules from memory.

The useful output is a permission an engineer can follow: this account may use this client and mode on this repository layout, with these excluded paths and this review arrangement. Expand it when new evidence supports a specific change.

Sources and limitations

We opened and reviewed all sources below on 3 September 2026.

• GitHub's 2 September release establishes the current app and CLI announcement and eligible plans.
• GitHub's coverage and limitations define the product boundaries used here.
• GitHub's configuration guide supports the account-scope distinction and path-list example.
• GitHub's audit guide documents evidence of policy changes.
• OWASP LLM06:2025 supplies established guidance on tool permissions, independently of GitHub.

GitHub is the primary source for its product behaviour. OWASP does not corroborate the release or certify its implementation. We have not tested these Copilot clients, measured leakage rates or assessed a customer's contractual requirements. The examples and acceptance exercise are proposed engineering analysis. Confirm the documentation and your installed clients before applying them.