Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Is the trust concern for the agent running in any form on your machine? Like in a VM on your machine as well or do you mean on the host itself?

I have read about people giving an agent full access to their main system saying they have nothing of value. To me, that's a strange opinion to have with the distinction between what's private and what's secret.



I don't run agents directly on my desktop/laptop machine. I run them in VMs or containers (sometimes in containers on VMs). There have been too many credentials stealing exploits via prompt injection and the like for me to be willing to let an agent roam around on my personal system.

I've also started creating new github deploy keys for each repo in use on a VM, so the blast area for any given agent disaster is "a couple/few github repos and whatever credentials were needed for the agent/model".

I wouldn't let a coworker, even one I know pretty well, log into my personal account on my machines...why would I let an agent that can be tricked into uploading all my credentials to an attackers web server?

The agents have sandboxes, but those are loose. Not enforced by anything outside of the agent harness itself.


> The agents have sandboxes, but those are loose. Not enforced by anything outside of the agent harness itself.

You might want to check out Ant's open source srt [0], I use it to contain my local coding agents. It's strict by default and enforced at the OS layer.

[0] https://github.com/anthropic-experimental/sandbox-runtime


What benefit does running it locally have over parents solution of running it in a container in a VM?

I do the same: my agents run in a hardened VM on a hardened Linux machines in a separated network in my basement. The magic of ssh makes this setup transparent for me on my desktop. But extremely hard for my agent to do nasty things.


I'm working on a credential broker that would keep credentials vaulted and parcel out access on a per-grant basis. Is that something you'd find useful or is your setup comprehensive enough? We would be allowing people to draft access policies with natural language, I figured it would be useful for things like vercel, stripe access etc.


Not at all would i ever within the current technology constraints trust a "natural language model" to secure access to my own credentials, i will always keep it as completely isolated from anything at all i would consider 'risky' and pre-define before it begins what it could possibly access through a brand new VM with only the absolute minimal access to any git repo's and completely restrict to the extent that is allowable, it's ability to do anything outside of it's own playground. The playground is disposable, the potential for the LLM to access any of my own accounts and wreak havoc on the trust in my network is unacceptable under any rules....


fwiw, i built something simple like this into my harness thing (github.com/0gsd/enough). may not be complicated enough to do per application nowadays vs. needing a modularized outside solution, but it is certainly a good idea that seems to work!


Oh yeah, that sounds wise to me. Some people don't run the agents on a VM on their own machine and opt for a VPS somewhere. And I was wondering if privacy and security had anything to do with their decision.


Do you not find a dedicated UNIX user to be sufficient for the sake of protecting personal files, SSH keys, etc?


It's all fun and games until the model is smart enough to figure out privilege escalation, i.e. a lot of people don't realize Docker enabled on a regular user is enough for privilege escalation if you "follow the tutorials."


Agent that can apt-get is more useful.


When I was in university in 2009, the student union I was in had set up their Linux computers with a small program that one of the members wrote, that had the suid bit set and would exec apt-get install passing the arguments along.

This way, all members of the student union were able to install any software they wanted to on the student union computers without having to give out blanket root access to the members. Only a select few members had full root access.

There’s other ways to achieve the same too.

And you can do this exact same sort of thing for the user that your agent runs as too, without having to give it access to do everything that root can.


Giving users ability to use apt with root privileges is pretty much game over security wise. Full root is a malicious package away


The student union mainly kept the full root privileges restricted to a select few students to avoid accidental destruction rather than as a measure against maliciousness.

After you had been a member for a while and demonstrated that you mostly knew what you were doing, they’d give you full root access if you had some reason to want it that they agreed with.

And thanks to the dedicated suid program that exec’d into apt, wanting to install additional software was not a reason to be granted full root privileges since everyone could already install packages from the apt repositories this way without full root privileges.

Along with full root access came basically just a couple of simple rules, one of which was:

Do not abuse your root access to walk into other members home directories.

That rule was put in place after a previous member with root access had used the root privileges to copy the homework of another member into his own home directory without asking the other member for permission to see his work.

Aside from that one thing happening that one time, there hadn’t really been anyone doing anything malicious AFAIK. We were a rather small group of members in this student union, and it was a pretty chill and nice place. People came there to hang out, drink beer and tinker with electronics and computers.

There wasn’t much that root privileges could be abused for anyway. Regular members could already use all of the machines via graphical login at the desks, and remotely over ssh. Really the main two things anyone could have done maliciously would be to steal other people’s homework (like that one guy was kicked out for doing), or to steal credentials from others (no known cases of that happening there).

And if someone had started acting really maliciously, using the student union computers to attack the wider network, the university would have been on top of that real fast. The computer network of the student union was a subnet of the university network, and this university had a very competent crew of people watching over the university computer network as a whole.

A friend of mine once wondered how many computers were on the university computer network in total and did a port scan from one of the university computers (not from the student union computers). It did not take long from he started the port scan until university employees contacted him and gave him a stern talking to, and also told him the proper way find the answer to how many computers were on the university network.


I hope you see how this is less secure than a docker container?


This is what I do, VMs in proxmox. It works really well.


Have you seen smolvm (from smolmachines)?




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: