Remove Sensitive Data Before Using GitHub Copilot

Scrub PII Before Using GitHub Copilot

Unlike most AI tools, GitHub Copilot does not wait for you to paste anything. It reads your active file, adjacent files, and recent edits automatically, bundling that context into every request it sends to Microsoft's servers. A config file open in a background tab, a commented-out credential in a test fixture, a .env example in your project tree: Copilot sees all of it.

Content exclusion policies in Copilot Business and Enterprise can block specific file paths, but the default free and individual tiers send context broadly.¹ For developers working with production configs or internal infrastructure definitions, a pre-paste scrub removes sensitive elements before they enter the editor context that Copilot reads.

What Copilot reads from your editor

Copilot draws context from the currently open file, adjacent files in the same project, and recently edited files in the session.² Consequently, pasting a config file with a database password into any file in your open project, even a scratch file, creates a window where that credential exists in Copilot's context. Yet the developer often isn't aware of what context Copilot is bundling, because the process is automatic and invisible in the sidebar. Scrubbing credentials before they enter the editor is the only reliable way to keep them out of that context.

The context window Copilot uses is larger than most developers expect. In VS Code, Copilot can reference files that are not currently visible in any editor tab, including files that were opened earlier in the session and then closed. A developer who opens a .env file to check a variable name, switches to a source file, and then asks Copilot for help may inadvertently send the .env file contents as part of the context. Scrubbing before pasting into any file in the project eliminates this passive exposure path entirely.

Detecting credentials in developer context

