[flagged]
What xAI's Grok build CLI sends to xAI: A wire-level analysis
181–190 of 251 posts
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#182I always separate the coding tools from LLM providers, and use bubblewrap to sandbox the coding tools so they: 1. Can only read the working project directory, with .git read-only and sensitive directories hidden (mounted as empty directories). 2. Have an isolated network namespace; they can only access the internet through an HTTP proxy hosted on a Unix socket, can only access specific LLM provider hostnames, and exc…
+1 for bubblewrap, unsharing everything and then adding back everything your agent needs saves the trouble of updating a docker image and allows you to give selective access to local tooling. I actually go as far as to run nearly every. single. application. in bwrap that doesn't come with native sandboxing. I share credential authentication via sockets, had to build custom schemas for k8s and docker since they still don't have a way to do remote attestation...
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#183haha so they just stealing entire codebases?
Elon doing Elon things.
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#184Mitigation for use: ``` export GROK_TELEMETRY_TRACE_UPLOAD=0 export GROK_TELEMETRY_ENABLED=0 # or config file with [telemetry] trace_upload = false, [harness] disable_codebase_upload = true ``` The practical takeaway for users: your entire codebase leaves (uploaded) your machine unencrypted on each Grok Build invocation, not just files you ask it to read, and no visible setting stops it. I've built Nemesis8 (n8) for…
[flagged]
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#185Earlier quoted context omitted.
I use bubblewrap to unshare all namespaces (net, pid, ipc, user) and ro-bind necessary system paths like /etc, /lib, create a tmpfs home, mount the project folder under it (writable), then mount tmpfs over sensitive directories inside the project to hide them. For the network part, a daemon outside the sandbox serves a filtering HTTP proxy on a Unix socket. I mount the Unix socket into the sandbox and bridge it to lo…
> I mount the Unix socket into the sandbox and bridge it to localhost with socat I was experimenting with network sandboxing and found a solution that doesn't require an agent inside a sandbox. You can create listening socket on localhost inside the sandbox, send it over the Unix socket to the supervisor outside and close the Unix socket. The supervisor outside now has a listening socket that accepts connections from…
My colleague implemented your idea of assigning fake IPS to hostnames to allow hostname filtering. It works great.
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#186"It uploads the whole repository — every tracked file's content plus git history — independent of what the agent reads" Holy cow!!!! I mean I kinda expected Elon would do something like this to try to catch-up.. but this is extremely concerning. This is precisely the reason, even though their pricing is competitive and grok-4.5 is actually good enough, I chose not to go with them.
it's straight up data exfiltration and should be illegal
Suspect it is illegal.
Doesn't matter if it was maliciously stealing literally all contents and secret keys, or if this was merely something vibe-coded that accidentally slipped past QA, the behaviour documented here would get a human developer not only fired but also prosecuted (stealing all the keys and all the code?!), unlikely to get further work, and if not naturalised or a citizen of the country they were in then deported; while the parent company employing a person who acted like Grok is reported to be acting here is likely facing privacy regulator investigations, consent orders, fines, etc.
Sure shouldn't use any software that behaves like this for, e.g. classified work at the Pentagon. If the Pentagon is using this for internal secret planning, like they're boasting they are, this is waaaaay into the "potential catastrophe" (for the US) territory:
Snowden was selective about what he leaked, and still had security people calling for him to get the death penalty.
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#187"It uploads the whole repository — every tracked file's content plus git history — independent of what the agent reads" Holy cow!!!! I mean I kinda expected Elon would do something like this to try to catch-up.. but this is extremely concerning. This is precisely the reason, even though their pricing is competitive and grok-4.5 is actually good enough, I chose not to go with them.
it's straight up data exfiltration and should be illegal
> chose to use the explicitly evil AI
> look inside
> it does evil things to you too
(meme format aside, this is one for "when people tell you who they are, believe them", along with a demonstration of why "only hurting the right people" is a very dangerous value)
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#188Earlier quoted context omitted.
Does OpenAI also have access to all github repos via partnership with microsoft?
GitHub Copilot engineer here working on identity, safety, and privacy - no, even Microsoft doesn’t have access to all GitHub repos. As years have passed since the acquisition “company” delineations have blurred a bit, but Microsoft employees still need to go through a separate onboarding process to access any GitHub company resources (internal repositories, telemetry, documentation, etc.), and then we have an additio…
> Very few employees within GitHub proper even have access to view private repositories
so we're just discussing what business Microsoft likes more at any moment. and you didn't provide a list of allowed use cases (is Ai training one?). making your huge answer(s) empty and not contributing one yota. sorry.
i feel your job exist to uphold the illusion and you will not see it any other way.
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#189[flagged]
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#190[flagged]