GitHub Copilot Enterprise and personal Copilot share a name and almost nothing else. Cursor is its own thing again. The Microsoft Copilot governance policy your firm needs is not the one GitHub's brochure suggests.
Most engineering leaders miss the same four things: code retention, training carve-outs, IP exposure on suggested code, and sub-processor visibility. Those are the ones that matter when a regulator or auditor looks at your tooling from an AI compliance standpoint.
This piece is the structured comparison for VP Engineering and CISO who need to write the policy. The tier landscape, the four governance considerations, and a policy template that recognises how engineers actually adopt these tools.
Side By Side
The engineering AI assistants cluster into a small number of architecturally distinct products that share marketing language. Distinguishing them is the first job.
GitHub Copilot personal. The individual subscription tier. Trained on public code; offers code completion in the IDE; the user's own code is sent to GitHub's infrastructure for context. The data handling is at the consumer-tier level, the firm has no contractual relationship with GitHub for the engineer's personal Copilot, regardless of the engineer's employer.
GitHub Copilot Business. The team-tier subscription with administrative controls, the explicit position that Business-plan inputs are not used for training, and SSO support. Offered through the firm's GitHub organisation. The data residency commitments and the contractual depth are improved over personal tier but the integration with broader Microsoft compliance commitments is shallower than Enterprise.
GitHub Copilot Enterprise. Integrated with the firm's GitHub Enterprise Cloud or GitHub Enterprise Server deployment. Code-aware suggestions that draw on the firm's own repositories rather than only public code. Includes the Microsoft 365 Copilot-style commercial commitments where the firm is also on Microsoft 365 commercial. The contractual depth is the deepest in the GitHub product line.
Cursor. A separate IDE built around AI-assisted code generation, with the underlying language models provided by Anthropic and OpenAI. Cursor sits architecturally between the user and the model providers; the firm's contractual relationship is with Cursor, and Cursor's contractual relationships with the model providers determine the data flow. Cursor offers tiered subscriptions with progressively stronger enterprise commitments. The model dependency is the substantive architectural difference: Cursor's behaviour and data handling are partly Cursor's and partly inherited from the upstream provider.
Tabnine, Codeium, Replit AI. Other AI coding assistants with their own architectures. Tabnine offers self-hosting in some tiers, the only major product in the category that does. Codeium has a free tier with consumer-style data handling and paid tiers with enterprise commitments. Replit AI is integrated with the Replit hosting platform and is best understood within that broader product context.
Four Governance Considerations
The four operational questions any credible AI governance policy needs to answer.
Code retention. What does the tool retain from the code the engineer sends it? The default position varies by tool and tier. For inference, the prompt typically includes the active file plus context; some tools retain the prompts for a defined period for abuse monitoring or product improvement. The firm's confidential code is the firm's intellectual property, the policy needs to specify what retention is acceptable.
Training carve-outs. Whether the tool uses the firm's code for vendor-side model training. The standard enterprise commitment is that customer code is not used for training; the standard consumer-tier position is variable. The policy should require contractual confirmation of the carve-out at the tier the firm is procuring.
IP exposure on suggested code. Where AI coding assistants generate suggestions, the question of whether those suggestions could reproduce copyrighted code from training data has been the subject of litigation in the US over the past two years. The litigation status changes; the operationally prudent position for European engineering organisations is to require attribution-free suggestion modes where available, to retain logs of the AI-generated portions of the codebase, and to ensure the firm's code review process is sufficient to catch suggestions that exhibit suspicious specificity.
Sub-processor visibility. For Cursor and other tools that wrap upstream model providers, the firm's actual data flow includes the tool plus the upstream provider. The DPA should reflect this layered relationship. The fourth-party visibility - knowing not only Cursor's sub-processors but also the model provider's, matters for DORA in-scope financial entities and for NIS2 supply-chain assessments, and is a core requirement of any serious AI compliance programme.
Copilot Enterprise solves half the problem, and the half it does not solve is Cursor. Most engineering teams that have procured Copilot Enterprise are using both. Copilot for the tasks it handles well: code completion, PR summaries, and documentation. Cursor for the tasks where it performs better: complex refactoring, multi-file context, and conversational code generation. Engineers know the difference, but the governance team often does not. The procurement record shows one tool, whereas the actual engineering environment contains two. The Copilot side has a DPA, a training carve-out, and SSO visibility. The Cursor side has a personal subscription, a consumer-tier data-handling position, and no entry in the ICT register. The engineers are not being careless; they are using the right tool for each task. The governance gap is that nobody in the firm mapped the full tools present. - Ankur Arora, CEO & Co-Founder, Montro |
A Policy Template For Engineering AI Tooling
The policy that holds in engineering culture has three components.
Sanctioned tools. The firm provides specific approved tools at specific tiers, provisioned through SSO. The list is short - typically Copilot Enterprise or Business, possibly Cursor at the appropriate tier, possibly a self-hosted option for the most sensitive code. Each sanctioned tool has a documented contractual position on the four considerations.
Acceptable use. Specific lines on what the engineer may and may not do with the sanctioned tool. The list is operational, not philosophical: do not use the AI assistant on code paths that handle authentication credentials, encryption key material, customer financial records, or special category data. Do not paste production secrets into the AI. Do not use the consumer tier of any AI tool for work-related code.
Discovery. The firm runs continuous discovery for unsanctioned engineering shadow AI tools. The pattern at most firms is that personal Copilot accounts and consumer Cursor subscriptions are present in the engineering organisation regardless of policy. The discovery layer surfaces them; the response is migration to sanctioned tooling, not punishment.
The AI governance policy that engineers respect is the one that recognises why they adopted the tool in the first place - speed, code quality, reduced friction. The sanctioned tools that win in engineering culture are the ones that match or exceed the consumer alternatives on those dimensions, with the additional benefit of being defensible under inspection.
Frequently Asked Questions
What is the difference between GitHub Copilot Business and Enterprise from a security standpoint?
The main difference is contractual depth. Business brings administrative controls, SSO, and a training carve-out - which personal tier does not offer. Enterprise adds integration with the firm's own GitHub repositories, code-aware suggestions drawn from the firm's codebase rather than public code only, and the Microsoft 365 commercial data commitments for firms already on that stack. For security teams documenting ICT third-party governance under DORA or NIS2 supply chain requirements, Enterprise sits within the broader Microsoft Copilot governance framework, which makes it easier to document.
Which Copilot tier is the minimum for work-related engineering use?
Business is the practical floor. Personal tier gives the firm no contractual relationship with GitHub for the engineer's use, the moment an engineer uses personal Copilot for work code, the firm has an uncontracted ICT service in its environment with no training carve-out and no administrative visibility. Business changes that. The choice between Business and Enterprise after that comes down to whether the firm needs repository-aware suggestions and the deeper Microsoft compliance commitments that come with Enterprise.
What does the AI coding IP litigation risk actually mean for a European engineering team?
The litigation is US-based and ongoing, the legal position continues to develop. For European teams the practical implication is not to wait for it to resolve. European intellectual property law does not map directly onto the US cases, so extrapolating from US outcomes would be a mistake. What engineering teams should do now, regardless of how the litigation develops, is require attribution-free suggestion modes where the tool offers them, retain logs of AI-generated code portions, and ensure code review catches suggestions with suspicious specificity. European firms with specific concerns should take legal advice under the applicable national and EU frameworks rather than following US litigation commentary.
