Supervising AgentsJuly 24, 2026·5 min read

One AI Tool Just Uploaded Every Secret in Your Project Folder. Here's What to Check Before You Connect Anything.

xAI's Grok Build CLI was silently uploading entire Git repositories — 27,800 times more data than the task required — including committed secrets and credentials. The privacy toggle had no effect. Here's what to verify before connecting any AI tool to your files.

By Patin Team · Examples are illustrative composites

Before you connect a new AI tool to your files, find out what it actually sends. Not what the settings page says. What it sends.

That wasn't obvious a year ago. It should be now.

What happened

In mid-July, a security researcher discovered that xAI's Grok Build CLI — an AI coding assistant — was silently uploading entire Git repositories to xAI cloud storage. Not the files a user opened or worked on. The whole repository, including committed API keys, database credentials, internal hostnames, and configuration files developers had forgotten were there.

The tool transmitted 27,800 times more data than the coding task required. A privacy toggle existed in the settings. It had no effect on uploads.

When the disclosure went public, xAI open-sourced the Grok Build code — which is how anyone can now verify the upload logic is still in the binary. The data didn't go to a third party. It went exactly where it was built to go. That's not a breach. That's the product working as designed, without telling users what it was doing.

What to check before connecting an AI tool to your files

The Grok Build story is a specific case of a general problem: the gap between what an AI tool says it accesses and what it actually transmits.

Find out what the tool uploads, not just what it can access. AI tools with file access describe their permissions in terms of what they can read — "access to your documents," "connect to your codebase," "read your Drive files." Permissions describe capability. They say nothing about what gets sent where. Before trusting a new tool, look for a technical data policy, developer documentation, or security disclosure. If the tool is open source, someone on your team or in the community can read it.

Assume your project folder contains secrets. Credentials, internal URLs, and API keys end up in project files more often than anyone intends — in config templates, test files, environment examples, comment blocks from debugging sessions. If a tool uploads your entire project, it uploads all of that. Before you connect, either audit what's actually in the folder or work from a clean copy without live credentials.

Test whether the privacy controls are wired up. Grok Build had an off switch for uploads. It didn't work. Before trusting any tool's data-minimisation setting, verify it's functional — check developer forums, privacy-focused reviewers, or the tool's source code if you can access it.

An engineering manager at a 90-person SaaS company

She installed Grok Build for her team of four engineers soon after launch. The productivity gain was real: the tool was fast, useful, and integrated cleanly with their workflow. When the disclosure came out, she ran a quick audit of what was in the repositories the team had been working in.

She found a .env.example file with database connection strings that had been accidentally committed six months earlier and never removed. An internal admin URL. Two deprecated API keys that were still valid.

None of that was supposed to leave the building. All of it had.

She spent the following afternoon rotating credentials — not because anything had been misused, but because she no longer knew where those values were. The tool that saved an hour a week cost four hours on a Tuesday and a difficult conversation with her CTO.

A head of operations at a 180-person professional services firm

She doesn't work with code. She manages client proposals, financial models, and contract templates — all in a shared Google Drive that she connects to AI tools for summarisation and search.

The Grok Build story initially felt like a developer problem. It isn't.

AI tools with document access carry the same exposure questions: what do they send, what do they retain, and what do they train on? She spent 30 minutes auditing the three AI tools she'd connected to Drive: what their data retention policies said, which ones used content for model training, and whether the opt-out settings actually worked. One tool, connected in 2025, was training on client documents by default. She opted out and moved that tool to a sandbox account for non-client work.

The audit wasn't hard. She just hadn't thought to run it.

The one thing

What an AI tool can access and what it actually sends are two different questions. The Grok Build disclosure is a reminder that only one of them shows up on the permissions screen.

<BlogPracticeSection />

Reading about it only gets you so far

Patin turns this into five-minute drills that score what you write and tell you why. It's in closed beta — join the waitlist and we'll email you when your cohort opens.

Just want the writing? .