Does GitHub Copilot send my code to train OpenAI or Anthropic's models?

For Copilot Business and Enterprise plans, GitHub's Copilot Trust Center states that prompts and code suggestions are not used to train the underlying models or retained for that purpose. Individual Copilot Free and Pro plans have historically had different defaults, so organizations should confirm which plan and settings apply to their seats rather than assuming Business-tier behavior applies everywhere.

Can content exclusion stop sensitive data from reaching Copilot's model?

Content exclusion stops Copilot from reading files that match a configured path or glob pattern as context. It cannot evaluate the actual content of files that were not excluded, and it applies the same way regardless of who is making the request. A sensitive string in a file nobody thought to add to the exclusion list still reaches the model unfiltered.

Is GitHub Copilot's audit log enough evidence for a security review of AI usage?

GitHub's audit log documents account, seat, and configuration activity, which supports governance and operational questions. It does not produce a record tying a specific prompt's content to the authenticated developer who sent it and the policy that applied to that exact request. A security review that needs that connection requires a request-level record, not just administrative history.

Does org-level Copilot policy protect a specific regulated repository differently from the rest of the org?

Org and enterprise Copilot policies apply at the seat or organization level, not per repository or per request by default. If a specific repository requires stricter handling than the rest of the organization, that typically has to be enforced through repository-level content exclusion or a separate control layer, since policy toggles alone apply uniformly across the seats in scope.

Is Copilot's agent mode a bigger security risk than chat or completions?

Agent mode extends the same HTTP request pattern into multi-step actions, including opening pull requests, so the volume and autonomy of requests increase. The underlying question stays the same: which identity authorized the action, what content left the editor across each step, and what policy applied. Local execution and repository permissions around what an agent can commit are separate, adjacent concerns from the model request path itself.

GitHub Copilot Security: What the Request Path to the Model Covers

Every Copilot completion, chat reply, and agent-mode action starts the same way. VS Code (or another supported editor) packages the surrounding file content, the repository's language identifier, and the prompt text into an HTTP request, sends it to GitHub's Copilot API, and GitHub routes that call to a model from OpenAI or Anthropic depending on the configured backend. The response comes back over the same connection and lands in the editor as a suggestion, a chat message, or a pull request from the coding agent. That HTTP call, not the extension running locally, is where an enterprise's security posture for Copilot actually gets tested.

I want to walk through what GitHub's own controls cover on that path, and where the coverage runs out.

TL;DR

Copilot completions, chat, and agent-mode requests travel as HTTP calls from the IDE or GitHub client to GitHub's Copilot API, which routes to an underlying model provider.
Org and enterprise policy settings control which Copilot features are enabled and which model a given organization can use; they apply the same way to every developer holding a seat.
Content exclusion configures which repository paths GitHub will not send as context, but it filters by file path, not by who is asking or what the request contains.
Telemetry and audit-log settings record account and configuration activity. They do not, by themselves, produce a per-request record of what code left a given developer's editor.

The request leaves the editor before any org control sees it

A Copilot completion request carries the current file's surrounding lines, open-tab context the editor decides to include, and metadata like the repository name and primary language. GitHub's Copilot Trust Center documents that for Business and Enterprise plans, that prompt and the resulting suggestion are not retained to train GitHub's own models. That is a real, verifiable commitment about data retention on the provider side.

It is also a statement about what GitHub does with the request after GitHub receives it. It says nothing about whether the specific file the developer had open should have left the machine at all. A connection string sitting in a .env.example file that a developer forgot to rename, or a customer's account ID hardcoded into a debugging comment, travels in the same request as legitimate code context, because Copilot's context window does not distinguish sensitive strings from ordinary ones. Picture a developer at 9:40pm finishing a migration script, three tabs open, one of them a staging config file with a real database password left in from an earlier debugging session. Copilot's inline suggestion pulls context from all three tabs by design.

Org policy governs the seat, not the request

GitHub's enterprise and organization admins can set policies for Copilot that turn features on or off: whether Copilot Chat is available, which model an organization has selected for chat and agent tasks, and whether suggestions matching public code are filtered. Those policies apply uniformly to every seat in scope. A financial services company can require the public-code filter for its entire engineering org, or restrict which model Copilot Chat uses.

That is coarse, seat-level control. It does not evaluate an individual request. A developer with access to a regulated production repository and a developer working on an internal tools sandbox inherit identical policy, because the policy object is the organization, not the request. If the regulated repository holds source that a specific compliance obligation says should never leave a defined boundary, org-wide policy has no mechanism to catch that one request without also restricting every other request from the same seat.

Content exclusion filters by path, not by content or identity

Content exclusion lets an organization or repository owner define glob patterns for files and paths that Copilot should never read as context, configured at the organization, repository, or individual level. A team can exclude secrets/** or a legacy directory full of unreviewed credentials.

I think GitHub undersells how blunt this control actually is by calling it "content exclusion" rather than what it functions as: a static denylist that has to be maintained by hand and matched by path before anyone knows what a file actually contains this week. A new file added to an excluded directory is covered. A sensitive string that lands in a file nobody thought to exclude is not. The control operates on file paths configured in advance, not on the classification of what a given request contains or the role of the person sending it. Two developers with different clearance levels hitting the same unexcluded file get the same treatment, because content exclusion carries no concept of the requester's identity or authorization level. That gap is the same one covered in why AI security must be inline: a decision made in advance, against a static list, cannot evaluate a request that did not exist when the list was written.

Telemetry and audit settings record activity, not per-request decisions

GitHub's enterprise audit log and Copilot-related telemetry settings show configuration changes, seat assignments, and feature usage at the account level. That evidence supports operational and governance questions: who has a seat, when a policy changed, whether a team enabled agent mode. It was never built to answer a narrower question a security review eventually asks: which specific code context left this developer's editor, under what policy, and was that request evaluated against anything beyond "does this seat have Copilot enabled." I covered that gap in more detail in GitHub Copilot audit logs, including why enterprise administration events and request-level evidence answer different questions.

Adjacent control ownership

Local code execution, IDE extension supply-chain risk, and sandbox escapes inside VS Code or JetBrains are real engineering-security concerns, and they sit outside the HTTP path between the editor and GitHub's Copilot API. Those risks get addressed by endpoint controls, extension allowlisting, and the IDE vendor's own sandboxing, not by anything inspecting the AI request itself. The same is true of a stolen personal access token used to call the Copilot API directly. This piece is about what happens to a legitimate, authenticated request once it leaves the editor bound for a model, not about how that request got authenticated in the first place.

What request-level enforcement would need

Closing the gap between org policy and an individual request means evaluating three things before the request reaches GitHub's Copilot API: the authenticated identity behind the call, the classification of the content in that specific request, and a policy that can say yes to one request and no to the next one from the same seat. None of GitHub's native controls, policy settings, content exclusion, or telemetry, were built to make that per-request decision. They were built to configure a seat, filter a path list, and record what happened afterward. An identity-aware AI gateway sits at the point where that decision has to happen: after authentication, before the model sees the content.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline on the HTTP path between an authenticated developer or agent and the LLM endpoint a Copilot-compatible tool calls, evaluating each request against the identity behind it, the classification of the content in that request, and the organization's current policy, before the request reaches the model.

The decision, permit, redact, or deny, gets written to a signed, per-request audit record independent of GitHub's own telemetry. Org policy, content exclusion, and GitHub's audit log stay exactly as useful as they already are. DeepInspect adds the layer none of them were designed to provide: a request-level, identity-bound decision that a compliance review can point to for one specific prompt rather than one specific seat.

Book a demo today.