The challenge
- Sensitive code. Source code must never leave the organization, and personal GitHub accounts must never reach it.
- Teams that want AI. Blocking it outright stalls development; opening it up puts the organization at risk.
- The whole picture, not just the IDE. Securing the developer environment isn’t enough. Identity, network, endpoints, cloud and regulation all have to fit together, so the organization looked for combined expertise — a VP of R&D and a cloud security architect — to run the project end to end.
- Developers and security speak different languages. Infrastructure and security teams don’t live in IDEs, repositories and AI assistants, and developers don’t always see why every block is needed. Someone had to bridge the two.
- Regulation. Every cloud service at a financial organization has to meet identity, access, encryption and network requirements.
- Manually managed developer machines. No central control over versions, extensions or accounts.
What we did together
OnCloud’s VP of R&D and cloud security architect worked with the organization’s development, infrastructure and security teams. We turned developer needs into security requirements, and security requirements into settings that don’t slow development down.
1GitHub as a licensing layer for Copilot only
We blocked repository creation, forking, visibility changes, GitHub Pages, Actions, Projects and outside collaboration, restricted Personal Access Tokens, and enforced branch rulesets and minimal base permissions.
The benefit: Developers get an AI assistant; the code stays in the organization’s repositories, and Copilot doesn’t use it for training.
2Identities owned by the organization
Managed accounts only, provisioned automatically from Entra ID (SCIM), with verified domains. Sign-in with a personal GitHub account is blocked.
The benefit: Leavers lose access automatically, and there are no accounts nobody manages.
3Access and admins
Conditional Access with MFA, access only from approved networks, and high-risk sign-ins blocked. For admins: phishing-resistant MFA, compliant devices, and roles through PIM, only for as long as needed.
The benefit: A leaked password isn’t enough to get in, and no admin holds standing rights an attacker could use.
4Copilot inside the limits we set
Approved models only. We turned off web search, MCP servers, the coding agent, Code Review and Spaces.
The benefit: The assistant helps write code, but doesn’t connect to tools or data sources the organization hasn’t approved.
5A centrally managed developer environment
Up-to-date VS Code with settings managed through Intune: which extensions are allowed, and Copilot only with the work account.
The benefit: No developer installs an unapproved extension or signs in with a personal account.
6Network and DLP
Copilot reaches only approved endpoints, through the corporate proxy with SSL inspection, and DLP inspects the traffic before it leaves.
The benefit: DLP blocks passwords, API keys and sensitive data before they leave inside a question to the assistant.
7Tested for real
We ran a penetration test with real attack scenarios: pushing code out, pulling from an outside repository, installing an extension, signing in without MFA, and starting an MCP server.
The benefit: The settings didn’t stay on paper. We saw them stop real attempts.
What changed
Want to give your developers AI without exposing your code? Start with a technical intro meeting.
Book a meeting