We recently worked with a large Israeli financial organization that wanted to give its developers GitHub Copilot. Its code stays in its existing source control, and GitHub Enterprise is used only to license and govern Copilot. We've already published the full customer story. This post collects the actual settings, layer by layer, so you can check them in your own environment.
Why turning on Copilot and trusting the defaults isn't enough
Copilot Business and Copilot Enterprise are managed through a GitHub Enterprise account, and that account comes with the whole platform: repository creation, forks, GitHub Pages and Actions. Copilot itself also does more than code completion: web search, agents, MCP servers and Spaces. Each of these is one more way for code or data to leave the organization. If all you need is a coding assistant, everything you don't use should be off.
1. GitHub Enterprise: keep only what you need
- Enterprise repository policy: restrict repository creation, visibility changes and transfers across all organizations, with an empty allow list. Field tip: leave deletion unrestricted, so a repository created by mistake can be removed quickly.
- Enterprise branch ruleset: a second layer. Even if a repository gets created, nobody can create or update branches or force-push.
- Base permission set to "No permission", and forks, deploy keys and GitHub Pages disabled.
- Outside collaborators can be added by enterprise owners only.
- Actions, Projects and hosted compute networking off, if you don't use them.
- Fine-grained personal access tokens restricted. If you need them: an approval flow and a short expiry.
2. Copilot itself: models and features
- Approved models only: disable every model, then enable only those that passed your security, privacy and compliance review.
- Default to off: in the policies for enterprise-assigned users, set the default to Disabled. Otherwise features set to "Let organizations decide" can end up on without anyone deciding.
- Web search and MCP servers off: both open a path for code context to reach an outside source.
- Coding agent, code review, Spaces and generated commit messages off when not needed.
- Where Copilot runs: only in the IDE and the CLI. Off on GitHub.com, in GitHub Desktop and in GitHub Mobile.
3. Identity: organization accounts only
- Enterprise Managed Users with SCIM from Entra ID: accounts are created, updated and disabled from Entra ID. A leaver loses access with no manual step in GitHub.
- Conditional Access on the GitHub app: MFA for everyone, access only from approved networks, and high-risk sign-ins blocked (needs Entra ID P2).
- Admins: phishing-resistant MFA, a compliant device, and the Enterprise Owner role through PIM, only for as long as needed (needs Entra ID P2).
4. The IDE: settings developers can't override
GitHub settings don't help if a developer signs in to the IDE with a personal account, or installs an extension that works around them. So:
- VS Code managed through Intune or GPO: an approved-extensions list, with
ChatMCP,ChatAgentExtensionTools,ChatToolsAutoApproveandChatToolsTerminalEnableAutoApprovedisabled. - Visual Studio: the Copilot administrative templates block activation with a personal GitHub account.
- Supported, up-to-date versions only: older versions don't enforce some of the policies.
5. Network and DLP: the layer most people forget
No GitHub setting knows what a developer pastes into a prompt. An API key, a password or a piece of a config file can leave inside an ordinary question.
- Endpoint allow list: allow only the endpoints GitHub publishes for Copilot, and block the rest of GitHub's services.
- Corporate proxy with SSL inspection: set the proxy in the IDE and install the corporate certificate on every workstation.
- DLP on the decrypted traffic: blocks secrets and sensitive data before they leave.
6. Monitoring: know when something changes
Settings drift. Send GitHub audit logs (including the repo, copilot, personal_access_token and enterprise categories) and Entra ID sign-in logs to your SIEM, such as Microsoft Sentinel. Also watch changes to the groups that grant GitHub access and to the Enterprise Owner group. Any activity by the break-glass account should trigger a review.
Finally, training: even with everything locked down, developers need to know how to check what Copilot suggests, and not to paste anything into a prompt they wouldn't email outside the company. We do all of this in our Copilot security service, as part of our Microsoft 365 security projects.
Does GitHub use our code to train models?
According to GitHub, with Copilot Business and Copilot Enterprise your code and prompts aren't used to train the models.
Can we use Copilot without hosting code on GitHub?
Yes. That's the setup in this project: GitHub Enterprise handles licensing and governance, and the code stays in the existing source control.
Which Microsoft licences do we need?
Entra ID P1 for Conditional Access, Entra ID P2 for risk-based blocking and PIM, and Intune to manage the IDE.
Want to give developers Copilot without opening up the organization? We'll go through the settings with you.
Talk to us