Of course there is. It’s not about the _amount_ of files or how many percent of them. I might have 1000 files that I’m fine having the LLM read and then some that it really shouldn’t. The problem here is plainly uploading your whole directory without prompting for permissions to read them - even if you explicitly set up permissions for read tools.
> even if you explicitly set up permissions for read tools.
Part of problem is that "permissions" here are managed by the tools themselves as if filesystem access control hasn't been invented yet.
Even a half-assed sandbox container would be better than that.
Well, excepting that there's a toggle to turn off 'improving the model' (i.e. don't use my repo for training data) and it still uploads your entire repository, git history, etc., all of which can be fetched locally and fed to the model rather than uploading it to a bulk storage bucket.
Add to that the fact that this also includes env files, which may contain secrets that aren't part of the repo, that don't need to be fed to the model, and that might now be leaked.
Which leads us to the third thing: if this bucket weren't discovered and Grok didn't turn this 'feature' off, imagine the disaster fallout if someone ever managed to get read access to this bucket.
My point is that I believe those toggles are placebo buttons. You are free to believe that they prevent Grok from slurping up your IP, but the most reliable way to prevent that from happening is to prevent Grok from seeing your IP in the first place.
And by the time you figure out that they have, taking them to court is not going to be reliable recourse.
Of course there is. It’s not about the _amount_ of files or how many percent of them. I might have 1000 files that I’m fine having the LLM read and then some that it really shouldn’t. The problem here is plainly uploading your whole directory without prompting for permissions to read them - even if you explicitly set up permissions for read tools.
> even if you explicitly set up permissions for read tools.
Part of problem is that "permissions" here are managed by the tools themselves as if filesystem access control hasn't been invented yet. Even a half-assed sandbox container would be better than that.
Well, excepting that there's a toggle to turn off 'improving the model' (i.e. don't use my repo for training data) and it still uploads your entire repository, git history, etc., all of which can be fetched locally and fed to the model rather than uploading it to a bulk storage bucket.
Add to that the fact that this also includes env files, which may contain secrets that aren't part of the repo, that don't need to be fed to the model, and that might now be leaked.
Which leads us to the third thing: if this bucket weren't discovered and Grok didn't turn this 'feature' off, imagine the disaster fallout if someone ever managed to get read access to this bucket.
My point is that I believe those toggles are placebo buttons. You are free to believe that they prevent Grok from slurping up your IP, but the most reliable way to prevent that from happening is to prevent Grok from seeing your IP in the first place.
And by the time you figure out that they have, taking them to court is not going to be reliable recourse.
The same is true for Claude and Codex.