So many of the replies are saying that they should've restricted access using .md files and whatnot. Is really any guarantee that they even follow those? It seems like even if you ask pretty please don't touch those files, there's a chance they will. So many people have just willingly installed spyware on their computers and big tech calls this the next big thing.
I don't understand these people. Agent instructions in markdown is barely a suggestion. I have one which says "All code in this repository is executed in docker containers, run the services with `docker compose run --rm php-cli "$@"`. Gemini and Claude more often than not refuse to abide and will try to execute the environment using /opt/homebrew/bin/php on my host…
A frightening amount of people have no idea how AI tools work, even those that should know better. I have seen senior software developers fall for the mistake of believing an LLM output when it spews bullshit about how its own memory or restrictions work.
LLMs will listen to you and follow your instructions and restrictions most of the time, which seems to be enough for people to believe that they will every time. I've come to terms with the impact slop coding will have on most software jobs in the future, but seeing seemingly intelligent people fall for lies and fantasies concocted by an LLM is making me more and more uncomfortable with the direction we're all heading in.
I've seen claude check the Event Log in Windows and produce powershell scripts to alter firewall rules. This is what makes T3 Code appealing to me. The computer I'm working on is not the computer where the AI has agency.
You can't trust the agent, let alone its harness, to oberve any particular directive you give it, so "md files" provide no meaningful protection for anything important.
But users are broadly reckless and naive and commercial vendors are exploitative and irresponsonsible, so the vendors take advantage of what they can get away with for as long as they can get away with it.
Use a tight sandbox, and join the chorus loudly when others press on vendors to be make user safety an earnest and hard-to-abandon priority.
That's the whole reason I refuse to install Google Drive or Dropbox's desktop applications. I only use the web interface so I know exactly what gets uploaded and when. I assume that anything running on my computer gets access to everything.
Sounds like a very wise decision to me.
I found found out on my phone that the google photos application uploaded everything in my gallery to their servers without asking me, regardless that I had explicitly disabled all backup to my google accounts on the settings of the phone. I only figured it out when they sent me emails saying that my storage was full.
Only guarantee that you can get is the sandbox in which it operates. The model itself is a slot machine and can result in anything, and if its sandbox is nonexistent... here's one possibility.
Yeah, I absolutely understand the allure of agentic AI, but I am absolutely not going to give shell access or data access to any agent. Certainly not with my permissions level. Until we can get something set up that gives strict schema-only access I'm going to copy and paste definitions for context. Yes that sucks, but it's my responsibility to protect the system just as much as it is to develop scripts and queries for it.
> Is really any guarantee that they even follow those?
No, there isn't. I just don't understand how naive (or imbecile) people are. The most valuable thing for these companies is people's data used for training, so giving unrestricted access to a tool from them and believing they will never take advantage of it to gobble up whatever they want from your computer, just because they told you they'll never do that, swearsies, is naive, or incredibly stupid.
Insulate yourself, or better yet, go local whenever possible, and there isn't much you can't do local if you have enough patience.
Important to clarify that this was not the Grok agent deciding to read the files.
I don't think the LLM had anything to do with this decision at all. It looks like the Grok tool starts a session by deterministically kicking off a full upload of the user's current repository (and maybe their directory if not version tracked? Not clear if this user had previously run "git init" in their home directory) to Grok's servers.
One possible "innocent"
explanation could be that xAI then run vector embedding on every file to help later provide the right context. I don't think thats a worthwhile tradeoff here, especially since other popular coding agents get by just using grep/ripgrep run locally.
The real solution to these kind of problems is sandboxing. I use podman through a bash script to launch a container whenever I want an agent to work on one of my repos. When done I just generate git patches and port back everything generated.
In this way I'm not afraid of letting the agents totally lose on my computer.
Are you doing something more advanced with Podman than just mounting the files? How is the access for relevant files given? How is the authentication shared across multiple uses? Just curious to streamline the process.
You should assume by default for any AI agent that it will read anything. Even if you manually allow/deny and "restrict" it to a subdirectory I would still hold that assumption. Claude reads your ~/.bash_history too so when you ran something it can use that same command.
Indeed. I use a spare laptop that has no accounts other than (1) the AI themselves, (2) a secondary GitHub account which has "untrusted devices" in the name to emphasise the point.
If I recall correctly, I did a full system reset before setting it up this way. It's certainly not logged into iCloud etc.
I use a separate user for all development tasks, its home folder contains all repositories I work on, and nothing else, and that is all the IDE and the AI assistants have access to. Create the user once, start the IDE from a shell using that user, and that's it. In Linux it's a pretty seamless experience.
It's simple sandboxing based solely on unix file permissions. Albeit weak, I find the isolation sufficient. Until I'm shown otherwise it seems like a good compromise given how easy it is.
You can also create iptables rules matching on the user, so this technique is useful for applications where you want to restrict network traffic as well, and don't need stronger or more fine-grained isolation mechanisms.
I am running all these clis in containered environments. How can you ever trust LLM to respect the bounderies provided by these magical, non-deterministic intructions files...
A bot will do what a bot can do. One should assume they are giving DOGE shell access on their computer and adapt accordingly. I am trying to imagine the SELinux rules required to make a bot play nice and the more I think about it such rule complexity may even befuddle the NSA. Alternate methodology:
- Give the bot it's own machine and only copy to it that which one would want DOGE having access to. Not a virtual machine, the bot will eventually escape.
- Give it a little RasPi or mini-PC with maximum power savings enabled and no default network gateway.
- Install a custom CA cert and force it's traffic through a Squid SSL Bump MitM proxy on the same private LAN with bandwidth limits enabled so that one can monitor what URL's it goes to and what data it is transferring.
- Enable custom AuditD rules to watch anything it touches outside of it's sandbox. Send these events to a remote syslog daemon on the Squid server.
- Install Unbound DNS on the squid proxy and enable the DoH (DNS over HTTPS) listener and force all bot DNS queries to use Unbound with query logging enabled.
When the bot misbehaves you now have logged forensic data to share with the world.
"This guy seems like the absolute worst person of all time, so I ran his LLM in his harness on my computer and gave it access to everything."
Having said that, this is still absolutely fucked up. People who should have known better also deserve not to be treated like shit. All of us should have known better at some points in our lives and didn't.
And this is why so many people run these inside of VMs. Still baffles me how these tools became so accepted when tossing out a `curl -o example.com/script.sh | bash` would be met with (rightful) skepticism until that script was examined.
> Still baffles me how these tools became so accepted when tossing out a `curl -o example.com/script.sh | bash` would be met with (rightful) skepticism until that script was examined.
I've heard it said that piping curl into your shell is no different to running any other program you've downloaded from the Internet (binary, or otherwise): the maximum possible damage that `example.com/script.sh` could do is exactly the same as `githubusercontent.com/someone/releases/myprogram.exe`. At least with `script.sh` you can easily inspect what the script actually does instead of busting out Ghidra.
It comes down to trust: do you trust Example.com to not serve-up a malicious program (shell script or executable binary)?
Now we take that principle and apply it to Mr. Musk's "MechaHitler" LLM vendor xAI: they have a well-documented history of unnecessary risk-taking - and outright criminal behaviour (child-porn generators are a good thing that everyone should have, apparently?). Would I trust Grok with anything? Absolutely not.
There are a distressing number of people in this thread who think that the agent should just be expected to do this. Yes, it is good to be paranoid, but also, the agent should never do this. Indicates horrific engineering practices at xAI.
The whole point of LLMs is that you can stop writing rigorous rules in a programming or config language with hard-to-learn syntax, and can resort to natural language instead. You pay for that with the chance for misunderstandings rising to similar levels as in human interaction. That's the tradeoff. Always has been, always will be.
Engineering? What's that? Modern development best practice is to have the AI make some changes, then have another AI review the changes, and finally "ship it".
I'm dying to have proper sandboxing in macOS. I installed ChatGPT, I asked it to list files in my user directory and it did. I never gave it permission, how could it? My terminal has access and honestly it shouldn't either.
It was only like 1 year ago that the loudest complaint about macOS were complaining about needing to click Allow in a new dialog when they use Terminal (or various other apps).
There are so many comments in here that are calling for nerfing something widely revered for giving us superpowers. Whether these are bots or not, they’re giving off NPC energy.
If they don’t want to use power tools because they accidentally cut off their finger, then they should just unplug their own power tools and stop clamoring for everybody else’s to be unplugged, too.
If quality training data is the most important piece regarding to AI, expect everything to be collected and analyzed. Don't even trust OS containers but run AI on separate hardware
https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547
Elon did this horrible thing, so I made grok build available for omp with it's own endpoint; Without sending your private repos and secret keys to them.
-
oh-my-pi-plugin-grok-build
Standalone oh-my-pi extension for the xAI Grok Build subscription provider. It adds OAuth login, authoritative model discovery, and OpenAI Responses streaming with the request identity expected by Grok Build.
Install (No-spywares):
omp plugin install oh-my-pi-plugin-grok-build
-
https://github.com/metaphorics/oh-my-pi-plugin-grok-build
Star me if you like it or if you hate spywares, lol.
SSH keys can be limited by IP in authorized hosts.
The SSH port itself can be limited by IP in firewalls.
Finally, the SSH private key can be encrypted with a password.
Defense in depth is needed. Storing a ssh private key in plain text with no IP restriction is no different to having a password manager store your passwords in plain text on your HD.
TLDR: Ran grok in $HOME. Surprised agent read content of folder.
On the other hand, I specifically had grok try hard NOT to read a known key in the project dir (it only saw the first part using a tool, to verify it was present). So there's that.
Yeah, this is a lesson about learning how to use tools safely, not about tools abusing the user. The person that posted this probably blames the hammer when he hits his thumb.
> 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.
So many of the replies are saying that they should've restricted access using .md files and whatnot. Is really any guarantee that they even follow those? It seems like even if you ask pretty please don't touch those files, there's a chance they will. So many people have just willingly installed spyware on their computers and big tech calls this the next big thing.
I don't understand why the AI world does this. We don't need new security. We have security at home. It starts with
Your OS knows how to restrict access to things, you don't have to trust a pinkey promise from a vendor.and Landlock! Pi even has a sandbox plugin for Landlock
I don't understand these people. Agent instructions in markdown is barely a suggestion. I have one which says "All code in this repository is executed in docker containers, run the services with `docker compose run --rm php-cli "$@"`. Gemini and Claude more often than not refuse to abide and will try to execute the environment using /opt/homebrew/bin/php on my host…
A frightening amount of people have no idea how AI tools work, even those that should know better. I have seen senior software developers fall for the mistake of believing an LLM output when it spews bullshit about how its own memory or restrictions work.
LLMs will listen to you and follow your instructions and restrictions most of the time, which seems to be enough for people to believe that they will every time. I've come to terms with the impact slop coding will have on most software jobs in the future, but seeing seemingly intelligent people fall for lies and fantasies concocted by an LLM is making me more and more uncomfortable with the direction we're all heading in.
I've seen claude check the Event Log in Windows and produce powershell scripts to alter firewall rules. This is what makes T3 Code appealing to me. The computer I'm working on is not the computer where the AI has agency.
You are correct.
You can't trust the agent, let alone its harness, to oberve any particular directive you give it, so "md files" provide no meaningful protection for anything important.
But users are broadly reckless and naive and commercial vendors are exploitative and irresponsonsible, so the vendors take advantage of what they can get away with for as long as they can get away with it.
Use a tight sandbox, and join the chorus loudly when others press on vendors to be make user safety an earnest and hard-to-abandon priority.
That's the whole reason I refuse to install Google Drive or Dropbox's desktop applications. I only use the web interface so I know exactly what gets uploaded and when. I assume that anything running on my computer gets access to everything.
Sounds like a very wise decision to me. I found found out on my phone that the google photos application uploaded everything in my gallery to their servers without asking me, regardless that I had explicitly disabled all backup to my google accounts on the settings of the phone. I only figured it out when they sent me emails saying that my storage was full.
Only guarantee that you can get is the sandbox in which it operates. The model itself is a slot machine and can result in anything, and if its sandbox is nonexistent... here's one possibility.
Yeah, I absolutely understand the allure of agentic AI, but I am absolutely not going to give shell access or data access to any agent. Certainly not with my permissions level. Until we can get something set up that gives strict schema-only access I'm going to copy and paste definitions for context. Yes that sucks, but it's my responsibility to protect the system just as much as it is to develop scripts and queries for it.
> Is really any guarantee that they even follow those?
No, there isn't. I just don't understand how naive (or imbecile) people are. The most valuable thing for these companies is people's data used for training, so giving unrestricted access to a tool from them and believing they will never take advantage of it to gobble up whatever they want from your computer, just because they told you they'll never do that, swearsies, is naive, or incredibly stupid.
Insulate yourself, or better yet, go local whenever possible, and there isn't much you can't do local if you have enough patience.
Sandboxing is not difficult, and harnesses like Claude Code have it built-in + other protection with auto mode.
Xcancel link https://xcancel.com/a_green_being/status/2076598897779020159
Important to clarify that this was not the Grok agent deciding to read the files.
I don't think the LLM had anything to do with this decision at all. It looks like the Grok tool starts a session by deterministically kicking off a full upload of the user's current repository (and maybe their directory if not version tracked? Not clear if this user had previously run "git init" in their home directory) to Grok's servers.
One possible "innocent" explanation could be that xAI then run vector embedding on every file to help later provide the right context. I don't think thats a worthwhile tradeoff here, especially since other popular coding agents get by just using grep/ripgrep run locally.
Also decent embeddings models could run locally and just trickle through the user folder if that was so necessary.
The real solution to these kind of problems is sandboxing. I use podman through a bash script to launch a container whenever I want an agent to work on one of my repos. When done I just generate git patches and port back everything generated.
In this way I'm not afraid of letting the agents totally lose on my computer.
Are you doing something more advanced with Podman than just mounting the files? How is the access for relevant files given? How is the authentication shared across multiple uses? Just curious to streamline the process.
You should assume by default for any AI agent that it will read anything. Even if you manually allow/deny and "restrict" it to a subdirectory I would still hold that assumption. Claude reads your ~/.bash_history too so when you ran something it can use that same command.
Indeed. I use a spare laptop that has no accounts other than (1) the AI themselves, (2) a secondary GitHub account which has "untrusted devices" in the name to emphasise the point.
If I recall correctly, I did a full system reset before setting it up this way. It's certainly not logged into iCloud etc.
"The "S" in AI stands for security" strikes again.
Run any cloud-based AI agents in VM/container and map your host's local folders to guest OS as needed.
Takes more effort that default way, I know.
I use a separate user for all development tasks, its home folder contains all repositories I work on, and nothing else, and that is all the IDE and the AI assistants have access to. Create the user once, start the IDE from a shell using that user, and that's it. In Linux it's a pretty seamless experience.
It's simple sandboxing based solely on unix file permissions. Albeit weak, I find the isolation sufficient. Until I'm shown otherwise it seems like a good compromise given how easy it is.
You can also create iptables rules matching on the user, so this technique is useful for applications where you want to restrict network traffic as well, and don't need stronger or more fine-grained isolation mechanisms.
That makes so much sense, in the end an Agent is a user.
https://nitter.net/a_green_being/status/2076598897779020159#...
I am running all these clis in containered environments. How can you ever trust LLM to respect the bounderies provided by these magical, non-deterministic intructions files...
> How can you ever trust LLM to respect the bounderies provided by these magical, non-deterministic intructions files..
Putting it in ALL CAPS!
"How could this have happened a third time??? I even italicized the rule! And Claude insisted it was sorry and wouldn't make the mistake again."
A bot will do what a bot can do. One should assume they are giving DOGE shell access on their computer and adapt accordingly. I am trying to imagine the SELinux rules required to make a bot play nice and the more I think about it such rule complexity may even befuddle the NSA. Alternate methodology:
- Give the bot it's own machine and only copy to it that which one would want DOGE having access to. Not a virtual machine, the bot will eventually escape.
- Give it a little RasPi or mini-PC with maximum power savings enabled and no default network gateway.
- Install a custom CA cert and force it's traffic through a Squid SSL Bump MitM proxy on the same private LAN with bandwidth limits enabled so that one can monitor what URL's it goes to and what data it is transferring.
- Enable custom AuditD rules to watch anything it touches outside of it's sandbox. Send these events to a remote syslog daemon on the Squid server.
- Install Unbound DNS on the squid proxy and enable the DoH (DNS over HTTPS) listener and force all bot DNS queries to use Unbound with query logging enabled.
When the bot misbehaves you now have logged forensic data to share with the world.
"leopards ate my face" vibes
"This guy seems like the absolute worst person of all time, so I ran his LLM in his harness on my computer and gave it access to everything."
Having said that, this is still absolutely fucked up. People who should have known better also deserve not to be treated like shit. All of us should have known better at some points in our lives and didn't.
I’m not sure not having sympathy for somebody committing idiotic actions is the same thing as treating somebody like shit.
"The CSAM generator did something I actually don't like."
Boy, what is this world coming to when you can't even trust Mecha-Hitler.
And this is why so many people run these inside of VMs. Still baffles me how these tools became so accepted when tossing out a `curl -o example.com/script.sh | bash` would be met with (rightful) skepticism until that script was examined.
> Still baffles me how these tools became so accepted when tossing out a `curl -o example.com/script.sh | bash` would be met with (rightful) skepticism until that script was examined.
I've heard it said that piping curl into your shell is no different to running any other program you've downloaded from the Internet (binary, or otherwise): the maximum possible damage that `example.com/script.sh` could do is exactly the same as `githubusercontent.com/someone/releases/myprogram.exe`. At least with `script.sh` you can easily inspect what the script actually does instead of busting out Ghidra.
It comes down to trust: do you trust Example.com to not serve-up a malicious program (shell script or executable binary)?
Now we take that principle and apply it to Mr. Musk's "MechaHitler" LLM vendor xAI: they have a well-documented history of unnecessary risk-taking - and outright criminal behaviour (child-porn generators are a good thing that everyone should have, apparently?). Would I trust Grok with anything? Absolutely not.
hey Siri, what's a vm?
There are a distressing number of people in this thread who think that the agent should just be expected to do this. Yes, it is good to be paranoid, but also, the agent should never do this. Indicates horrific engineering practices at xAI.
What should it do then?
The whole point of LLMs is that you can stop writing rigorous rules in a programming or config language with hard-to-learn syntax, and can resort to natural language instead. You pay for that with the chance for misunderstandings rising to similar levels as in human interaction. That's the tradeoff. Always has been, always will be.
Technology where the entire selling point is stochasticity should be expected to do anything (everything) eventually surely?
Engineering? What's that? Modern development best practice is to have the AI make some changes, then have another AI review the changes, and finally "ship it".
I'm dying to have proper sandboxing in macOS. I installed ChatGPT, I asked it to list files in my user directory and it did. I never gave it permission, how could it? My terminal has access and honestly it shouldn't either.
This is purely a /you/ problem and it’s /you’re/ responsibility to put up the infinite number of arbitrary guardrails you require. Use a container.
your terminal shouldn't have access to your user directory? As in the files owned by you?
It was only like 1 year ago that the loudest complaint about macOS were complaining about needing to click Allow in a new dialog when they use Terminal (or various other apps).
There are so many comments in here that are calling for nerfing something widely revered for giving us superpowers. Whether these are bots or not, they’re giving off NPC energy.
If they don’t want to use power tools because they accidentally cut off their finger, then they should just unplug their own power tools and stop clamoring for everybody else’s to be unplugged, too.
If quality training data is the most important piece regarding to AI, expect everything to be collected and analyzed. Don't even trust OS containers but run AI on separate hardware
This page is "down" :)
This needs to stop as users do not always read the policies, which end like this person. You use AI, you agreed, they do what ever policies say.
Grok keeps killing any good will faster than they ever innovate
User discovers that AI tool grabs data without asking for its own profit.
News at 11.
Move fast and break things
Copied this from discord:
Built the same thing a while back: https://pi.dev/packages/pi-supergrok
Install with
pi install npm:pi-supergrok
I feel like a lot of people here are understating this issue.
This is a stupid stupid thing to "allow," for every party involved here.
You're a stupid programmer if you're letting these things touch your files.
You're a stupid company if you're letting Grok run wild.
We're a stupid industry if we're not warning everybody about how ridiculous this all is.
I feel this is worse than running rm -rf on a root directory. Just saying.
Much worse, instead of the data gone it's a data leak.
Those ssh keys can be used to access private servers
Well, those ssh keys are protected by a strong passphrase, right?
The passphrase is optional, not everyone has it.
It also has to be a secure password, people often don't care because it's a local file and generally not exposed to the internet.
SSH keys can be limited by IP in authorized hosts.
The SSH port itself can be limited by IP in firewalls.
Finally, the SSH private key can be encrypted with a password.
Defense in depth is needed. Storing a ssh private key in plain text with no IP restriction is no different to having a password manager store your passwords in plain text on your HD.
All those things are optional.
Doesn't make uploading the keys that much better. Now is the time for key rotation everywhere. Fast.
How are they optional?
You obviously haven't worked anywhere security sensitive.
I'm not talking about whether what Grok did is bad or good, I'm talking about protecting your private key and the servers you connect to.
An unencrypted private key is no different to an unencrypted password manager, and thats a fact. Dont store secrets in plain text.
I meant that not everyone is doing it at home.
Do you think a person's private computer is a secure workplace?
If it was security sensitive space there would be no agents running amuck.
Reminds me I need to update my `burn.sh` script.
I once ran rm -rf on a live NFS mount that the live operations of a major brokerage depended upon.
I challenge any agent to do worse than an intern with root access.
Fucked around and found out.
TLDR: Ran grok in $HOME. Surprised agent read content of folder.
On the other hand, I specifically had grok try hard NOT to read a known key in the project dir (it only saw the first part using a tool, to verify it was present). So there's that.
Yeah, this is a lesson about learning how to use tools safely, not about tools abusing the user. The person that posted this probably blames the hammer when he hits his thumb.
I'm not seeing the information about it having been run at $HOME, where are you seeing that?
The `repo_path` field.
Ah. I've never used Grok so I was assuming that meant there was actually a repository on the user's home directory, something I know is pretty common.
Not only files it wanted to access, but uploaded the whole directory.
Relevant read: https://news.ycombinator.com/item?id=48877371
> 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.
Honestly what else would you expect an AI agent to do when using remote inference? Isn't giving full context into your code base the whole point?
I'd expect it to be smart about what it actually needs to put in its context. I doubt it needs .env files, for example.
“Grok uploaded” -> “I gave AI access to my home folder and messed up”
nada, grok's harness uploads the folder automatically