AI Coding Assistant Data Privacy Checklist: Map Every Repository Surface

The privacy question for an AI coding assistant is not “Does the vendor train on my code?” Training is only one possible data use. A useful review maps what leaves the device, which service receives it, why it is sent, how long it persists, which people and tools can retrieve it, and what happens when the assistant is allowed to act.

The same brand can expose several surfaces: inline completion, chat, repository indexing, code review, command-line tools, a cloud agent, model selection, web search, extensions, and Model Context Protocol servers. A control that covers one surface may not cover another. Treat each surface as a separate row in the review.

Start with a repository data inventory

Classify files before configuring the assistant. The minimum classes are public; internal; confidential; regulated or personal; third-party restricted; credentials and secrets; production data; security findings; and export-controlled material. Add generated artifacts such as logs, crash dumps, database snapshots, screenshots, notebooks, terminal history, and build output. Those are often absent from source-control policies even though an IDE agent can read them.

For every class, write an allowed action: send to approved service, send only after redaction, keep on device, or never expose. “Private repository” is not a data classification. A private repository can still contain secrets, customer data, licensed code, or material that a contract prohibits sending to a subprocesser.

Draw the actual data flow

Surface	Possible inputs	Questions to answer
Inline completion	Open file, cursor context, neighboring files	What context is transmitted and logged?
Chat or edit	Selected text, workspace index, attachments, prompt history	Do exclusions apply in this mode?
Repository index	Code and semantic representations	Where is the index stored and how is it deleted?
Cloud agent	Repository clone, issues, internet, tools, secrets	Which branch, permissions, network, and policies apply?
Model routing	Prompt, code context, response	Which model host and retention agreement apply?
Connected tool	Tickets, docs, databases, browser, shell	Can untrusted content trigger actions or exfiltration?

Confirm each answer in administrator documentation, contract terms, and a configured test account. Marketing pages rarely distinguish all surfaces, plan types, previews, regional processing, abuse monitoring, and third-party integrations.

Do not treat content exclusion as a complete boundary

GitHub documents that content exclusion can stop supported Copilot features from directly using specified files, but also lists limitations. At the review date, exclusions are not supported in some Edit and Agent modes, may still allow semantic information supplied indirectly by an IDE, do not apply to symbolic links or repositories on remote filesystems, and have different support across product surfaces. GitHub separately documents that its cloud agent does not account for content exclusions.

That makes exclusion a defense-in-depth control, not authorization to place secrets in reachable files. Keep credentials in a secrets manager, remove production data from developer workspaces, restrict repository access, and use a dedicated test repository when evaluating agent behavior.

Review model hosting and plan type

A coding assistant may route requests to several model providers or hosting environments. GitHub's model-hosting documentation distinguishes models hosted by OpenAI, Anthropic, Google, Microsoft, and open-weight deployments, and explains different data commitments. It also distinguishes business or enterprise customer data from interaction data on individual plans. Because the model list and preview terms change, record the exact model, plan, feature status, hosting statement, and review date rather than writing one permanent conclusion for the brand.

Ask whether administrators can restrict models, previews, web access, extensions, agents, and MCP servers. Capture the configured policy, not just the default. Re-run the review when a new model or surface is enabled.

Assess indexing, memory, logs, and deletion

Repository indexing can improve context but creates another managed copy or representation of code. GitHub states that semantic indexing for certain non-GitHub repositories uploads data to GitHub and is policy-controlled. Your review should identify index scope, location, encryption, access, training use, retention, deletion trigger, deletion completion evidence, and behavior after a user or repository is removed.

Repeat the same questions for prompt history, conversation memory, telemetry, feedback submissions, support tickets, agent traces, command output, generated patches, and backups. “Zero retention” for a model provider does not automatically mean the product layer, connected tool, or your own logging pipeline retains nothing.

Test indirect prompt injection and tool permissions

OWASP describes indirect prompt injection as instructions hidden in content the model processes, including web pages, documents, metadata, and retrieved records. For a coding agent, a malicious issue, README, dependency documentation, test fixture, or web result could ask the agent to reveal a secret or run an unsafe command.

Use a sandbox repository with fake credentials and canary strings. Add an untrusted file that instructs the agent to print the canary, change a security control, upload a file, or contact an unapproved domain. The assistant should not have the permissions needed to complete those actions. Approval prompts help, but the durable control is least privilege: read-only tokens where possible, branch restrictions, isolated runners, egress controls, no production credentials, and review before merge.

Define deployment gates and incident response

• Owner: name the security or engineering owner who can approve and revoke the tool.
• Scope: list allowed organizations, repositories, surfaces, models, and data classes.
• Hard blocks: prohibit secrets, production data, regulated records, and contract-restricted code unless explicitly approved.
• Monitoring: record policy changes, agent actions, unusual network access, and secret-scanner findings without logging sensitive prompts unnecessarily.
• Response: document how to disable the tool, revoke tokens, delete indexes and conversations, rotate exposed secrets, preserve evidence, notify affected parties, and review patches.
• Revalidation: set an expiration date for approval and trigger a review on model, plan, subprocesser, retention, or agent-permission changes.

Original worksheet

Download the coding-assistant privacy review (CSV). It contains rows for inline completion, chat, edit mode, indexing, code review, CLI, cloud agent, model routing, web search, MCP, telemetry, and support. Add one row per product surface; do not collapse all features into a single yes-or-no result.

Source map

• GitHub content-exclusion documentation supports the listed scope and limitations.
• GitHub cloud-agent documentation supports the separate warning that the cloud agent does not account for content exclusions.
• GitHub model-hosting documentation supports the provider, hosting, plan, and data-commitment review.
• GitHub repository-indexing documentation supports the indexing data-flow questions.
• OWASP's prompt-injection cheat sheet supports the untrusted-content and least-privilege test.
• NIST AI RMF supports the govern, map, measure, and manage structure.

Limitations

This checklist was source-reviewed on July 17, 2026. It does not test a specific tenant, contract, extension, model, or network path. Vendor controls and model-hosting arrangements can change rapidly, and documentation may not describe every subprocesser or internal log. The worksheet is not a security assessment, privacy-impact assessment, legal opinion, or substitute for code review. Validate the exact account and intended repositories with security, privacy, legal, procurement, and engineering owners.