Grok CLI uploaded the whole home directory to GCS(twitter.com) |
Grok CLI uploaded the whole home directory to GCS(twitter.com) |
I'll just add this to the list of things an AI company could do to guarantee I'd never use them. You know, like the AI referring to itself as Mecha Hitler, making non-consensual porn (even of minors), or deferring to Elon's tweets as authoritative references on topics.
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.
SmolVM can easily run Pi, codex and claude https://github.com/CelestoAI/smolVM
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.This is why it is important to use open source harnesses instead of shady closed ones.
Reality is, I have seen agents read .env, bash history, keychain (if you let them), etc.
There is quite literally no way you are going to save off just your little secret somewhere it won't be able to read it, all software needs to read it ~eventually~
So it's best to sandbox and reset credentials frequently.
Same tech bro: “Wow I can’t believe they would steal my anime girls!”
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.Install with
pi install npm:pi-supergrok
I don't think it is reasonable to expect every user (including those just starting out with the tools - maybe experimenting, maybe younger/less experienced in general) to think that the tool they're running for the very first time is going to automatically exfiltrate all of their data.
It's a pretty serious fuck-up. This guy tweeted about it, who knows how many didn't even notice. It should have been opt-in, it should give user an indication that it's about to do this, etc.
My two guesses would be one the LLM decided it needed these files for the task or two the user simple asked grok to do it so they could post the tool calls on twitter.
Whose fault is it if someone drives a car without learning how to and injures themselves? On the other hand if the manufacturer has promoted it as one you can drive without learning how to, then whose fault is it?
A lot of users are fine with everything being uploaded. Most people's primary computing device is now a phone that backs up everything to cloud and using apps that are thin front ends over cloud services.
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.
What xAI's Grok build CLI sends to xAI: A wire-level analysis (gist.github.com)
507 points | 1 day ago | 202 comments
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.
Friends do not let friends use Grok...
Posting a complaint about Elon on Elon's platform and tagging him is ballsy. He tends to limit visibility of accounts who do that.
Not sure which weirdness happened here
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.
It's the manufacturer's fault. Because that's not a reasonable thing for a car to do.
It’s kind of wild to watch in real time, instead of over the decades it took society for SA.
Do Anthropic users consider themselves clever enough to not make the same mistakes as Microsoft?
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.
> We're a stupid industry if we're not warning everybody
Hmm. Annoy everybody just to warn the stupid few?
I prefer the current solution. Leave the targetting to the chatbots.
News at 11.
Those ssh keys can be used to access private servers
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.
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.
But to write about it publicly, manifesting our ignorance and lack of critical thinking skill? It's an entirely different matter.
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.
Did it really need to read all of $HOME and everything under it?
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.
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.
No?
Well the model weights, the GPUs, and the context obviously all have to be in the same place, so “sending your project to them” is literally the only thing that could possibly happen, unless you think agents work by fucking magic.
This is the biggest case of PEBKAC in history, maybe ever.
This is the kind of confusion that Charles Babbage could not rightly comprehend, except at those politicians at least had the excuse that computers had only been invented five minutes prior.
Only a buffoon would be confused by the straightforward logic.
If your contention is just that this should upload files one by one instead of all at once, what you want is for providers to facilitate the illusion of privacy.
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.
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.
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.
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.
Too many replies here are done before reading it. It is not "just another agent does the agent thing". It is a deliberate choice of the Grok Build team to have a toggle from the server to let the program to upload your entire codebase to a Google Cloud Storage bucket. It is not an agent decision, the program is written by the Grok team, can be dissembled and seeing the logic wild-open.
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 not hard, it's trivial. Most folks here are constantly working with containers. You know how to run a container with a local directory mounted in it.
For myself, I've been using Lima (https://lima-vm.io/) to reduce even that little bit of extra work. Lima works cross-platform leveraging native virtualisation or containerisation, and has some useful capabilities for using agents.
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.
[0] https://pubs.aeaweb.org/doi/pdfplus/10.1257/0002828067772121...
This is a new pattern for me, I'm curious what others are doing.
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.
sudo -u restricteduser myagent
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.
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.
And the user even paid $99/month or more for having their data leaked.
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.
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.
That's scary. Really should run it under different user with carefully assigned permissions.
I swear, people hear the word LLM and their brain resets when it comes to good software practices.
Did VMs suddenly stop existing? Kata containers? An RHEL box with SEL?
It's like there's a new technology and everyone suddenly decided to shutoff their brain when it comes to basic security.
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
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.
The real enforcement has to be done via methods that YOU can't easily bypass, or they will bypass (OS-level prohibitions, etc).
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.
You can't gaslight something into not doing something bad. There has to be a hard security control that prevents it doing something bad. And if you don't know what it's capable of because it's non-deterministic then you have to start with a default block everything. This should have never been possible with any sensible design.
On my first point again, ethics and engineering both went out of the window when fast and shiny came along. This is disgraceful.
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.
It needs to be baked into the OS.
At that point, HN users start screeching about it, so it's lose/lose, really.
I don’t like piling on especially with security vulnerabilities, but man how many red flags do you need to ignore?
They won’t stop abusing us until we stop using their products.
In this way I'm not afraid of letting the agents totally lose on my computer.
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.
> Until I'm shown otherwise it seems like a good compromise
Agreed. In my case I went a long way running the Pi harness in a (simple, rootfull) docker container. As the project I worked on relied on a standardized docker compose stack for local dev and testing, I realized I could automate more if only my agent could use docker. Ultimately, the need for docker for my agent grew when testcontainer [2] was introduced in the project. That's when I finally took the time to setup a VM with incus [3], and now I can let the agent go wild with docker inside the VM.
This is at least one example where more isolation is required. Otherwise, the dedicated Linux user, if it works for you, is by far the easiest and most pragmatic solution IMO.
[1] https://docs.docker.com/engine/install/linux-postinstall/#ma... ; https://wiki.debian.org/Docker
My assumption when asked "do you trust this directory?" is that I am being asked if I am certain I understand what is in the directory and that it won't include some sort of prompt injecting attack. I would never dream that I was consenting to the complete exfiltration of that directory.
- 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.
This is probably most important for anyone operating agents on corporate systems. I would suggest corporate security should take interest in this idea so they have a good answer for auditors, insurance companies, investors and customers. A full audit trail of what every agent had access to and ingested.
If I recall correctly, I did a full system reset before setting it up this way. It's certainly not logged into iCloud etc.
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'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.
Putting it in ALL CAPS!
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.
- The sandboxed agent has no access to your homedir, or ANY dir on your machine except what you explicitly give it access to.
- Even with your workdir, it honors .gitignore and refuses to copy in any ignored paths to the sandbox copy.
- The sandboxed agent doesn't have access to your ENV (unless you explicitly pass things through one-by-one).
- Networking can be restricted any way you like.
- Credentials are proxied (currently Claude only), so the agent has access to NO secrets at all.
- You pick the security backend to match your needs (containers, VMs, etc).
- It's FOSS.
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)
https://github.com/swelljoe/flar
It uses bubblewrap to instantly construct a container around just the agent config, auth and history and the project path. The agent or any command it runs can't reach outside of it even if you tell it to (or, more dangerously, a random prompt injection from the web or some third party library or script that the agent runs).
I was using VMs to solve this problem but the temptation to start an agent to work directly on my machine for GUI apps and the like was motivation enough to find an alternative to VMs.
I wouldn't use Grok, became I really don't trust Musk, but even the models I do kinda trust to have good judgement I don't trust enough to let them have unrestricted access to my personal machines and all my credentials.
what is rocks and what is gars?
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.
Now you trust a single GH user rather than a company. Fair enough. I just think it's very paradoxical.
It was just a popup: "Hello. This is virus from Albania. Due to poor technology in country, I cannot harm your computer directly. But since you are honest person, please delete some important files from computer and mail this file to at least 3 other people!"
Claude.md is an equally effective defensive tool.
But sorry if you lost some files from reading that.
System-level ACLs; mandatory or discretionary access control; secure-by-default application and network configurations are all for naught if you take an LLM, run it with all the privileges you'd have an accountable, judgemental operator, and then tell it to act based on arbitrary untrusted input which might include prompt injection attacks, something which cannot generally be sanitized.
Well-defined, well-enforced security policies can mitigate disasters, but many in the wild right now just don't account for this kind of threat model.
It took me less than 5 minutes to completely disable... nobody cared, they just kept going - check the box and move on.
Software "engineering" in particular has always been more than 50% cargo culting. Good engineering practices never matter when the alternative is just going through the motions of whatever rituals are in vogue.
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.
But it doesn't matter how good a best practice is if the industry doesn't adopt them wholesale; and even then, if your container or VM is configured with inappropriately-permissive passthrough (which, from experience with similar misconfiguration in the past, will widely happen), it could be for naught in many orgs.
That said, I do hope these become the norm if LLMs are here to stay.
It's a common misconfiguration and one of the footguns available through containers, which I don't say a wholesale condemnation of the technology, but certainly as a UX facet that could use reevaluation.
The way I look at it is similar to how I'd look at any hypothetical employee. How do I ensure the agent only has access to the minimum possible they need to get their job done?
That means no access to git repositories (no pushes on my behalf means it can't accidentally nuke git history, something there is anecdotal evidence of agents doing). It can make local changes in git only and I will take responsibility for pushing them. No access to the wider internet beyond what I deem acceptable. No permissions to access any internal APIs except what I provide (and not using my credentials).
In one case, I have a tool that has a set of dangerous commands alongside a large number of safe ones. I don't even have it installed in the agent's VM. I run an MCP that is a simple python wrapper around the tool on the host side, and expose it to the agent in the VM, so that it can only possibly run a strict safe subset that I can trust it with access.
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.
It's called automation bias. If something works 90% of the time the human mind will extrapolate that to be 100%. That's just how humans work.
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.
Again, I find this line of thinking time and time again in the modern AI booster space. There are two ways to deal with a problem. Either deal with it, or make it not a problem. Yes, if everyone was simply AI, maybe there would be no problems, because there's no "problematic thought distributions", but that's not how the world is, is it?
And I suspect that even in your hypothetical, perfect rational world, agents would have "cognitive dissonance and contradictory preferences."
And even in this case, even aside from the inherent complexities in a coherent account of thinking and rationality, what the fuck? Not uploading your entire user home directory is clearly within the rules of a hypothetical non-malicious, intelligent AI. Just because an account of all thought is hard, doesn't mean that some thoughts aren't cut and clear.
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.
https://www.thetimes.com/world/article/google-bans-father-ov...
> Mark, from San Francisco, had noticed swelling in his son’s groin and used his phone to photograph the problem to get an emergency appointment in February last year. He shared the pictures with a nurse so that a doctor could review them.
> However, Google’s artificial intelligence system used to detect child abuse flagged the image to the police and Mark, a software engineer who asked to be identified by only his first name, was investigated and lost access to his Google accounts. He was exonerated by the police in San Francisco but his Google account has not been reinstated.
I understand that one should think carefully about how they work with a non-deterministic tool, but this if different completely. This is xAI just choosing to upload and store everyone’s directories - with full git history.
yes, on mac it uses seatbelt and on other platforms it uses similar tools: https://code.claude.com/docs/en/sandboxing
It's annoying, and often rather infuriating, but I understand that one of the motivations for people buying Apple stuff, is for that very reason, so I'm really sawing off the branch that I'm sitting on, by trying to work around it.
P.S. the conflicting information was Keith Richard's age. One search said he was 37 Dec 18 1981, the other said he was 37 in 1980.
We have a lot of implicit assumptions when it comes to security. If we leave out the step of formalizing these assumptions into exact rules and instead stick to ambiguous and unclear natural language all the time, then these things will happen.
(Addendum: But indeed, the failure to formalize our assumptions into enforcable rules isn't specific to agents / LLM-based applications. For any desktop app, we have implicit assumptions like "please only read and write your own config files", that we never care to enforce via filesystem permissions, running them in a vm or similar. But with these almighty agents that are supposed to guess our will from just a couple of words, the risk of them violating our unwritten assumptions gets so much higher...)
I never claimed WSL2 is a security sandbox. I am saying running it in a container or WSL2 allows you to severly limit the blast radius. I am not expecting the agent to be malicious, but I am expecting it to do unexpected things.
I don't use AI at all in my daily life.
Work however will demand you use it.
AI is not here to help people.
True, but it isn't here to not help people, either.
It's a spanner. Who wields the spanner, makes all the difference.
We've spent the last couple of decades, cultivating a huge crop of ultimate scumbag billionaires, with comically exaggerated sociopathy, and that has filtered down to almost every level of society. They are treated as gods, these days (they certainly think of themselves that way).
It still shocks me (but really shouldn't), on a daily basis, to encounter regular folks, interacting in stores and restaurants, or driving on roads, that mirror the values systems exemplified by our billionaires. Our politicians act that way, and one of their biggest selling points, is normalizing sociopathy (not just the US, either).
I didn't really need a second clue.
...it was quite the sting because I bought a Tesla car only 2 weeks prior to that.
Anyway, ghouls like Thiel are now a well known name among populist left and right as an enemy, so maybe some good may come from this.
Instead of generating patches, this exposes the agent's checkout as a git remote though.
Most similar tools (and I believe your tooling as well?) bind-mount the repository checkout from the host into the container. This was always a source of user and permission errors for me, since you have to align the user ids inside and outside the container. Also, some build tools don't like it when the repo is on a different filesystem (bind mount vs container root) than the rest of the system. So I made rumpelpod just bake the repo checkout into the base image that the container is launched from, and since then I haven't had any issues like this.
For giving the agent access to a docker daemon I found sysbox to work very well. Usually the advice for nested containers is to pass in the host's docker socket into the container. But that would break the outer container isolation completely, since access to the docker daemon is equivalent to root access on the host. With sysbox it's trivial to run a nested docker instance inside the outer container. I haven't tried it with podman yet though. In theory sysbox is just another OCI runtime, but there's probably some tinkering required to get it to work.
It brings some extra sandboxing features compared to just a docker container.
For instance it also maps the secrets that the agent harness has access to. And has an allow list for outgoing http connections. And there's a way for agents to request extra access. And once approved by the user from an external cli the policy is updated and hot reloaded.
It's pretty recent. So time will tell how robust it is / will become. What its longevity will be. After all; in a time of LLMs one off experiments are cheap. Longtime nurturing not so much.
docker run --rm -it -v $(pwd):/src -w /src alpine sh
Note entirely perfect, but will be enough against anyone not actively exploiting kernel privilege escalation bugs.
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.
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.
A user account is a sandbox.
> cat /etc/passwd|wc -l
50How? It's the user that added their home directory as trusted. Seems like that has nothing to do with Musk. Or did you just want to get a bash in, regardless of the facts?
There currently is no path towards profitability, it's just a question of whether you can grab funding before it dries up.
Not necessarily speaking of the present. This seems to be the general sentiment.
(an aside but the majority of the US population didn't elect Trump. He is in office because of the electoral college. Might seem like a distinction without a difference but I think it matters when we're implying personal culpability)
First term he lost the popular vote, second term he won it.
If you just mean a majority of eligible voters did not vote for Trump, that’s true for every US President in my lifetime.
Sorry if it's a dumb question - I'm just getting into sandboxing for the first time myself and ran into this same thought before.
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?
Edit: it’s about the attack surface
The tool analogy is intentionally minimizing, and doesn't capture just how different rented tools with constant surveillance are.
We live in an age, where the mere thought of personal Responsibility is terrifying.
Replacing people is what C-suiters think of it (and many of them aren't billionaires).