Decide what an approval means before delegating more work to Copilot

GitHub announced general availability on 26 October 2026 for Copilot CLI, the Copilot app and VS Code. Eligible command, path and URL requests can receive model-assisted approval; enterprise administrators can restrict Assisted and Allow All separately. Check the actual client and policy before assuming your team has the same configuration. (GitHub)

Separate three decisions

The first decision belongs to the person commissioning the work: what outcome is authorised? “Prepare a reviewable patch” and “publish a release” are different instructions, even when both involve the same repository. Write down the outcome and the actions that need a further decision before the session starts.

The second decision is how the agent’s permission requests are handled. The third is what its credentials, file access and execution environment actually permit. A useful operating arrangement considers all three. A narrower prompt does not, on its own, narrow a credential; a broad credential does not, on its own, authorise the agent to use every capability.

An enterprise ask rule can still be satisfied by a model

Eligible enterprise ask rules may be satisfied by model approval; deny rules still apply. Already-allowed requests can bypass review, while unattended requests still needing approval are denied. The review can err; unavailable review does not remove existing broad access. Client and host coverage varies, including cloud sessions. Model review does not replace isolation or access restrictions. (GitHub)

This matters when a team uses a prompt as its evidence of control. If a process requires a named person to approve a release, define how that approval is recorded and enforced. Do not infer it from the absence of a prompt, or from a policy label whose detailed behaviour nobody has checked.

Use the same distinction when reviewing a completed session. “The request proceeded” is an observation. “A human approved it”, “the model reviewed it” and “an existing permission already allowed it” are different explanations. The session evidence should support the explanation you record.

Plan the unavailable-review path

Include an unavailable-review case in the proposed operating procedure. Decide what evidence the operator needs to establish the session’s effective mode, which work must stop and who can resolve the uncertainty. A warning should lead to that decision process, rather than disappear into an unattended log.

For a proposed unattended job, specify an acceptable stopping condition before enabling it. If the job depends on assisted review, the operator needs evidence that the intended mode was available and active. A job should not be described as model-reviewed merely because the command requested that mode.

• Record the client, execution host, permission mode and relevant administrator policy for the actual run.
• Inspect warnings and the effective access rather than relying only on a launch setting.
• Define who reviews unexpected file changes or service actions before the next run.
• Choose a recovery procedure for partial work; a stopped session may already have changed local state.

Start with one reviewable task

For example, a team could propose a pilot that updates a small documentation section in an isolated copy of a repository. Before running it, the team would list the intended files, expected output and operations that must remain outside scope. Afterwards, it would inspect the diff and session evidence. This is a hypothetical pilot design; no Copilot test was performed for this article.

Keep the first task small enough that a reviewer can explain every change. Expand the scope only after the team understands both the successful path and the stopping path. Counting fewer approval prompts alone would miss whether an action remained within the task and whether the resulting work was acceptable.

What to settle before adoption

The reviewed announcement and documentation do not establish an incremental price or minimum client version for every account. Confirm subscription eligibility, current client support and relevant charging terms for your organisation. General availability does not establish Swiss data residency, a security certification or suitability for every client environment.

For agency work, agree who may approve actions and releases in the client’s environment as part of the technical delivery responsibilities. That agreement should name a decision-maker and evidence, rather than treat a permission mode as a substitute for the project’s authority.