Set the rules before AI coding agents become the default

AI coding tools are moving beyond suggestions inside an editor.

They can now review changes, work on repository tasks, use connected tools and carry context between sessions. That can remove useful repetition for a small development team. It also changes the business decision.

The question is no longer only whether the tool writes good code.

The question is what it can access, what it retains, which actions it may take and where a person must still be responsible.

What GitHub announced, and when

On August 28, 2026, GitHub announced upcoming changes to Copilot policies and billing for Copilot Business and Enterprise.

No earlier than September 28, GitHub plans to combine Copilot Chat on GitHub.com, Copilot Chat in GitHub Mobile and Copilot cloud agent under one policy. GitHub says that unified experience will be enabled by default after launch. It also says GitHub.com chat data will move from 28-day retention to retention for the life of the account.

This is a confirmed upcoming change, not a completed rollout. As of September 3, GitHub's current cloud agent access documentation still says Copilot Business and Enterprise administrators must enable cloud agent before members can use it. Administrators should check the effective setting when the unified policy arrives rather than assuming the current documentation describes the future default.

The same August announcement included two cost changes. From October 1, existing Business and Enterprise customers paying by credit card or PayPal will be charged upfront for assigned seats at the start of the billing cycle. Removing a seat will not create a prorated refund. GitHub says plan prices are not changing. Its current plan documentation lists Copilot Business at US$19 per granted seat each month, with additional AI usage controlled through credits and budgets.

Why this is a business decision

A coding conversation can contain more than source code.

It may include client requirements, system architecture, error logs, security assumptions, configuration details or a description of a commercial process. A cloud agent may also have access to repository issues, pull requests and any approved tools or services connected to its work.

GitHub says it does not use Copilot Business or Enterprise data to train its models. That is an important distinction. It does not make retention, access or internal visibility irrelevant.

Longer retention changes the amount of information held over time. A broader default policy changes who may start an agent session. Connected tools can expand what an agent can read or do. Each choice may be reasonable, but it should be deliberate.

This matters most for:

• agencies working across several client codebases;
• businesses that own customer portals, ecommerce systems or operational software;
• teams handling personal, financial, health or commercially sensitive information;
• repositories connected to deployment, support, analytics or internal systems;
• small teams where one GitHub administrator quietly owns every policy decision.

A brochure website with no sensitive workflow may need a light policy. A repository that supports payments, customer accounts or an important internal tool needs more care.

Approval is becoming a separate choice

On September 1, GitHub also announced that Copilot code review can approve pull requests.

The approval feature is in public preview and is off by default. If administrators enable it, a Copilot approval can count towards a repository's required approval rule. Controls can be set at enterprise, organisation and repository level, with file path limits available at repository level.

An approval assessment can be useful as another signal. It should not become the only release decision for consequential code.

Generated code and generated review can share blind spots. Tests can miss a business rule. A technically valid change can still expose the wrong data, weaken an accessibility path or create a maintenance burden the reviewer does not understand.

Human review should remain responsible for the business consequence, not merely the syntax.

Set the rules before choosing the workflow

A practical governance review does not need to become a large policy project.

Start with a short inventory:

• Which repositories can use cloud agents?
• Which people can start or steer a session?
• What information must not appear in prompts, issues or logs?
• Which files or paths contain sensitive business logic or client material?
• Which external tools, Model Context Protocol (MCP) servers, packages and secrets are available?
• Can the agent write only to a branch, or can connected tools change another system?
• Which checks and human approvals must pass before merge or deployment?
• Who reviews retained sessions, access, spend and exceptions?

GitHub's own cloud agent risk guidance identifies unvalidated code, access to sensitive information, prompt injection and loss of administrative visibility as risks. Its MCP documentation also notes that configured tools may be used autonomously during a task.

That makes least privilege the useful starting point.

Allow only the repositories, paths, tools and secrets needed for the chosen workflow. Treat content exclusion as an additional control, not a replacement for repository permissions, secret management and careful task design. GitHub made content exclusions generally available for the Copilot app and CLI for Business and Enterprise customers on September 2, 2026.

Start with one bounded workflow

Do not begin with company-wide access and hope useful behaviour emerges.

Choose one stable, repetitive development task. Good candidates might include drafting tests for an understood component, preparing routine documentation updates or proposing a small change in a low-risk repository.

Then use a measured sequence:

1. Record the current cycle time, review effort, rework and failure rate.
2. Give the agent access only to the repository and context the task needs.
3. Define a bounded role, such as preparing a draft pull request rather than making a release decision.
4. Keep a qualified person responsible for review, approval and deployment.
5. Compare the result with the baseline, including time spent correcting the output.
6. Improve the instructions and controls before expanding access.

The point of the pilot is not to prove that the agent can produce code.

It is to learn whether the complete workflow becomes faster, safer or easier to maintain.

Risks that still need an owner

Privacy and confidentiality

The announced lifetime retention applies to the future unified GitHub.com experience. GitHub's current agent session documentation says cloud agent sessions can be archived but not deleted. The final controls for the unified experience should be verified when it launches.

Businesses should decide whether retained prompts, responses and file context fit client agreements, privacy obligations and internal information policies. Where the answer needs legal interpretation, obtain appropriate advice before enabling the workflow.

Security and access

An agent with repository access can still be influenced by poor instructions, unsafe dependencies or untrusted content. External tools and broader tokens increase the possible impact of a mistake. Keep secrets out of prompts, limit credentials, review connected tools and preserve branch protection.

Accuracy and reliability

An AI review is not evidence that the change is correct. Require the same tests, accessibility checks, security review and domain judgement that the repository would need from a human contribution.

Cost

Seat cost is only one part of the decision. Review effort, cloud agent sessions and additional usage can consume AI credits. GitHub is also changing the default review effort from Lite to Balanced on September 28 for repositories left on Default. Measure total workflow cost, set budgets and remove unused seats before the next billing cycle.

Maintenance and vendor dependence

Policies, session history, repository instructions and connected tools can become part of how a team delivers software. Keep important standards in portable documentation and tests so the workflow does not depend on one vendor's current interface or policy model.

What to review before September 28

For a team already using Copilot Business or Enterprise, the practical next step is an explicit settings review.

Confirm whether the future unified experience should be enabled. Review repository access, content exclusions, MCP tools, agent secrets, session visibility, code review effort, approval settings, budgets and seat ownership. Record the reason for each consequential choice.

If the team is not using cloud agents, there is no need to introduce them because a platform default changed. Keep the current workflow if it is clear, reliable and proportionate to the work.

If the team does want to test an agent, start with one bounded workflow and one accountable human reviewer.

The next decision

AI coding agents can be useful for agencies and growing businesses with software to maintain. The value comes from reducing repeated delivery work while keeping technical direction clear.

That is the same principle behind good Custom Internal Tools and good technical architecture: the system should make responsible work easier, not make responsibility disappear.

For teams that need to review Copilot policies, repository boundaries and a sensible pilot together, a Fractional Technical Partner can help turn a changing vendor setting into a clear technical decision.