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 a new pattern for me, I'm curious what others are doing.
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.
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.
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.
Beyond that, I just keep advocating for more safe and secure approaches any opportunity I get.
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.
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.
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.
[0] https://pubs.aeaweb.org/doi/pdfplus/10.1257/0002828067772121...
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.
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 wonder what will happen after our benevolent prophets St.Sam and St.Dario will succeed in re-training humanity and break this collective expectation of program correctness. I guess they didn't even think about that.
sudo -u restricteduser myagent
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.
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.
A user account is a sandbox.
Edit: it’s about the attack surface
> cat /etc/passwd|wc -l
50You 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.
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.
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.
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.
That's scary. Really should run it under different user with carefully assigned permissions.
The real enforcement has to be done via methods that YOU can't easily bypass, or they will bypass (OS-level prohibitions, etc).
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.
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.
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.