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 will keep banging this drum until people listen:
Trying to use markdown files to limit access should never be treated as a security guarantee at all.
This is a form of in-band signalling that goes into a machine that, among other things, tries to read between the lines of your requests, extrapolate user desires, and please the user.
The only sane way to address this is using a control plane. A well-built harness can do this; a sandbox can do this; hell, a carefully-chosen `umask` can do this; but both of those are liable to introduce notification fatigue in the user.
It's wild that we've known for decades to use ACLs to make sure people don't have access to files we don't want them to have access to, but somehow a computer pretending to be a person doesn't get that same treatment.
> Trying to use markdown files to limit access should never be treated as a security guarantee at all.
This is akin to politely asking guests to to steal your jewels. If your jewels are in the living room, and your guests have unfettered access to the living room, this technique will only work for the most trustworthy of guests.
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 know it may seem like that reading HN but LLMs are not necessary for writing software, they might be a useful adjunct to it, but they do not have to be central to it (and Id argue they shouldn’t be).
We don’t have to head in this direction of using LLMs for most development at all.
There’s an aspect of extrapolation in the perception spike of the Dunning–Kruger effect.
In the same way smart people, doctors etc, can be better victims for scams I think tech skills can really give the wrong impression of how transformers and LLMs work. If someone has decades of relational database experience all their assumptions will be coloured towards data existing in the model accessible in a rational manner.
I've seen claude check the Event Log in Windows and produce powershell scripts to alter firewall rules. This is what makes (something like) T3 Code appealing to me. The computer I'm working on is not the computer where the AI has agency.
You will want at least a separate session for the `restricteduser`: E.g. with X11, a process in the same session can do almost anything with your input/output. And most Linux distributions make it really hard to disable external device access for individual users...
> And most Linux distributions make it really hard to disable external device access for individual users...
For any distro that relies on the traditional plugdev group, just don't add those users to the plugdev group. Which would be the default when creating a user anyway.
Does this have the affordances to work well with a pretty standard agentic coding setup (e.g. claude code/codex) on macos?
I don't really have a good mental model of how ports/files/etc get exposed/permissioned across users. Containers and sandboxing seem much more common than agent-user accounts. Networking seems a little more complicated in the general case.
I roughly went the route of running apple's container-cli (separate vm/kernel per instance I believe) and mount the relevant home directory/projects and bind ports. Seatbelt/linux sandboxing seems simpler sometimes, but has its complications too.
It's limited. For instance, you're going to have to explore different kinds of sandboxing if you want to prevent network access (except for certain cases, like to allow it to talk to the AI provider). But generally, a filesystem will have metadata for files like which groups are allowed to read/write, and the operating system will enforce those rules for processes that run as that user, and for any processes which that user starts. I feel like that gets you 90% of where you're likely to want to go with it.
I think it would be much better if we leaned into improving that kind of control rather than thinking about security for specifically agents. Otherwise what's to stop an agent from writing a program to do whatever it's not allowed to do, and then running that program? You want the restrictions to be enclosing around parts the process tree, not the agent itself, and OS-level restrictions have been doing that kind of things for decades.
Why would you give a non-deterministic text generator a user account? It’s not a person, it’s barely a tool at the software level. Restrict at the right level, in this case, a complete sandbox around it given its propensity to hallucinate and be steered by anybody.
The standard here is not enough when the agent can escalate by finding 0 days, for example. It’s like giving a black hat a limited account. Sure it might restrict him, but not giving him an account at all is way better
But none of these services have the kind of latent capabilities an agent has, you know a deterministic service’s constraint are its code+bugs. There are no such constraints in an agent…
...this is a completely normal thing to do in linux, it's the most basic form of access control. There's like a dozen non-human accounts in a clean install before adding your own like this, and a lot of software adds their own. Edit: I have 54 entries on my personal laptop, just one of which is actually me.
This model is already not perfect, and not at all built for agents. The only way to secure an agent is an air-gap with the execution layer. Treat it like text, and the problem never arises until you “interpret” the agent output in a more limited environment than the OS
Even though it’s completely normal to us and in widespread use, GP is a reminder that conceptually it’s a broken model. Security should be capability-based not user-based. And to anyone who didn’t grow up on a desktop this model makes complete sense since it’s what your phone uses.
He said it’s less than a software, so saying software does this too isn’t really a strong counter argument. In case, I don’t think you are really in disagreement. Restricted accounts are necessary is your point, but I think op is saying they aren’t sufficient.
Is it less secure if I simply have nothing to do with language models whatsoever? I take that to be the parents point, but I know you are correct and yes, user restrictions should be a necessary part of the way people who use LLMs setup their system to use them in a safe manner.
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.
If it’s to be trusted, it has nothing to do with the “agent” or what’s sent to the LLM. The harness will just straight up package the folder it’s run from and upload it to Google Cloud Storage.
> If it’s to be trusted, it has nothing to do with the “agent” or what’s sent to the LLM. The harness will just straight up package the folder it’s run from and upload it to Google Cloud Storage.
Even if there is a misunderstanding who is really uploading the directory, the TUI/CLI itself by actual code, or if the model decided to do so in the session, if you apply the recommendations from the replies to parent, and it no longer matter who did it, neither the software nor the model will be able to upload all your ssh keys.
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.
Ooooh, don't get me started how mad it makes me! I am paranoid (or just lucky) enough that I didn't yet had it happen to me, but my wife's phone had done it four times in the last year. Each time I check and double check that all "backups" are turned off, and each time it somehow pops back.
So, Google "backs up" a 128Gb worth of photos on the phone onto 15Gb free storage combined with Gmail and who knows what, completely clogs it (as if it couldn't be predicted) and then has audacity to suggest paying for "extra storage". There is no way in online UI to just delete the whole "backup". And the cherry on top: when you finally get to delete some there is a fine-print - "the selected photos will be deleted from all synced devices". Well, I guess I must be thankful that they at least show this warning. This is what passes as "backup" in Google's parlance these days.
Sometimes you can't even rely on harness not allowing ai to access certain files. "Oh, user doesn't want me to use `read_file` on .env? Well how about I run `cat .env` then?"
That's scary. Really should run it under different user with carefully assigned permissions.
I guess the downside of the lower barrier to entry to use these tools is the lack of basic understanding of exactly this sort of concept.
This sort of thing is why I'm hopeful I'll continue to have employment going forward. Some expertise is hard won and there's just no replacing learning through experience.
I think you're right in principle but I just hope I can hold out long enough for my experience to become appreciated and whose corresponding hourly rate isn't something which is suddenly being scoffed at (i.e. markets can remain irrational longer than I can remain solvent).
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.
> ... I am absolutely not going to give shell access or data access to any agent. Certainly not with my permissions level.
Of course not.
To me it's on a server, in a VM. And they're not seeing the real data/databases from the actual projects: they're seeing fake infos used only while in the dev environment. There's no way I'm dumping, even for tests, the real or part of the real DB somewhere an AI can see it.
To find bugs (for example), AIs are useful but honestly for code generated by LLMs, I'm thinking about going back to the early copy/paste from the ChatGPT days: because I see so many horrors in the code output by the latest SOTA LLMs that every single line of code they spew has to be checked by someone who does know better.
It's not just an issue of protecting confidential data / preventing spying: we're all discovering that we've got serious sloppy-pasta code problems now.
> 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.
You can even go a step further and run the container in a VM, such as with Docker Sandbox or the krun runtime in Podman.
There's also smolvm which is a nice minimal microvm manager based on libkrun: https://github.com/smol-machines/smolvm. I vibe coded a little shell utility for building and running OCI images for the Pi harness using it (easy enough to do manually, but the automation just makes it a couple quick commands rather than digging through documentation): https://github.com/neuroblaze/smol-pi
Yup, good call, I'll have to check those out. Not that urgent to me as I also happen to use colima for it's docker daemon interface. And, colima uses a full VM to host the containers, and you can further lock down the config to what is even allowed to vol mount so there's even another fs access restriction layer in play.
I almost exclusively dev in containers as is, cant really imagine letting some AI model run free on bare metal no matter what claims of guardrails it might have.
Is that built in protection really a filter, on code level, that sits between the LLM session and the shell or is it just some pleading in the bootstrap prompt? "Pretty please don't do xyz this is important!!!11"?
The latter can seem to be as good as the former for any amount of time. No outside observation can really prove reliability, only the negative result ("it does occasionally break the rules we expect") would be proof. So it's difficult to trust any claims that it's the former.
And even if it does have some of the former, chances are that the protection you experience is only partially provided on code level, while an unknown amount is still just bootstrap prompting that just works until does not.
> So many of the replies are saying that they should've restricted access using .md files and whatnot.
What? No, but the random 3rd party software you run on your computer, must be limited by you in some way, haven't we learned this even after the AUR, npm and LLM shenanigans we've dealt with for decades at this point?
No, don't ask the model "Please don't go outside this directory", you limit the runtime (via VMs, containers, unix permissions, whatever) so it only has access to what it should, not more.
Same goes for any software, not just agents or chat clients or whatever. Any 3rd party software you don't want to have access to your entire computer, you need to run in this way.
"IMPORTANT: Before entering the leopard pen, don't forget to put on the leopard safety jacket that reads 'UNDER NOT CIRCUMSTANCES SHOULD YOU EAT MY FACE'"
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.
Yeah, I'd expect this approach to be almost universal, with the caveat that of the few who don't, many still don't get bitten.
But it turns out even in the container, there are footguns that have occasionally made the news by being fired: few projects don't have any external resources and when credentials with any form of write access happen to make it into the container (even if it's just a session cookie) agents might jump at the opportunity.
It’s not that intricate. A very simple docker and alias setup will get you an ephemeral container with your Claude (or whatever) config and the current wd bind mounted in. That’s a pretty good start.
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.
Just a little bit, I want coding agents to work their own disposable copy of a git repo. Here is a quick rundown of what it does:
It copies the current Git repo into the sandboxes dir, mounts that copy at /workspace in the container. The original repo is never mounted writable, so I don't care if the agent goes to town/wild in there (peace of mind).
It also builds cached Debian/mise/Elixir/Phoenix images, can start a private Postgres container, publishes selected localhost ports, reuses dependency/build caches, and prints commands on exit for reviewing diffs, exporting patches, applying them back to the real repo, or reopening the same sandbox later. Pi, and OpenCode are configured with proper LLM access keys (derived from my own).
So spinning a new sandbox is a matter of cding into a project directory and run something like: `ai-sandbox --port 4000 --postgres somedbname` or `ai-sandbox --port 4001` if I don't need DB support. Then when running the server in the container I can access it from the host machine to review in my browser.
I work on a sandbox which has similar isolation level to Podman (rootless Linux user namespaces), but with UX optimized for local development work. Take a look: https://github.com/wrr/drop
Basically, you don't enter a separate container in which you install a new distro, but you run on top of your current distro. You have environment specific home dirs which isolate your original home, but can have some files, such as configs, mounted from your original home (mostly in read-only mode).
This is wonderful - might even be exactly what one of my projects needs to use as a dependency.
In the README it mentions that it puts the dev environment in a filesystem jail, but how are you able to use your hosts bins without leaking access to the rest of the system? Or is that just an assumed liability?
It assembles and pivots to own root filesystem. The filesystem mounts dirs and files from your original filesystem, most of them in read-only mode, but does not mount files that expose secrets to the sandbox. The sandbox also mounts own, writable version of your home dir, so secrets, such as .ssh dir are not exposed. The config file allows to configure which files should be exposed from your original home. For example, configs, such as .bashrc, are safe to expose in read-only mode, provided you don't store secrets in them.
A bot will do what a bot can do whether malicious or accidental. 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. This applies to all bots or agents of all LLM's. Name the node DOGE to remind anyone using it not to share their crown jewels. Come up with a silly name for the agent. Elonious?
- Give it a little RasPi or mini-PC with maximum power savings enabled and no default network gateway.
- Install a self signed CA cert on the DOGE node and force it's traffic through a Squid SSL Bump MitM proxy on the same private LAN to another node with bandwidth limits enabled so that one can monitor what URL's it goes to and what data it is transferring. Configure Squid Access Control Lists to only permit specific domains and optionally URL's, mime-types, sizes, etc...
- 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 attempts to misbehave there will be forensic data to share with the world.
You shouldn’t run any AI cli (codex, claude code, open code, whatever) locally outside of a vm. It’s like “you shouldn’t run a .exe you downloaded from the internet if you don’t trust the source”. We will learn
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.
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.
We all know the dangers of running agents with no permissions on our laptop.
The good news is its now just as easy to spin up a sandbox in the cloud for an experiment or coding session than it is on your laptop. Possibly easier since laptop sandboxes aren't as cut and dry as a new cloud VM.
exe.dev is my sandbox infra of choice. You get a new sandbox in literally a second with SSH and a coding agent (Shelley) built in.
I generally drop in in my own binary with toolkit so I can connect Claude or Codex subscription and use their harness.
> We all know the dangers of running agents with no permissions on our laptop.
Some/maybe most of the HN crowd, sure, but as a rule ... definitely not. People are generally happy to take whatever the path of least resistance is.
I know quite a few civilians (even C-level people) who "heard openclaw was cool" (or whatever) and downloaded the first installer they found and hit enter/run without thinking twice.
How would it mitigate this issue? Presumably you'd need all the code for a given project inside the sandbox anyways, so the agent will still be able to upload everything. The only thing it might mitigate is you accidentally uploading your home directory.
Or if you're on Linux or macOS, learn how Unix permissions work and can be used for, create a new restricted user locally, use that. No need to go all remote with all its drawbacks just to limit a little local process on your computer.
Even better: you can fork the exeuntu image & make it immediately more relevant to the things you do in addition to just dropping in your programs and such.
I commented not so long ago to people very invested in AI, agents and tokens that are very enthusiast that I would not use an agent for security reasons and loss of control (besides suboptimal output).
It seems I was not wrong.
Not that I do not use AI. I do: fenced, always pasting my snippets and NEVER giving access to my code. Always from the browser. I know what it can do well and which workflows accelerates for me. But I do not want to think that my whole project ends up somewhere else.
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...
"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 meant "treated like shit by Grok" and I agree with Diogenesian: you can both believe that somebody did something dumb and also believe that what happened to them is fucked up and that being dumb doesn't mean you deserve to get mistreated.
You should ALWAYS run your agent as separate, unprivileged, UNIX user, never in your main account.
If you absolutely need to run it as your own user, you should bubblewrap it. I do this for things like Steam, games, or other "blackbox" closed source programs that cannot be reasonably trusted.
Lots of people responding about LLM but this sound like it’s their coding software („grok build“). Which is approx 100x worse.
LLMs going rogue is a thing and shit happens but publishing software that is uploading user directories including ssh keys is insane behaviour on xAIs part (alledgedly)
the 'upload your home directory to our servers' feature is the kind of thing that used to require a warrant and now it's just a Tuesday afternoon bug report
This is why it's going to be a long time before companies will trust AI to scan their networks or apps for security vulnerabilities.
Our company audited a few AI-based pentesting companies and requested logs. In more than one case, it was sending drop tables for sql query injection checking and other destructive operations.
The reports of copilot running amok when Microsoft integrated it into Windows 11 should have been enough of a warning. You either ensure proper sandboxing, or you'll be in for a bad surprise eventually.
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.
Have the comments been combined with another story? Because this isn't about a LLM reading and sending contents of the file to be processed, but the agent framework uploading every single file in /home/user to a random server.
It’s not really paranoia that makes me expect this will happen. It’s more like, well, the model weights and the files I want the model to work on have to be inside the same GPU for the agent to actually work, right? So step 1 has to be either “they send me a server rack of GPUs”, or “I send them the files I want the model to work on”. I’m not sure I could reasonably expect anything except this to happen.
How could it possibly work without something effectively the same as this happening? Either you run the LLM locally or you send it your files. Am I missing something?
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".
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
Don't store any secrets in your repo. Don't store them in env vars.
Strong long passphrase on your SSH keys, stop using unencrypted SSH keys. Everything in a keychain.
The practice of storing secrets in a .gitignore'd .env.local.json or whatever is a really bad idea and I can't believe that it has become a normalized, acceptable practice in the industry.
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 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.
Sadly, the pendulum keeps swinging in the way of the tools actually being unplugged and dumbed down in favor of these screaming people, rather than leaving things alone so the rest of us professionals can continue to (safely) do our jobs with the already somewhat restricted tools we have.
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.
I am sure majority of people don't use password for ssh keys. The good solution is to use password manager like 1password which will prompt you to approve ssh.
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.
Anything that isn’t a default is optional by default. Anything that’s toggleable or configurable is optional.
Security is, always, a trade off. It is hilariously common for private keys to work as a full identifier for a person, without concern of IP or anything of the sort. Should they? Maybe, maybe not, that’s the calculus of risk management; but victim-blaming the average person who is following best practices is a bad look.
I'm a security eng and I've worked for both a FAANG and TS government contractor. Neither of them bothered with either of the of the stupid suggestions. IP restrictions prevent roaming, the point of working remotely via SSH. passwords are equally defeated by using an ssh agent, something I'd suggest everyone use. Then on top of that there's no reasonable threat model where something would be given unrestricted access to user env, but also be untrusted. If it can read from ~/.ssh neither IP protection nor keyfile password protection will protect you from maleficence.
The only reasonable response from a security perspective is don't use grok, then use it sandboxed. Trying to claim it's the users fault for not using password protection and IP restrictions is completely nonsensical. Same energy as telling someone their computer is more secure when it's off.
The point is to know better than to let the intern hurt themselves.
I once saw an engineer try to place the blame on his intern for taking down prod. I was sitting in a meeting with the VP of engineering and someone asked if it was ok for some to blame their intern for the SEV, and I remember the VP saying "I'll talk to $director_for_the_interns_mentor". Interns can't take down prod. An intern's mentor willingly watching an intern take down prod is the closest you can get.
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.
Trying to use markdown files to limit access should never be treated as a security guarantee at all.
This is a form of in-band signalling that goes into a machine that, among other things, tries to read between the lines of your requests, extrapolate user desires, and please the user.
The only sane way to address this is using a control plane. A well-built harness can do this; a sandbox can do this; hell, a carefully-chosen `umask` can do this; but both of those are liable to introduce notification fatigue in the user.
This is akin to politely asking guests to to steal your jewels. If your jewels are in the living room, and your guests have unfettered access to the living room, this technique will only work for the most trustworthy of guests.
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 know it may seem like that reading HN but LLMs are not necessary for writing software, they might be a useful adjunct to it, but they do not have to be central to it (and Id argue they shouldn’t be).
We don’t have to head in this direction of using LLMs for most development at all.
In the same way smart people, doctors etc, can be better victims for scams I think tech skills can really give the wrong impression of how transformers and LLMs work. If someone has decades of relational database experience all their assumptions will be coloured towards data existing in the model accessible in a rational manner.
For any distro that relies on the traditional plugdev group, just don't add those users to the plugdev group. Which would be the default when creating a user anyway.
I don't really have a good mental model of how ports/files/etc get exposed/permissioned across users. Containers and sandboxing seem much more common than agent-user accounts. Networking seems a little more complicated in the general case.
I roughly went the route of running apple's container-cli (separate vm/kernel per instance I believe) and mount the relevant home directory/projects and bind ports. Seatbelt/linux sandboxing seems simpler sometimes, but has its complications too.
I think it would be much better if we leaned into improving that kind of control rather than thinking about security for specifically agents. Otherwise what's to stop an agent from writing a program to do whatever it's not allowed to do, and then running that program? You want the restrictions to be enclosing around parts the process tree, not the agent itself, and OS-level restrictions have been doing that kind of things for decades.
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.
If it’s to be trusted, it has nothing to do with the “agent” or what’s sent to the LLM. The harness will just straight up package the folder it’s run from and upload it to Google Cloud Storage.
Even if there is a misunderstanding who is really uploading the directory, the TUI/CLI itself by actual code, or if the model decided to do so in the session, if you apply the recommendations from the replies to parent, and it no longer matter who did it, neither the software nor the model will be able to upload all your ssh keys.
So, Google "backs up" a 128Gb worth of photos on the phone onto 15Gb free storage combined with Gmail and who knows what, completely clogs it (as if it couldn't be predicted) and then has audacity to suggest paying for "extra storage". There is no way in online UI to just delete the whole "backup". And the cherry on top: when you finally get to delete some there is a fine-print - "the selected photos will be deleted from all synced devices". Well, I guess I must be thankful that they at least show this warning. This is what passes as "backup" in Google's parlance these days.
That's scary. Really should run it under different user with carefully assigned permissions.
This sort of thing is why I'm hopeful I'll continue to have employment going forward. Some expertise is hard won and there's just no replacing learning through experience.
The real enforcement has to be done via methods that YOU can't easily bypass, or they will bypass (OS-level prohibitions, etc).
https://github.com/ashishb/amazing-sandbox
Of course not.
To me it's on a server, in a VM. And they're not seeing the real data/databases from the actual projects: they're seeing fake infos used only while in the dev environment. There's no way I'm dumping, even for tests, the real or part of the real DB somewhere an AI can see it.
To find bugs (for example), AIs are useful but honestly for code generated by LLMs, I'm thinking about going back to the early copy/paste from the ChatGPT days: because I see so many horrors in the code output by the latest SOTA LLMs that every single line of code they spew has to be checked by someone who does know better.
It's not just an issue of protecting confidential data / preventing spying: we're all discovering that we've got serious sloppy-pasta code problems now.
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.
There's also smolvm which is a nice minimal microvm manager based on libkrun: https://github.com/smol-machines/smolvm. I vibe coded a little shell utility for building and running OCI images for the Pi harness using it (easy enough to do manually, but the automation just makes it a couple quick commands rather than digging through documentation): https://github.com/neuroblaze/smol-pi
The latter can seem to be as good as the former for any amount of time. No outside observation can really prove reliability, only the negative result ("it does occasionally break the rules we expect") would be proof. So it's difficult to trust any claims that it's the former.
And even if it does have some of the former, chances are that the protection you experience is only partially provided on code level, while an unknown amount is still just bootstrap prompting that just works until does not.
yes, on mac it uses seatbelt and on other platforms it uses similar tools: https://code.claude.com/docs/en/sandboxing
What? No, but the random 3rd party software you run on your computer, must be limited by you in some way, haven't we learned this even after the AUR, npm and LLM shenanigans we've dealt with for decades at this point?
No, don't ask the model "Please don't go outside this directory", you limit the runtime (via VMs, containers, unix permissions, whatever) so it only has access to what it should, not more.
Same goes for any software, not just agents or chat clients or whatever. Any 3rd party software you don't want to have access to your entire computer, you need to run in this way.
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.
https://cursor.com/docs/agent/tools/search
Child pornography and sexual pictures uncensored on Grok? Its not Elon Musk issue until it becomes his issue.
Let get Elon Musk, the richest person on the planet with his own propagandaplatform off the hook eh?
/s
In this way I'm not afraid of letting the agents totally lose on my computer.
But it turns out even in the container, there are footguns that have occasionally made the news by being fired: few projects don't have any external resources and when credentials with any form of write access happen to make it into the container (even if it's just a session cookie) agents might jump at the opportunity.
Or, the internal sandboxing.
It copies the current Git repo into the sandboxes dir, mounts that copy at /workspace in the container. The original repo is never mounted writable, so I don't care if the agent goes to town/wild in there (peace of mind).
It also builds cached Debian/mise/Elixir/Phoenix images, can start a private Postgres container, publishes selected localhost ports, reuses dependency/build caches, and prints commands on exit for reviewing diffs, exporting patches, applying them back to the real repo, or reopening the same sandbox later. Pi, and OpenCode are configured with proper LLM access keys (derived from my own).
So spinning a new sandbox is a matter of cding into a project directory and run something like: `ai-sandbox --port 4000 --postgres somedbname` or `ai-sandbox --port 4001` if I don't need DB support. Then when running the server in the container I can access it from the host machine to review in my browser.
In the README it mentions that it puts the dev environment in a filesystem jail, but how are you able to use your hosts bins without leaking access to the rest of the system? Or is that just an assumed liability?
- 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. This applies to all bots or agents of all LLM's. Name the node DOGE to remind anyone using it not to share their crown jewels. Come up with a silly name for the agent. Elonious?
- Give it a little RasPi or mini-PC with maximum power savings enabled and no default network gateway.
- Install a self signed CA cert on the DOGE node and force it's traffic through a Squid SSL Bump MitM proxy on the same private LAN to another node with bandwidth limits enabled so that one can monitor what URL's it goes to and what data it is transferring. Configure Squid Access Control Lists to only permit specific domains and optionally URL's, mime-types, sizes, etc...
- 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 attempts to misbehave there will be forensic data to share with the world.
If I recall correctly, I did a full system reset before setting it up this way. It's certainly not logged into iCloud etc.
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'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.
The good news is its now just as easy to spin up a sandbox in the cloud for an experiment or coding session than it is on your laptop. Possibly easier since laptop sandboxes aren't as cut and dry as a new cloud VM.
exe.dev is my sandbox infra of choice. You get a new sandbox in literally a second with SSH and a coding agent (Shelley) built in.
I generally drop in in my own binary with toolkit so I can connect Claude or Codex subscription and use their harness.
https://github.com/housecat-inc/scratch
If I was working with newer agents like Grok I'd absolutely experiment on a cloud sandbox before running on my laptop bypassing permissions.
Some/maybe most of the HN crowd, sure, but as a rule ... definitely not. People are generally happy to take whatever the path of least resistance is.
I know quite a few civilians (even C-level people) who "heard openclaw was cool" (or whatever) and downloaded the first installer they found and hit enter/run without thinking twice.
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.
... that's guaranteed vuln-free, right?
It seems I was not wrong.
Not that I do not use AI. I do: fenced, always pasting my snippets and NEVER giving access to my code. Always from the browser. I know what it can do well and which workflows accelerates for me. But I do not want to think that my whole project ends up somewhere else.
Putting it in ALL CAPS!
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.
If you absolutely need to run it as your own user, you should bubblewrap it. I do this for things like Steam, games, or other "blackbox" closed source programs that cannot be reasonably trusted.
LLMs going rogue is a thing and shit happens but publishing software that is uploading user directories including ssh keys is insane behaviour on xAIs part (alledgedly)
Our company audited a few AI-based pentesting companies and requested logs. In more than one case, it was sending drop tables for sql query injection checking and other destructive operations.
SmolVM can easily run Pi, codex and claude https://github.com/CelestoAI/smolVM
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.
The practice of storing secrets in a .gitignore'd .env.local.json or whatever is a really bad idea and I can't believe that it has become a normalized, acceptable practice in the industry.
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.
Sadly, the pendulum keeps swinging in the way of the tools actually being unplugged and dumbed down in favor of these screaming people, rather than leaving things alone so the rest of us professionals can continue to (safely) do our jobs with the already somewhat restricted tools we have.
Install with
pi install npm:pi-supergrok
News at 11.
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.
Those ssh keys can be used to access private servers
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.
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.
Doesn't make uploading the keys that much better. Now is the time for key rotation everywhere. Fast.
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.
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.
Anything that isn’t a default is optional by default. Anything that’s toggleable or configurable is optional.
Security is, always, a trade off. It is hilariously common for private keys to work as a full identifier for a person, without concern of IP or anything of the sort. Should they? Maybe, maybe not, that’s the calculus of risk management; but victim-blaming the average person who is following best practices is a bad look.
The only reasonable response from a security perspective is don't use grok, then use it sandboxed. Trying to claim it's the users fault for not using password protection and IP restrictions is completely nonsensical. Same energy as telling someone their computer is more secure when it's off.
I challenge any agent to do worse than an intern with root access.
I once saw an engineer try to place the blame on his intern for taking down prod. I was sitting in a meeting with the VP of engineering and someone asked if it was ok for some to blame their intern for the SEV, and I remember the VP saying "I'll talk to $director_for_the_interns_mentor". Interns can't take down prod. An intern's mentor willingly watching an intern take down prod is the closest you can get.
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.
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.
But to write about it publicly, manifesting our ignorance and lack of critical thinking skill? It's an entirely different matter.