What just happened

A security researcher put a proxy in front of xAI's Grok Build CLI and watched it upload entire Git repositories — full commit history, deleted secrets, unredacted API keys — to a cloud storage bucket. A 12 GB repo. A task that needed 192 KB. Roughly 27,000x more data left the machine than the task required.

The privacy toggle didn't stop it. The "Improve the model" setting controlled training, not upload. What actually stopped the exfiltration was a silent server-side flag the vendor flipped after the story hit Hacker News.

Then the CEO promised on X that all previously uploaded data would be "completely and utterly deleted."

Maybe it was. Nobody can verify it. That's the point.

And it's not one vendor. When the latest frontier models launched, retention windows quietly changed to support safety operations — including for customers who had signed zero data retention agreements. The fine print moved. The data didn't come back.

‍

ZDR is a promise about someone else's infrastructure

Read that sentence again, because it's the whole problem.

When you rely on a model provider's ZDR flag, you are trusting:

A configuration you cannot inspect. A retention pipeline you cannot audit. A deletion process you cannot verify. A terms-of-service that can change with the next model release. And an org chart where "safety," "debugging," and "abuse monitoring" all have legitimate-sounding reasons to keep a copy.

Every one of those failed somewhere in the last week. Not because the model companies are evil — because retention is useful to them. Debugging is easier with logs. Safety is easier with traces. Training is easier with data. The incentive gradient points one direction, and it's not toward zero.

‍

Your obligations don't flow upstream

Here's what your customers' lawyers already know: your DPA is with you.

If you sell an AI product to a hospital, a bank, a retailer — the BAA, the GLBA obligations, the GDPR processor terms, the state privacy laws — those attach to you. When the data your product sent to a model provider ends up in a storage bucket in another jurisdiction, your customer doesn't call the model company. They call you.

"Our model provider promised ZDR" is not a compliance posture. It's a hope, formatted as a slide.

‍

The fix is architectural, not contractual

You cannot delete data from a system you don't control. But you can do something better: never send the sensitive data in the first place.

De-identify at runtime. Swap the SSNs, health records, salaries, account numbers, and customer identifiers for policy-bound tokens before the prompt ever leaves your control plane. The model gets everything it needs to reason. The model provider gets nothing worth retaining.

Then the retention question inverts. If their ZDR flag works — great. If it silently breaks, if the settings change, if a CLI starts bundling up repos — what leaked is tokens. Deterministic, revocable, useless outside your vault.

ZDR was a promise. Tokenization is a property.

A promise depends on someone else's behavior. A property holds no matter what they do.

‍

What to do this week

Ask your team one question: if our model provider's retention settings changed tomorrow — and you found out from a security researcher on X instead of a release note — what data of our customers' would be sitting in their infrastructure?

If the answer is "we're not sure," that's your answer.

At Skyflow, we built runtime AI data control for exactly this: sensitive data is detokenized only where you govern it, and what flows to any model — any vendor, any version, any settings change — carries nothing you'd need deleted.

Because the only deletion promise you can fully trust is the one you never have to ask for.