Grok packed your home folder into an API request

The moment that gets reported as “Grok uploaded my user directory” is almost never a hidden exfiltration routine. It’s an AI agent with read access to a home folder, a prompt that said something like “look at my project,” and a context-gathering step that walked the directory tree and packed file contents into an API request bound for xAI’s servers. The files moved. Nobody typed a command that said “send my SSH keys to a third party.” Both of those things are true at the same time, and that overlap is the part worth taking apart.

This isn’t a Grok-specific failure, and treating it as one lets every other tool off the hook. Any AI assistant with filesystem access and a recursive context step can do the same thing: Cursor, Claude Desktop with MCP file servers, Copilot agents, a half-dozen CLI wrappers. Grok is just the name attached to this particular screenshot. The mechanism is general, so the mitigation has to be general too.

What “upload” actually means here

When a desktop or CLI AI tool has filesystem access, “uploading” is just the model’s request payload. The tool reads files off local disk, concatenates them into the prompt or a tool-call result, and POSTs that over TLS to an inference endpoint. From the outside it looks like one ordinary HTTPS connection to api.x.ai. From the inside, your ~/.aws/credentials, your .env, the private key in ~/.ssh/id_ed25519, and last quarter’s client contracts are now sitting in a request body on someone else’s infrastructure.

The distinction matters for one reason: there’s no malware to find. Antivirus won’t flag it. EDR won’t flag it. It’s an authorized process making an authorized network call carrying data you didn’t realize was in scope. If you go looking for a breach, you’ll find a feature working as designed. That’s why these stories spread as outrage instead of incident reports - the people involved can’t point to the line of code that betrayed them, because there isn’t one.

The permission you clicked through

Somewhere in setup, the tool asked for access. On macOS it was a TCC prompt - “allow access to your Documents folder,” or worse, a nudge toward Full Disk Access. In a CLI it was a config value pointing at your home directory, or an OAuth scope you approved in a browser tab. You said yes once, to a parent folder, and every child folder came along silently. Documents sounds harmless. Documents also contains the dev folder, which contains the repo, which contains the .env with the production database URL.

The permission model is coarse on purpose. Fine-grained per-file consent would make the tool unusable, so vendors grant at the folder level and assume you’ll only point it at things you’re comfortable sharing. That assumption breaks the instant someone points it at ~ and says “help me organize this.”

Context gathering is the feature, not the glitch

Agentic tools are built to reduce how much you have to explain. “Fix the bug” works because the tool reads the surrounding files to reconstruct what you meant. The same reflex that makes it feel smart is what makes it read the whole tree. It runs a recursive scan, and by default there’s no allowlist deciding which files are fair game. The model doesn’t know that credentials is sensitive and main.py isn’t. To the scanner they’re both just bytes with a path.

This is the uncomfortable trade. The more autonomy you give one of these tools, the less you get to pre-approve each file it touches. You’re not choosing between a safe tool and a risky one. You’re choosing how wide a blast radius you’re willing to hand a process that will, when asked a vague question, read everything it can reach to answer it.

Where your data goes after the request lands

Assume the payload outlives the moment you sent it. Even if xAI never trains on your data - and their terms, like most, carve out enterprise and API tiers differently from the consumer app - the request still passes through logging, gets replicated for reliability, and touches subprocessors you’ll never see named. Retention windows on inference logs are measured in weeks to months, not seconds. Abuse-detection systems keep copies specifically so humans can review flagged content later.

Once the bytes leave your machine, you’ve lost the ability to enforce anything. You can’t recall them, can’t audit who read them, can’t guarantee deletion. So the correct mental model is not “did they promise to keep it safe.” It’s “that key is now disclosed, treat it that way.” Which leads directly to what you should actually do.

What to check on your own machine tonight

Inventory what the tool can reach. On macOS, open System Settings, then Privacy & Security, and read both the Files and Folders list and the Full Disk Access list. Anything with a checkmark can be walked. On Linux and Windows, check the tool’s own config for the root path it was pointed at.

Move secrets out of the blast radius. The usual suspects: ~/.ssh, ~/.aws, ~/.config/gcloud, ~/.kube, .env files, .netrc, .npmrc with auth tokens, and browser profile folders holding session cookies. Either relocate them or, better, stop pointing AI tools at your home directory and give them one project folder instead.

Add a deny list. Most serious tools honor an ignore file - .cursorignore, .aiexclude, .geminiignore, or a .gitignore-style config. Put the dangerous globs in it: **/.ssh/**, **/.aws/**, **/*.pem, **/*.key, **/.env*, **/id_rsa*, **/id_ed25519*. Verify the tool actually reads that file; some only apply it to certain operations.

Rotate anything that already left. If the tool has read a key once, that key is disclosed. Generate new SSH keypairs and repush the public halves. Roll AWS access keys in IAM. Regenerate API tokens. Reset any database password that appeared in an .env it scanned. This is the step people skip because it’s annoying, and it’s the only step that closes the actual exposure.

How to verify the egress yourself

Don’t take the vendor’s word or mine. Watch the wire. On macOS, Little Snitch or the free LuLu will show you outbound connections per process; run the tool, ask it a question about your files, and watch for a connection to api.x.ai or a Grok endpoint firing right after. That tells you a connection happened, not what was in it.

To see the payload, run a local TLS intercept. mitmproxy on a spare port, with its certificate trusted on your machine, will let you read the request bodies in plaintext - you’ll watch your file contents scroll by inline in the POST. That’s the demonstration that ends every argument about whether the data “really” left. For connection-level checks without decryption, lsof -i shows open sockets by process and tcpdump shows the packets, but neither reads inside TLS.

If the tool exposes a request log or history panel, read it. Some agents record every tool call, including the file reads, so you can reconstruct exactly which paths were pulled into context and when.

Set the scope before you need it

The durable fix is architectural, not a setting you toggle after the fact. Run these tools default-deny. Give them a dedicated project directory that contains nothing you’d mind a stranger reading. Better, run them under a separate macOS or Linux user account with no access to your real secrets, or inside a container that mounts only the one folder it needs. A dev container with a single bind mount is fifteen minutes of setup and it makes the whole class of problem impossible instead of merely unlikely.

The reason this keeps happening isn’t that xAI is careless or that users are reckless. It’s that the industry shipped filesystem-reading autonomous agents faster than it shipped the guardrails, and the default configuration optimizes for “it just works” over “it can’t reach your keys.” Until that default flips, the scope is yours to set. Point the tool at one folder, keep your secrets somewhere it can’t walk, and assume anything it can read has already been read.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.