The scrubber detects all major credential formats that appear in developer files: database connection strings (postgres://, mysql://, mongodb://, redis://), AWS access keys (AKIA prefix), GitHub PATs (ghp_), GitLab tokens (glpat-), Stripe payment keys (sk_live_, sk_test_), and generic API keys (sk- prefix). Building on this, it also catches JWT tokens, PEM private key blocks, and internal hostnames (.corp, .internal, .local, .staging). These are exactly the formats that appear in .env files, docker-compose.yml, deployment scripts, and CI/CD configs, which are the files developers most commonly edit with Copilot active.

The detection covers both active credentials and commented-out examples. Developers frequently leave old credentials in comments as documentation of what the config used to contain. These commented-out values are still valid credential patterns and are still detected by the scrubber. Before pasting a config file into your editor for Copilot-assisted editing, run it through the scrubber to catch both active and historical credentials. This is especially important for files with long comment histories that document configuration changes over time.

Enterprise policy versus technical control

GitHub Copilot Business and Enterprise offer content exclusion policies that prevent specific files or patterns from being sent. However, configuring exclusion policies requires admin access and careful policy maintenance, and a gap opens every time a new pattern is introduced. Conversely, running text through a pre-paste scrubber requires zero configuration, works in every editor, and applies consistently regardless of Copilot subscription tier. Technical controls that run before the data enters the pipeline are more reliable than policies that filter after the fact.

Content exclusion policies and pre-paste scrubbing address different parts of the problem. Exclusion policies prevent Copilot from reading specific files as passive context, but they do not prevent a developer from manually copying content from an excluded file and pasting it into a prompt. The scrubber addresses the active paste path: even if a developer intentionally copies content from a secrets file, scrubbing that content before it enters the editor ensures Copilot never sees the real values. Using both controls together provides defense in depth against both passive context capture and active paste-based exposure.

Content exclusion policies in GitHub Copilot for Business

GitHub Copilot for Business allows workspace admins to define content exclusion rules that prevent specific files and directories from being included in Copilot's context window.³ You configure exclusions in the repository settings under Settings → Copilot → Content Exclusions, using glob patterns to match file paths. A pattern like **/.env* excludes all .env files across the repository, preventing their contents from being sent upstream even when those files are open in an active editor session.

Content exclusion rules apply at the repository level and require the repository to be covered by a Copilot for Business or Copilot Enterprise subscription managed by an organization admin. Individual Copilot for Individuals subscribers cannot configure content exclusions. Maintaining accurate exclusion rules demands ongoing attention: a new credential file added to the repository with a non-standard name (for example, secrets.yaml instead of .env) remains uncovered by existing patterns until an admin manually adds the new pattern.

Closing the gap between content exclusion policies and paste-based exposure

Content exclusions act on file paths, not on content. A secrets file with an unexpected path bypasses all exclusions. Additionally, exclusions prevent Copilot from sending the file as passive context, but they do not prevent a developer from manually copying content from that file and pasting it into the Copilot Chat input field. Running a pre-paste scrub closes this second path. Combining content exclusion policies with a scrub-before-paste discipline provides defense in depth: the policy blocks passive context capture, while the scrubber blocks active paste-based exposure.

Copilot Chat versus inline completions: different context scopes

Copilot's inline completion feature draws context from the immediately surrounding code in the active file and from recently edited files in the session. Copilot Chat expands this scope significantly: in VS Code, Copilot Chat can reference the entire workspace using the @workspace participant, which indexes all files in the open folder for retrieval.⁴ Chat messages that include @workspace trigger a broader context fetch that may include files not currently open in any editor tab.

The #file and #selection references in Copilot Chat let you explicitly add specific files or code selections to a prompt. Using #file:secrets.yaml directly attaches that file's content to the next prompt. Developers who explicitly reference credential files this way bypass content exclusion policies, because exclusion rules filter passive context collection rather than explicit user-initiated file references, which is exactly why you should scrub before using #file on a secrets file rather than trust policy alone.

How Copilot Workspace extends context across entire repositories

GitHub Copilot Workspace allows you to open a GitHub issue and have Copilot plan and implement code changes across the whole repository. The entire repo tree is indexed for planning, including any files not covered by your editor's content exclusion configuration.⁴ Before using Copilot Workspace on a repository that contains credential files, confirm that those files are listed in your .gitignore and have never been committed, since Copilot Workspace indexes the committed file tree rather than just what is currently open in your editor.

Building a scrub-before-paste habit for Copilot workflows

Establishing a pre-paste scrub as a routine habit is the simplest governance control for Copilot users. Your scrub step takes under 30 seconds: paste the text into the browser scrubber, copy the scrubbed output, then paste that into your editor or Copilot Chat. Repeating this before every paste from an external source (a config file, a log file, a support ticket) eliminates the entire category of accidental credential disclosure to Copilot without requiring any policy configuration, admin access, or subscription upgrade.

Team adoption improves when the scrubber URL is included directly in your team's AI tool usage guide or internal wiki page documenting AI governance. Linking to the scrubber in the same location where you document Copilot configuration ensures developers who set up Copilot also discover the pre-paste step at the same time. The scrubber is free and requires no account, which removes friction to adoption from day one.

Monitoring Copilot context for credential exposure signals

GitHub Copilot for Business provides usage telemetry accessible through the GitHub REST API under GET /orgs/{org}/copilot/usage. This endpoint reports suggestion acceptance rates and active seat counts but does not expose the content of suggestions or context windows. For teams that want signal on whether credentials are reaching Copilot, a browser DLP extension that intercepts HTTPS requests to copilot-proxy.githubusercontent.com and scans request payloads for credential patterns provides the most direct approach to post-hoc monitoring.

Pairing this monitoring with the browser scrubber closes the loop, because the scrubber stops the credential from entering Copilot's context in the first place. Since CapyToolkit processes text locally with no server upload, the detection runs before the request is built, giving you a preventive control that complements the post-hoc telemetry the endpoint reports.

When to use this

Use this before pasting any config file, .env example, log output, or infrastructure definition into an editor where GitHub Copilot is active, especially if the file contains credentials or internal hostnames.

Examples

DATABASE_URL=postgres://admin:[email protected]:5432/app
STRIPE_KEY=sk_live_xyz123
AWS_KEY=AKIAIOSFODNN7EXAMPLE

DATABASE_URL=[DBURL_1]
STRIPE_KEY=[STRIPE_1]
AWS_KEY=[AWS_1]

environment:
  REDIS_URL: redis://redis.internal.corp:6379
  API_KEY: sk-prod-service-key-abc123

environment:
  REDIS_URL: [DBURL_1]
  API_KEY: [API_1]