Model choice can affect cost, latency, data-governance posture, and the behavior of AI-assisted development. GitHub Copilot targeted model rules give enterprise owners a way to allow selected models for selected organizations. For QA teams, the important question is not whether a rule appears in an admin screen. It is whether the intended people can use the intended models—and everyone else is consistently blocked.

This tutorial turns GitHub Copilot model access rules testing into a repeatable policy-enforcement exercise. You will build a small organization-by-model matrix, execute positive and negative tests across relevant Copilot surfaces, capture audit evidence, and prove that rollback works. The workflow is designed for QA engineers, SDETs, automation testers, and platform teams evaluating the public-preview feature safely.

What GitHub officially documents

GitHub’s official announcement says targeted model rules let enterprise owners allow specific Copilot models for selected organizations. The feature is in public preview for Copilot Business and Copilot Enterprise. The administration guide also describes enterprise-wide availability: Enabled makes a model available to all organizations, while Optional lets organizations decide whether to enable it.

Two details shape the test plan. First, GitHub’s policy-conflict reference documents how availability can be resolved when a user receives Copilot through multiple organizations. Second, the supported-surfaces reference warns that not every policy applies to every Copilot surface. Treat those documents as requirements, then verify the behavior in your own tenant rather than assuming the configuration screen is proof.

Build a safe test environment

Use a non-production enterprise or tightly controlled pilot. Create synthetic repositories with no customer data, secrets, or proprietary prompts. Use test identities rather than personal administrator accounts. Keep one enterprise owner available to change policy and a separate tester to validate the user experience.

Create three organizations and four test users:

  • qa-core: intended to receive Model A and Model B.
  • qa-regulated: intended to receive only Model A.
  • qa-sandbox: intended to receive Model B and Model C.
  • Users: one member per organization plus one user who belongs to both qa-core and qa-regulated.

Do not use model names as permanent assertions because available models can change. Record the model labels visible in your enterprise at execution time, the rule configuration, the test date, and the authenticated Copilot surface.

Create the model access test matrix

Test identity Organization context Expected allowed Expected blocked
core-user qa-core Model A, Model B Model C
regulated-user qa-regulated Model A Model B, Model C
sandbox-user qa-sandbox Model B, Model C Model A
overlap-user qa-core + qa-regulated Per documented conflict rule Everything outside the resolved set

Add rows for an enterprise-assigned user, an organization-assigned user, a newly added member, and a removed member if those identity paths exist in your deployment. The matrix prevents a common testing mistake: checking only that an allowed model appears while never proving that an unauthorized model is absent or rejected.

Step 1: Capture the baseline

Before creating a targeted rule, sign in as each tester and capture the visible model selector. Start a harmless prompt such as asking for unit-test ideas for a tiny synthetic function. Record whether the request succeeds, which model is shown, the client surface, time, organization providing the seat, and any policy message.

Save screenshots only after redacting account names and enterprise identifiers. The baseline is essential because a model may already be enabled by an enterprise default or another organization. Without it, a later success can be misattributed to the new rule.

Step 2: Configure one narrow rule

In enterprise AI controls, choose the Copilot model configuration area and create a targeted rule for qa-core. Allow only the two models selected for the test. Keep the first change deliberately narrow. Record the rule name, target organization, allowed set, administrator, timestamp, and a screenshot of the saved configuration.

GitHub labels targeted model rules as public preview, so make rollback part of the change ticket. Preview behavior and interfaces can change, and your evidence should identify the date on which it was collected.

Step 3: Test allowed and blocked paths

Refresh the client or reauthenticate according to your normal support procedure, then execute the matrix. For each expected-allowed model, verify both selector visibility and a successful benign request. For each expected-blocked model, verify it is absent or that the request is rejected with a clear policy outcome.

A disabled selector alone is not sufficient. Attempt the equivalent path through every supported surface in scope, such as GitHub.com, an approved IDE, or Copilot CLI. If a surface is not covered by the policy, document it as out of scope or as a governance gap rather than reporting a false failure.

Step 4: Exercise conflict and propagation cases

The overlap-user is the most valuable test. Confirm which organization supplies the Copilot license, compare the effective result with GitHub’s documented conflict behavior, and capture the evidence. Then change the user’s membership or license source and repeat.

Also test propagation without relying on a fixed delay:

  1. Record the policy-change timestamp.
  2. Poll at controlled intervals with a capped timeout.
  3. Log when the selector and request behavior change.
  4. Fail the test if the cap is reached, preserving evidence for support.

This approach measures actual propagation and avoids hiding an enforcement defect behind an arbitrary wait.

Step 5: Verify auditability and rollback

Use the enterprise audit log or approved governance record to verify who changed the model rule and when. Correlate that event with your matrix execution. Redact tokens, emails, prompts, and repository details before sharing evidence.

Rollback by removing the targeted rule or restoring the documented previous configuration. Repeat at least one previously allowed and one previously blocked case. A successful rollback means the effective user behavior returns to baseline—not merely that the admin page shows the old value.

Automate the repeatable checks

Automation can maintain the matrix, authenticate through approved test accounts, inspect exposed selectors, make harmless requests, and compare outcomes with expected policy. Keep configuration changes under administrator control. Store evidence as timestamped JSON plus redacted screenshots, and fail loudly when a model label, surface, or policy response changes.

Use soft assertions to collect the full matrix in one run, but make the final build fail on any unauthorized success. An allowed model becoming unavailable may be an operational defect; a blocked model becoming usable is a governance defect and should receive higher severity.

Release gate for QA

  • Every allowed path succeeds on each supported surface in scope.
  • Every blocked path is absent or rejected consistently.
  • Overlapping membership matches the documented conflict behavior.
  • Propagation time stays within the agreed operational limit.
  • Audit evidence identifies authorized policy changes.
  • No production code, secrets, or personal data entered the pilot.
  • Rollback restores the verified baseline.
  • Enterprise security and platform owners approve broader rollout.

Targeted rules improve control, but they do not prove enforcement by themselves. A compact identity-by-model matrix gives QA teams durable evidence that the configured policy is the policy users actually experience.