GitHub Copilot Policy Changes Before September 28

The GitHub Copilot policy changes announced on August 28 affect more than an administrator toggle. Starting no earlier than September 28, 2026, GitHub plans to merge three Copilot experiences under one policy, retain web chat data for the life of the account, and make Balanced the effective default for code reviews left on Default. Existing Business and Enterprise customers paying by credit card or PayPal also face an upfront seat-billing change from October 1.

This guide turns those announcements into an audit plan. It separates confirmed product behavior from recommendations, identifies inherited settings that can change without a repository edit, and gives engineering, security, and finance owners a common checklist.

Table of contents#

• What GitHub Copilot policy changes on September 28
• Why the unified Copilot policy changes the trust boundary
• How does lifetime chat retention affect governance
• What changes when Balanced becomes the code-review default
• How do repository overrides interact with organization defaults
• What changes for Copilot Business and Enterprise billing
• Audit GitHub Copilot policy changes before rollout
• How should teams monitor the rollout
• Frequently asked questions
• Conclusion

What GitHub Copilot policy changes on September 28#

GitHub announced three separate changes, with different dates and scopes. Treating them as one generic “Copilot update” hides the decisions administrators actually need to make.

Change	Earliest effective date	Default behavior	Primary owner
Unified Copilot experience and policy	September 28, 2026	Enabled after launch	Copilot administrator and security
Web/mobile chat moves to agent sessions	September 28, 2026	Chat retained for account lifetime	Privacy, legal, and security
Code-review Default resolves to Balanced	September 28, 2026	Deeper, higher-cost review	Repository and organization admins
Upfront charge for assigned Business/Enterprise seats	October 1, 2026 for existing eligible customers	All assigned seats charged at cycle start	Billing and license operations

The dates are not equally firm. GitHub says the unified experience will launch no earlier than September 28, while the billing update for existing Business and Enterprise customers paying by credit card or PayPal starts October 1. Build the audit around those dates, but recheck the official GitHub announcement before changing production policy.

The unified experience combines Copilot Chat on github.com, Copilot Chat in GitHub Mobile, and Copilot cloud agent. Separate policies for those surfaces will be replaced by one policy. Opting out will therefore remove web and mobile Copilot access as well as agent access after launch; it will no longer be possible to preserve web chat through the old separate toggle.

That is the first non-obvious consequence: policy convergence removes a selective control. An organization that previously allowed low-risk chat but blocked autonomous cloud work must choose a new posture rather than assume the old combination survives.

Why the unified Copilot policy changes the trust boundary#

A chat assistant answers inside a conversation. A cloud agent can create a session, inspect repository context, execute work in a sandbox, and produce durable GitHub artifacts. Combining those surfaces under one policy means the permission decision now governs a wider capability set.

GitHub says the relaunched web experience will use agent sessions and that cloud agent will use Sandbox for a faster cloud experience. The sandbox is an execution boundary, not a substitute for repository authorization or pull-request protection. Teams should still control which repositories are eligible, what credentials are exposed to the environment, and what branch rules guard the output.

This is the same distinction covered in the site's guide to VS Code agent sandboxing: isolation limits where commands run, while permissions determine what the session may reach. A permissive token inside a well-isolated machine remains permissive.

Before enabling the unified policy, answer four questions:

1. Which users need Copilot on github.com or mobile but should not start cloud work?
2. Which repositories contain regulated, export-controlled, or unusually sensitive code?
3. Which sandbox secrets or network destinations could an agent reach?
4. Which branch protections guarantee that agent output receives human review?

If the first question identifies a real user group, the unified toggle may be too coarse. The safer response is not to weaken repository controls. Keep policy access narrow, then use repository eligibility, least-privilege credentials, rulesets, and required reviews as downstream gates.

For collaboration surfaces, the same principle applies to the GitHub Copilot Slack integration: a convenient starting surface does not reduce the authority of the identity or app that executes the task.

How does lifetime chat retention affect governance#

The web experience previously retained Copilot Chat data for 28 days. After migration to agent sessions, GitHub says chat data will be retained for the life of the account, matching the existing cloud-agent experience. That is a material data-governance change even when the policy's enabled state does not change.

Longer retention increases the time in which prompts, pasted snippets, repository references, and generated answers remain associated with an account. It can improve continuity and auditability, but it also expands the consequence of putting secrets, customer records, incident data, or privileged legal material into a chat.

Do not reduce this to a training-data question. Retention, model training, access control, deletion, legal hold, and export are separate controls. A product may refrain from training on content while still retaining it for product operation. Your review should explicitly cover each control rather than accepting a single “enterprise data protected” statement as a complete answer.

