AI tool approval / GitHub Copilot

GitHub Copilot Business & Enterprise Security, Privacy and AI Tool Approval Checklist — 2026

Review GitHub Copilot for company use: repositories, privacy evidence, agent permissions, MCP, models and a practical approval checklist with decision conditions.

Official sources reviewed 11 September 2026. This is an independent document review; no tenant, runtime or network tests were performed.

Start with the exact Copilot workflow

Write down who will use which client, against which repositories, for which tasks. Reviewing code suggestions is a different approval scope from allowing an agent to execute commands or work asynchronously. Include the subscription and effective organization policies in the evidence record. Keep features outside the agreed scope disabled or otherwise restricted through verified controls.

September 2026 control: centrally managed agent permissions

GitHub announced centralized controls for shell operations, file access and network destinations on 9 September. The announcement covers the Copilot app, CLI and VS Code sessions using Agent Host. It says local user settings and saved approvals cannot weaken managed restrictions. Read the announcement.

The settings reference gives blocking rules priority over rules requiring approval, which in turn take priority over automatic permission. Managed approval rules require a new human decision each time. A default model setting does not prevent a user from selecting another model. Check the current settings reference.

Review action: record the policy source, client version and applicable team mapping. Test one blocked action, one action requiring approval and one permitted action with harmless examples. Repeat the approval-required action to confirm it prompts again. Treat the observed result as evidence for that configuration only; do not extend the conclusion to untested clients or workflows.

Privacy evidence is a separate decision

Restricting commands does not answer where code is processed or how long data is retained. Request feature-specific answers for code context, prompts, responses, telemetry and enabled integrations. Keep evidence for no-training commitments separate from retention, deletion and location commitments. This checklist does not assert a universal retention period or processing region for Copilot.

Partner agents and integrations need their own scope

GitHub documents third-party coding agents alongside its own cloud agent and requires their enablement through policies. Review third-party agent documentation. Record each selected agent and integration explicitly rather than using “Copilot approved” as a blanket permission.

Free GitHub Copilot approval checklist

For each item, record confirmed, pending or not applicable, with a reason, evidence link, verification date and owner.

1. Subscription and scope. Record Business or Enterprise, the organization, named users, client versions and each enabled feature. Separate editor assistance, local agents and cloud agents. A license is not authorization for every available workflow.
2. Repository access. Name approved repositories and their owners. Establish which branches, actions and data categories are permitted. Keep production credentials and customer records outside the pilot. Record how access will be revoked.
3. Privacy and contracts. Collect the applicable contract, DPA and subprocessor information. Ask how prompts, code, outputs and telemetry are processed for each selected feature and model. Record training commitments, retention exceptions, deletion procedures and processing locations separately.
4. Models. List models that users may select and who can change that list. Review a newly enabled provider before allowing confidential code. A preferred default model should not be treated as evidence that other models are blocked.
5. Shell, files and network. Define operations that must be blocked, require human approval or may proceed automatically. Test the effective policy with synthetic files and a normal member account in every client included in the approval.
6. MCP and plugins. Inventory server owners, permissions, tokens and destinations. Approve individual integrations and the data they receive. Test an unapproved server as well as an approved one; record the observed result and configuration.
7. Third-party agents. Document partner-agent enablement separately. Review their permissions and applicable data terms before including them. Do not assume a Copilot-only setting establishes equivalent restrictions for every agent.
8. Logs and incident handling. Identify which administrative changes and agent sessions can be reviewed in your deployment. Record access, retention, export and alert ownership. Check whether logging itself captures sensitive content and restrict access accordingly.
9. Generated changes. Require a human reviewer, ordinary repository protections and appropriate tests before merging. Keep deployment authority outside the pilot unless separately approved. Document how unsafe changes and exposed credentials are handled.
10. Decision and review date. Assign a business owner, security reviewer, evidence location and expiry. Record unresolved issues with deadlines. Reopen the decision when models, integrations, data categories or vendor terms change.

Worked example: a restricted pilot

Illustrative scenario, not a customer result: a five-person engineering team requests a two-week pilot on an internal demo repository containing synthetic data. The reviewer records the exact clients and policies, keeps external integrations outside scope and requires review before merging any generated change.

The evidence record includes policy screenshots and dated test outcomes from a regular member account. If a blocked operation succeeds or contractual questions remain open, the affected workflow stays pending. At the pilot end, the owner reviews incidents, useful output and unresolved questions before requesting expansion. A successful demo is not permission to add production repositories.

What the final approval record should contain

Record the organization, plan, users, clients, repositories, models and integrations, followed by allowed data, restrictions, evidence references, unresolved questions and the named sign-off authority. Add the decision date, expiry and triggers for re-review. Keep rejected and deferred requests in the register so that another team does not unknowingly repeat an unresolved request.

Related review guidance

• Cursor business approval checklist
• AI coding agent security and vendor review checklist
• AI vendor questionnaire guide

Official sources and review history

• September 9: enterprise-managed agent permissions — reviewed 11 September 2026.
• Enterprise-managed settings reference — reviewed 11 September 2026.
• Third-party coding agents — reviewed 11 September 2026.

First published 11 September 2026. Recheck the official sources before sign-off; product controls and terms can change.

Independent guidance from Operating Templates. Not affiliated with or endorsed by GitHub. These documents do not certify security or legal compliance.