Copilot Business Data-Handling Review With a Rogue Individual Account
Contoso Defense has 250 developers on GitHub Enterprise Cloud and Copilot Business. Legal is completing a vendor security review and sends three questions: (1) are prompts and suggestions used to train GitHub's models, (2) how long are prompts and suggestions retained, and (3) can Contoso audit individual Copilot usage without collecting source code. The security team captured outbound TLS traffic from developer laptops and saw connections to Copilot endpoints, plus GitHub.com. They also found that a developer had enabled a personal Copilot Individual account on the same laptop, which bypasses the enterprise policy. The platform team already uses content exclusions for two repositories and has SSO with SCIM. Legal wants answers that cite contractual commitments, not marketing pages, and wants to know what evidence Contoso can produce from its own enterprise. The review is due in five days.
1. Draft the answer to Legal's three questions, separating what GitHub documents publicly, what requires the contract, and what Contoso must verify itself.
Read the worked answer
Separate public documentation, contract, and local verification.
Training use. For Copilot Business and Copilot Enterprise, GitHub states that customer code, prompts, and suggestions are not used to train the models. That is different from Copilot Individual, where a user may opt in to product-improvement data use. Because a personal Individual account was found on a managed laptop, Legal must treat that account as out of policy: its terms and controls are not the enterprise terms.
Retention. Public docs and the Copilot Trust Center describe retention categories and purposes (service operation, abuse detection, telemetry, billing). Exact retention periods, subprocessors, and deletion commitments should be taken from the GitHub Data Protection Agreement or the signed contract, not from a marketing page. If the contract is silent on a period Legal requires, that is a gap to negotiate, not something to assert.
Audit. Enterprise audit logs can show seat assignment, SSO/SCIM events, policy and content-exclusion changes, and Copilot enablement. The Copilot metrics API provides aggregated usage and engagement, not prompt text. Contoso cannot produce individual prompt content from GitHub, and should not try; it can produce configuration and usage evidence.
State clearly what is verified by contract versus what is a public statement that may change.
2. What evidence can you produce from the enterprise to show usage and policy enforcement without collecting prompt content?
Read the worked answer
Produce configuration and usage evidence, not source content.
- Identity and access: SSO configuration, SCIM group-to-seat mapping, list of assigned seats, and the join date of each seat. This answers 'who could use Copilot'.
- Policy state: exported content-exclusion settings, repository patterns, and the timestamp of the last change. Pair each with an audit-log event so you can show change control.
- Usage: Copilot metrics API data at organization level: active users, acceptance rate, chat requests, and breakdown by IDE or language where available. Aggregate only; do not build per-developer scorecards without a stated purpose and legal review.
- Incident evidence: the personal-account detection, device-management record, and the remediation ticket. That is more persuasive than a statement that 'users were told not to'.
- Network: document the approved Copilot endpoints and proxy configuration; explain that TLS inspection of Copilot traffic is not a source-code audit mechanism and may break the service.
A good evidence pack has a one-page control matrix: question, control, evidence artifact, owner, and date. Legal can then see which answers are contractual and which are operational.
3. A developer asks if they can opt out of telemetry while keeping Copilot. What do you tell them, and what policy levers actually exist?
Read the worked answer
Treat the personal Individual account as a data-handling exception, not a licensing nuisance.
The Individual plan's data-use terms and retention may differ from Business/Enterprise, and the organization's content exclusions, audit logs, and seat controls do not apply. A developer could send proprietary code through an account the company cannot govern. That is the core issue; the extra license cost is secondary.
Actions:
- Remove or block the personal account on managed devices and require enterprise authentication for Copilot.
- Use MDM or extension allowlisting to prevent unapproved Copilot extensions and personal sign-ins.
- Check audit logs and network logs for use during the review period; if proprietary code was sent, follow the incident process rather than assuming no harm.
- Tell developers why: enterprise Copilot has different terms, exclusions, and auditability.
- If developers need Copilot on personal projects, keep that off managed devices and out of the enterprise network.
Do not simply say 'opt out of telemetry.' User-level telemetry opt-outs do not convert a personal account into an enterprise-controlled data flow, and they may not exist for every signal. The control is identity and device policy.