The minimum policy update should define:

• prohibited prompt content, including secrets and production personal data;
• approved ways to reference incidents, tickets, and customer cases;
• account offboarding and deletion responsibilities;
• who can retrieve session artifacts during an investigation;
• whether the new retention period changes a data-processing assessment or customer commitment.

Avoid copying entire incident threads into Copilot to gain context. Provide a sanitized problem statement and stable internal identifiers only when the agent has an approved path to retrieve the underlying record. This reduces accidental replication across chat, issue, branch, pull request, and logs.

What changes when Balanced becomes the code-review default#

GitHub Copilot code review supports Lite and Balanced effort levels. Lite is a targeted review for common bugs, security issues, and style inconsistencies. Balanced routes the pull request through a higher-reasoning model for longer analysis of complex logic, security-sensitive changes, and cross-service work.

On September 28, the value Default will resolve to Balanced instead of Lite for existing and new organizations and repositories. An explicit Lite or Balanced selection will be preserved. The risky setting is not Lite; it is an inherited or ambiguous Default whose meaning changes under it.

According to GitHub's current code-review documentation, a Lite review typically consumes an estimated $0.05 to $1 in AI credits, while Balanced is estimated at $0.25 to $5. These are ranges, not fixed prices. Pull-request size and repository instructions affect consumption, the estimates can change as models evolve, and GitHub Actions minutes are additional.

Dimension	Lite	Balanced
Intended work	Routine and straightforward changes	Complex, security-sensitive, or cross-service changes
Analysis	Fast and targeted	Longer, higher-reasoning review
Estimated AI-credit value per review	$0.05–$1	$0.25–$5
Actions usage	Agentic capabilities consume minutes	May consume marginally more minutes
Best default	High-volume, low-risk repositories	Repositories where missed defects cost more than review latency

Balanced is not automatically “better.” A blanket switch can spend more on generated files, documentation-only changes, dependency lockfiles, or repositories already covered by strong deterministic checks. Conversely, forcing Lite everywhere can be false economy for authentication, payment, infrastructure, or cross-service changes.

A practical policy uses repository risk as the default and manual selection for exceptions. Keep CI, CodeQL, linters, tests, ownership rules, and human review as enforcement. AI review is advisory; it should not become the only merge gate. The site's guide to safe agentic code-review workflows explains how to preserve that separation.

How do repository overrides interact with organization defaults#

GitHub applies the organization review-effort default to repositories that have not selected their own level. A repository override wins for automatic reviews. For manually requested reviews, a user can select the effort level from the Reviewers area without changing the stored organization or repository default.

That hierarchy creates three states worth inventorying:

• Explicit repository level: stable until a repository administrator changes it.
• Inherited organization level: changes when the organization default changes.
• Default: changes meaning on September 28 unless set explicitly.

Start with a repository inventory before opening settings screens. This executable command lists active repositories and visibility; it does not claim to read Copilot policy state, which GitHub's documented settings workflow exposes in the UI.

#!/usr/bin/env bash
set -euo pipefail

: "${ORG:?Set ORG to your GitHub organization login}"

gh repo list "$ORG" \
  --limit 1000 \
  --json nameWithOwner,visibility,isArchived \
  | jq -r '
      ["repository","visibility","risk_tier","current_effort","owner"],
      (.[]
       | select(.isArchived == false)
       | [.nameWithOwner, .visibility, "UNCLASSIFIED", "VERIFY_IN_UI", "UNASSIGNED"])
      | @csv
    ' > copilot-review-audit.csv

printf 'Created %s
' "copilot-review-audit.csv"

Review copilot-review-audit.csv with code owners and security. Classify each repository before deciding the effort level; public versus private is not a sufficient risk model. A private payroll service may require Balanced, while a public documentation repository may not.

What changes for Copilot Business and Enterprise billing#

GitHub is reopening new Copilot Business and Enterprise sign-ups paid by credit card or PayPal starting September 1, with stronger account vetting and updated payment behavior. New seat assignments require payment before users receive access.

For existing eligible customers, all assigned seats will incur an upfront charge at the start of the billing cycle beginning October 1. Revoking a seat does not create a prorated refund; the removal affects the next monthly cycle. Seats added mid-cycle remain prorated from assignment through the end of that cycle.

Base Business and Enterprise prices are not changing in this announcement. That does not mean the invoice cannot change. Seat timing, included usage, AI-credit overages, code-review effort, and Actions minutes remain independent cost drivers.

The operational response is simple:

