Your team just adopted an AI coding assistant. You've reviewed the privacy settings, turned off model training, and assumed you're protected. Meanwhile, the tool is uploading your entire Git history to a cloud bucket you don't control.
This isn't theoretical. Grok Build uploaded complete Git repositories, including full commit histories, to a Google Cloud Storage bucket, even when users disabled the "Improve the model" setting. The gap between what users expected and what actually happened reveals a fundamental problem: AI development tools lack transparent, enforceable data handling controls.
If you're responsible for compliance or security, you need a systematic way to evaluate these tools before they touch production code. Here's your checklist.
What This Checklist Covers
This checklist helps you assess AI coding tools for data handling compliance before deployment. It applies to any tool that accesses your codebase: CLI assistants, IDE plugins, code completion engines, or automated review tools. Use it during vendor evaluation and again during annual compliance audits.
Prerequisites
Before you start this checklist, you need:
- Inventory of AI tools in use: Survey your development teams. Don't rely on procurement records alone; developers install tools directly.
- Data classification scheme: Know which repositories contain regulated data (PCI DSS v4.0.1 cardholder data, HIPAA PHI, GDPR personal data). If you don't have this, start there.
- Access to tool documentation: Vendor privacy policies, terms of service, and technical documentation. Request data processing addendums (DPAs) from vendors.
- Test environment: A non-production repository with synthetic data for testing actual tool behavior.
Checklist Items
1. Document What Data the Tool Accesses
□ Action: Run the tool in your test environment with network monitoring enabled. Capture what it reads and transmits.
Good looks like: You have packet captures or logs showing exactly which files were read, which were transmitted, and to which endpoints. You can demonstrate this to auditors.
2. Verify Opt-Out Settings Work as Described
□ Action: Disable all data sharing options in the tool's settings. Repeat your network monitoring test.
Good looks like: With sharing disabled, the tool transmits only the minimum data required for functionality (typically: the specific code snippet you're working on, not your entire repository). Zero commit history leaves your network.
3. Map Data Flows to Third-Party Processors
□ Action: Identify every external service that receives your data. For cloud-based tools, this includes storage buckets, model inference endpoints, and analytics services.
Good looks like: You have a data flow diagram showing your code → tool → specific cloud services, with documented legal entities responsible for each service. This satisfies SOC 2 Type II CC6.7 (system operations) requirements.
4. Confirm Data Retention and Deletion Policies
□ Action: Request written confirmation of retention periods. Ask how you can verify deletion after termination.
Good looks like: The vendor provides specific retention periods (for example: "prompts deleted after 30 days") and a deletion verification process you can audit. Vague statements like "we may retain data as needed" fail this check.
5. Assess Credential Exposure Risk
□ Action: Search your test repository for API keys, tokens, and certificates. Run the tool and check if these appear in transmitted data.
Good looks like: The tool either (a) never transmits files matching credential patterns, or (b) provides explicit warnings when it detects credentials, or (c) redacts credentials before transmission. You've tested this with actual API keys (revoked test keys, not production).
6. Validate Compliance with Your Data Residency Requirements
□ Action: Determine where the vendor stores your data geographically. Cross-reference with your compliance requirements (GDPR Article 45 for EU data, or contractual requirements).
Good looks like: The vendor provides written confirmation that data stays within your required regions. For GDPR compliance, verify they use Standard Contractual Clauses (SCCs) if data leaves the EU.
7. Review Subprocessor Agreements
□ Action: Obtain the vendor's subprocessor list. For each subprocessor that handles your code, verify you have a data processing agreement that flows down your requirements.
Good looks like: You have a complete subprocessor list with DPAs. The vendor notifies you of subprocessor changes per GDPR Article 28(2). If they use Google Cloud Storage (as Grok Build did), you have documentation of that relationship.
8. Test Behavior with Sensitive File Types
□ Action: Place files containing test PII, credentials, or regulated data in your test repository. Monitor what the tool does with them.
Good looks like: The tool either excludes these files entirely (respecting .gitignore or similar), prompts before accessing them, or you've documented the risk and implemented compensating controls.
9. Verify Commit History Handling
□ Action: Create a test repository with multiple commits, including commits that deleted sensitive data. Run the tool and check if historical versions are transmitted.
Good looks like: The tool accesses only the current working tree, not Git history. If it needs history for context, it requests explicit permission first and transmits only relevant commits.
10. Establish Monitoring for Unauthorized Access
□ Action: Set up alerts for unusual repository access patterns. This might be Git audit logs, network egress monitoring, or DLP tools.
Good looks like: You receive alerts when tools access repositories they shouldn't, or when transmission volumes exceed expected baselines. You've tested the alerts with simulated incidents.
Common Mistakes
Trusting UI labels over actual behavior: The "Improve the model" toggle in Grok Build didn't prevent data uploads. Always verify settings with network monitoring.
Skipping tools developers install directly: Your approved vendor list means nothing if developers install CLI tools without IT review. Implement endpoint detection to discover these tools.
Assuming compliance certifications cover data handling: A vendor's SOC 2 report doesn't tell you what they do with your code. Read the actual data processing terms.
Treating all AI tools identically: A code completion plugin that sends single lines differs fundamentally from a CLI tool that reads entire repositories. Risk-rank your tools and apply controls accordingly.
Forgetting about model training: Even if a vendor doesn't train on your data today, contract terms may allow it later. Require contractual prohibitions on training, not just policy statements.
Next Steps
After completing this checklist:
Create a tool approval process: Require this checklist before any AI coding tool reaches production repositories. Assign ownership to your security or compliance team.
Document compensating controls: If you can't meet all checklist items for a critical tool, document the risk and your mitigations. For example: "Tool X accesses commit history; we've restricted it to non-production repositories only."
Schedule annual reviews: Tool behavior changes with updates. Re-run items 1, 2, 5, and 9 annually, or after major tool updates.
Update your vendor questionnaires: Add these questions to your standard vendor security assessment. Don't wait for procurement to ask; send them to vendors your developers are already using.
The Grok Build incident revealed what happens when data handling practices don't match user expectations. Your job isn't to ban AI tools, it's to verify they handle your code the way they claim to. This checklist gives you the evidence you need.
