For years, most conversations about governing AI-assisted development started with the editor.
Which extensions can developers install? Can Copilot access private repositories? What code may be included in a prompt? Who reviews the generated changes?
Those questions still matter, but the boundary has changed. A Copilot session can begin on GitHub, continue from a phone, move into a local client, and later be resumed from the command line or an IDE. The conversation, context, and work can follow the developer instead of remaining tied to one device.
That continuity is genuinely useful. It also means an organization cannot treat Copilot governance as an editor setting anymore.
The Session Is Becoming the Governance Boundary
When an AI session lived inside one editor, it was tempting to think of the editor as the control point. You could manage the extension, configure repository access, and establish local approval expectations.
A persistent session changes that model. The same task may be started from the GitHub website, steered from GitHub Mobile, resumed in Copilot CLI, and reviewed later from another client. Cloud sessions can keep running even after the developer closes a laptop.
The device is no longer a reliable boundary. The session is.
That does not make the experience unsafe by default. It means the organization must decide which controls should remain consistent as the session moves:
- Which identity is acting?
- Which repositories and organizations may the session access?
- Which tools can it invoke?
- Which external systems can it reach?
- What context is stored, and for how long?
- Who is accountable for reviewing and accepting the result?
Convenience Can Hide a Change in Authority
Moving a session from a desktop to a phone may feel like changing screens. From a governance perspective, the more important question is whether the developer is also changing how they supervise the work.
Reviewing a plan from a phone is different from reviewing a detailed permission request involving a terminal command, a third-party MCP server, or access to an external host. A developer who would carefully inspect that request at a desk may approve it more quickly while between meetings.
The risk is not the phone itself. The risk is assuming that the same person and the same session automatically produce the same level of oversight in every context.
Session continuity should preserve governance context, not merely development context.
Teams should define which actions are appropriate to approve remotely and which require a deliberate return to a trusted development environment. Reading progress and redirecting a plan may be acceptable from almost anywhere. Approving unrestricted tool use or access to a sensitive system deserves a higher bar.
Start With Identity and Repository Scope
The first control is still identity. A session should be connected to the correct managed GitHub identity, with single sign-on enforced where appropriate. Personal accounts and organizational work should not blur together simply because the interface makes switching easy.
Repository access also needs to be intentional. GitHub documents that cloud sessions may work across multiple repositories within an organization. That can be valuable for coordinated changes, but it also expands the potential effect of an incomplete prompt or overly broad task.
I would establish a clear default:
- Begin with the smallest repository scope needed for the task.
- Require an explicit reason before crossing repository boundaries.
- Keep sensitive repositories excluded unless there is a reviewed use case.
- Use branch protection and pull-request review as independent controls.
An agent being authorized to propose a change should not mean it is authorized to merge or deploy that change.
Tool Permissions Need an Organizational Position
Copilot supports different levels of tool approval. At one end, a developer approves each tool invocation. At the other, tools can run without individual approval. Assisted modes can reduce routine prompts while still escalating requests considered risky.
That flexibility is useful, but leaving every developer to make an isolated choice is not a governance strategy.
Organizations should decide where each mode is appropriate. A learning repository or disposable sandbox may tolerate broader autonomy. A repository that handles authentication, regulated data, production infrastructure, billing, or deployment workflows should use more restrictive defaults.
| Decision area | Question to answer | Safer default |
|---|---|---|
| Tool approval | Can the agent run commands without asking? | Assisted or manual approval for sensitive work |
| Repository scope | Can one session modify multiple repositories? | Limit scope to the task |
| MCP servers | Which external tools and data sources are trusted? | Use an approved allowlist |
| Network access | Which external hosts may the agent contact? | Allow only required destinations |
| Merge authority | Can agent-created changes bypass human review? | Preserve normal branch protections |
| Production access | Can the session reach production systems or secrets? | Keep production outside the agent boundary |
MCP and Network Access Deserve Separate Attention
MCP servers make an agent far more capable because they connect it to tools and information outside the immediate repository. That same capability makes them an important trust boundary.
An MCP server may expose documentation, issue tracking, databases, monitoring systems, or internal business data. Read-only access can still reveal information that should not become part of a coding session. Write access can create a much larger operational risk.
Do not evaluate an MCP server only by whether it is useful. Evaluate:
- Who operates it and how it authenticates users
- What data and actions it exposes
- Whether access is read-only or can change external state
- What information may be retained in session history
- Whether use is logged and attributable to a person
- How access is revoked when responsibilities change
The same principle applies to general network access. A cloud sandbox should not be able to reach every external destination merely because the developer's workstation could.
Persistent Context Creates a Records Question
Session history is valuable. It can explain why a change was made, show which tools were used, and help reviewers understand how the agent arrived at its result. GitHub also links agent-created commits back to session logs, improving traceability.
However, retained prompts and context may include architecture details, error messages, filenames, customer terminology, or other sensitive information. Organizations need to understand what session data is stored, which policies control synchronization, who can see it, and how that fits existing retention and legal requirements.
Do not tell developers simply to avoid sensitive prompts and consider the problem solved. Provide concrete examples of prohibited data, approved alternatives, and an escalation path when the agent genuinely needs more context.
Human Review Still Owns the Outcome
A continuous session can make the transition from idea to proposed change feel seamless. The pull request must still be treated as software produced by the team.
The reviewer should validate the architecture, authorization boundaries, data handling, tests, failure behavior, observability, and operational impact. Session logs can provide useful evidence, but they do not replace review of the resulting code.
This is especially important when a developer steers the session several times. Each correction may be reasonable by itself while the final collection of changes drifts beyond the original scope.
The durable rule is simple: the person who accepts the change owns the decision to ship it.
A Practical Governance Checklist
Before enabling persistent, cross-surface Copilot sessions broadly, I would ask a team to document these decisions:
- Identity: Which managed accounts, SSO requirements, and roles apply?
- Scope: Which organizations and repositories may sessions access?
- Surfaces: Are web, mobile, CLI, app, and IDE access all permitted?
- Permissions: Which tool-approval modes are allowed for each risk level?
- Connections: Which MCP servers, connectors, and external hosts are approved?
- Data: What information may be included in prompts and retained context?
- Review: Which branch protections, reviewers, and tests remain mandatory?
- Traceability: Where are session logs, commits, approvals, and exceptions reviewed?
- Cost: Who monitors sandbox compute and AI-credit usage?
- Incident response: How is a session stopped, access revoked, and unintended work investigated?
These decisions do not need to become a fifty-page policy. They do need to be explicit, enforceable where possible, and understandable to developers.
Govern the Work, Not Just the Interface
Cross-surface Copilot sessions remove friction. A developer can start a task, walk away from a desk, monitor progress, answer a question, and resume later without rebuilding the context. I expect teams will find real value in that workflow.
But every reduction in friction also removes a natural pause. Good governance puts the important pauses back in the right places: expanding repository scope, granting a tool permission, connecting an external system, accepting a change, or moving toward production.
If the session follows the developer everywhere, identity, permissions, data rules, review expectations, and accountability must follow it too.
How is your team governing AI work that moves beyond the IDE? I would be interested to hear which controls have been easy to implement and which remain difficult in practice.