1. Remove abandoned and duplicate assignments before the billing-cycle boundary.
2. Map every assigned seat to an active owner and cost center.
3. Confirm budgets for additional AI-credit usage.
4. Compare review volume and effort level after the default changes.
5. Reconcile seat charges separately from usage charges.

For the underlying token-based cost model, see GitHub Copilot AI Credits explained. Do not estimate the September impact from seat count alone.

Audit GitHub Copilot policy changes before rollout#

Run the audit in this order so inherited settings do not hide behind repository-by-repository exceptions.

1. Record the current policy state#

Capture the current web/mobile Chat, cloud-agent, sandbox, code-review, model, and paid-usage policies. Record whether each value is explicit, inherited, or default. Screenshots alone are weak evidence; add the owner, decision date, reason, and next review date.

2. Decide whether unified access is acceptable#

Test the new combined capability against user roles and repository classes. If chat-only access was part of the old design, document that the selective state is going away and choose a compensating repository control.

3. Update the retention assessment#

Replace the old 28-day assumption for github.com chat with account-lifetime retention after migration. Review prompt-handling guidance, offboarding, investigations, deletion, and contractual statements.

4. Make review effort explicit#

Choose Lite, Balanced, or a repository-specific mix. Do not leave a critical repository on Default merely because today it behaves like Lite. The point is to own the decision before the default changes.

5. Reconcile seats and budgets#

Remove unused seats before the applicable billing cycle, verify cost-center ownership, and confirm what happens when included AI credits or a budget is exhausted. Preserve a break-glass process for legitimate bursts without granting unlimited overage by habit.

6. Publish the decision record#

Send developers a short change notice that states capability, retention, review, and cost effects separately. Include where to report an access problem and how to request a higher review effort for a sensitive pull request.

How should teams monitor the rollout#

Measure behavior after the policy changes, not just whether the settings page saved successfully. A clean rollout can still create silent cost or access drift.

Track these signals for at least the first full billing cycle:

• active users versus assigned seats;
• agent sessions by repository and team;
• AI-credit consumption and blocked requests;
• code-review count split by Lite and Balanced;
• Actions minutes associated with agentic review;
• review latency, accepted findings, incorrect findings, and human overrides;
• access-denied events and support requests;
• sensitive-data incidents connected to prompts or session artifacts.

Use ratios carefully. More Copilot comments do not prove better review, and fewer comments do not prove failure. Sample resolved findings against defect severity and false-positive rate. GitHub now lets reviewers mark Copilot comments as addressed, won't fix, or incorrect; those outcomes are more useful than raw comment volume when teams apply them consistently.

Set two checkpoints: one shortly after the earliest September 28 rollout date to verify capability and retention behavior, and another after the October billing cycle to reconcile predicted versus actual spend. If GitHub delays the launch, preserve the audit work and move the checkpoint rather than assuming the change was cancelled.

Frequently asked questions#

When do the GitHub Copilot policy changes take effect?#

GitHub says the unified web, mobile, and cloud-agent experience will launch no earlier than September 28, 2026. The code-review Default also switches from Lite to Balanced on September 28. Upfront billing for all assigned Business and Enterprise seats begins October 1 for existing customers covered by the announcement.

Will opting out of cloud agent still allow Copilot Chat on github.com?#

Not after the unified experience launches. GitHub says opting out of the unified policy will remove access to Copilot on github.com and GitHub Mobile as well as the cloud-agent experience. Administrators who previously allowed chat but blocked agents need a new control strategy.

Does GitHub Copilot retain web chats permanently after the change?#

GitHub says web chat data will be retained for the life of the account after github.com moves to agent sessions, replacing the previous 28-day period. Organizations should separately verify deletion, legal-hold, access, and training controls because retention duration does not answer those questions.

Will every Copilot code review become Balanced?#

No. The change affects repositories and organizations whose review effort remains Default. Explicit Lite and Balanced choices are preserved, repository settings override the organization default for automatic reviews, and manually requested reviews can select an effort for that run.

Does Balanced code review cost more than Lite?#

Yes. GitHub estimates Lite at $0.05–$1 in AI-credit value per review and Balanced at $0.25–$5, excluding Actions minutes. Actual consumption varies with pull-request size, instructions, and model behavior, so administrators should monitor their own review mix after rollout.

Conclusion#

The dangerous assumption is that an unchanged toggle means unchanged behavior. On September 28, Copilot's access boundary, retention period, and code-review default can all change underneath inherited settings; October then changes when eligible seat costs are charged. Make access, retention, review effort, and budget decisions explicit now, and verify them again after rollout.