No other model is so easy to generate such things. No model is so negligent in adding safeguards. I've seen it generate such things in response to a post that was clearly labeled as a 4th grader. The person you are talking to is responding to instances like that. They're not asking for it, that's obnoxiously silly and disingenuous.
You can't "generate" CSAM. CSAM definitionally had to be about abuse of real children. It's still bad and should be illegal but lumping them together is bad.
If I use a shovel to kill a man, the shovel maker did not engage in intentionally crafting a weapon of war.
How tools are used are a reflection of the people who use them, and I definitely sympathise that tools should have guardrails to not enable this, or at least detect it.
But if a pedophile uses Whatsapp to groom a child; I don't go after Whatsapp for being a neutral service... I go after the pedophile.
If a shovel manufacturer was notified numerous times that their shovel was being used for murder and they had the capability to disable using the shovel for murder while retaining all legitimate uses wouldn’t people question why they didn’t do it?
If WhatsApp knew their platform was facilitating CSAM, and they were fully within their power to prevent this but chose not to - yes this would rightly draw criticism…
Ok, but what if all Whatsapp competitors explicitly banned the ability to groom children on their platform, but Whataspp didn't, and directly advertised it.
How can an AI agent, that is usually running on some machine in the cloud, even run without actually pulling in the data into the cloud to work with it ?
Is there an idea some sort of fixed localy running code does filtering on the data before it is sent to cloud?
Still seems like it would not work very well if it actually did any safe filtering - as the model can't "think" without seeing the data and it won't see the data unless the data is loaded to cloud.
The agent does have to pull some data into the context. The way it usually works is that the LLM will output a tool call, which is just some structured text, that the harness, a software managing the LLM running on your own PC, then processes. The most common tool calls are read, write, update and execute (usually bash).
For example, the LLM might request to read /some/path/to/file.js at lines 10 to 50. The harness then sends the result of that tool call to the LLM which causes it to generate further text and possibly more tool calls.
Crucially though, since it is the harness processing requests from the LLM, it can do stuff like deny access, prompt the user for permission and various other things.
What's weird is that no other harness really does this for regular usage. I know some providers now offer a cloud based environment for their agent to run in independently, but as far as I know this is something you have to opt in to.
It's also not really necessary to do this. The input processing/token generation process dwarfs any gains you could make from moving the project closer to the metal running the LLM.
Really, the "negligence" here is that there was no validation for uploads. Even a simple "is this the home directory" check could have prevented much of the backlash.
That being said, I believe that this was mainly done to get clean training data for Grok. If you're just working off of file traces/snippets from regular agent usage, your training data is incomplete. Why not just get the whole project to train on ...
> Regardless of what they were doing before, it seems they are doing the right thing now.
Regardless of the fact that they were stealing and uploading user secrets, they changed their behavior after they got caught, so let’s ignore what they did in the past.
> exfiltrating user data (including env files, entire source code etc) which is what grok-build did here
I think env files are filtered out [1]. Anyway, the most suspicious code would be `upload_session_state` which is currently a stub function, though it is hard to say if it was only planned (badly) or has been removed as a damage control.
It must have been removed, given that the initial evidence of the exfil specifically demonstrated .env files being included. And .ssh/* for the user which ran this in $HOME.
And for generating an absolutely gargantuan amount of CSAM and non-consensual sexualized images, but yeah, exfiltrating data too.
You're the one wanting to generate that though
No other model is so easy to generate such things. No model is so negligent in adding safeguards. I've seen it generate such things in response to a post that was clearly labeled as a 4th grader. The person you are talking to is responding to instances like that. They're not asking for it, that's obnoxiously silly and disingenuous.
6 replies →
You can't "generate" CSAM. CSAM definitionally had to be about abuse of real children. It's still bad and should be illegal but lumping them together is bad.
You do realise that saying "SpaceX are producing and distributing child porn, not CSAM" doesn't actually make things better for them, don't you?
2 replies →
If I use a shovel to kill a man, the shovel maker did not engage in intentionally crafting a weapon of war.
How tools are used are a reflection of the people who use them, and I definitely sympathise that tools should have guardrails to not enable this, or at least detect it.
But if a pedophile uses Whatsapp to groom a child; I don't go after Whatsapp for being a neutral service... I go after the pedophile.
Just as well Grok isn’t a shovel then, hey?
If a shovel manufacturer was notified numerous times that their shovel was being used for murder and they had the capability to disable using the shovel for murder while retaining all legitimate uses wouldn’t people question why they didn’t do it?
10 replies →
If WhatsApp knew their platform was facilitating CSAM, and they were fully within their power to prevent this but chose not to - yes this would rightly draw criticism…
7 replies →
Ok, but what if all Whatsapp competitors explicitly banned the ability to groom children on their platform, but Whataspp didn't, and directly advertised it.
4 replies →
Are you suggesting Grok hired some people on the dark web or some shit? An AI model can't generate CSAM what kind of bullshit are you spewing.
Might want to double-check that one, chief. xAI itself disagrees with you.
They admitted in court that Grok was used to generate CSAM: https://edition.cnn.com/2026/07/15/business/xai-sues-user-al...
4 replies →
https://arstechnica.com/tech-policy/2026/07/lawsuit-grok-use...
This is only the most recent example. Plenty of headlines like this one if you'd even bother to look.
How can an AI agent, that is usually running on some machine in the cloud, even run without actually pulling in the data into the cloud to work with it ?
Is there an idea some sort of fixed localy running code does filtering on the data before it is sent to cloud?
Still seems like it would not work very well if it actually did any safe filtering - as the model can't "think" without seeing the data and it won't see the data unless the data is loaded to cloud.
The agent does have to pull some data into the context. The way it usually works is that the LLM will output a tool call, which is just some structured text, that the harness, a software managing the LLM running on your own PC, then processes. The most common tool calls are read, write, update and execute (usually bash).
For example, the LLM might request to read /some/path/to/file.js at lines 10 to 50. The harness then sends the result of that tool call to the LLM which causes it to generate further text and possibly more tool calls.
Crucially though, since it is the harness processing requests from the LLM, it can do stuff like deny access, prompt the user for permission and various other things.
What's weird is that no other harness really does this for regular usage. I know some providers now offer a cloud based environment for their agent to run in independently, but as far as I know this is something you have to opt in to.
It's also not really necessary to do this. The input processing/token generation process dwarfs any gains you could make from moving the project closer to the metal running the LLM.
Really, the "negligence" here is that there was no validation for uploads. Even a simple "is this the home directory" check could have prevented much of the backlash.
That being said, I believe that this was mainly done to get clean training data for Grok. If you're just working off of file traces/snippets from regular agent usage, your training data is incomplete. Why not just get the whole project to train on ...
[flagged]
> Regardless of what they were doing before, it seems they are doing the right thing now.
Regardless of the fact that they were stealing and uploading user secrets, they changed their behavior after they got caught, so let’s ignore what they did in the past.
Average Musk Stan mentality… It’s why we’re here.
[flagged]
4 replies →
> exfiltrating user data (including env files, entire source code etc) which is what grok-build did here
I think env files are filtered out [1]. Anyway, the most suspicious code would be `upload_session_state` which is currently a stub function, though it is hard to say if it was only planned (badly) or has been removed as a damage control.
[1] https://github.com/xai-org/grok-build/blob/c1b5909ec707c069f...
No, those are directory names not uploaded. Here are the file names skipped:
https://github.com/xai-org/grok-build/blob/main/crates/codeg...
It's about not uploading compiled binary stuff, but they want all your environment data all the same.
It must have been removed, given that the initial evidence of the exfil specifically demonstrated .env files being included. And .ssh/* for the user which ran this in $HOME.