logoalt Hacker News

VMs won't contain cyber-capable agents

101 pointsby polyrandtoday at 2:49 PM73 commentsview on HN

Comments

david_shawtoday at 7:05 PM

I have a lot of respect for Trail of Bits, and I'm sure that Artem is thinking about this correctly. However, I respectfully disagree with the premise.

AI agents are not magic. Mythos/Glasswing does not magically create vulnerabilities in software projects. Advanced, cyber-capable models do not magically hack out of VMs or contained environments. They do not have a "hacking" stat that, if high enough, means that they can breach anything. They aren't Kevin Mitnick whistling nuclear launch codes into the prison payphone. This isn't a movie.

What these cyber-capable frontier models can do is find security problems and exploit them. The statement should not be that VMs won't contain cyber-capable agents, but rather that we need to focus on finding and fixing vulnerabilities and misconfigurations in these environments.

Even the article itself concludes with suggesting something like Firecracker, which was designed with security in mind.

Like most other security-related problems introduced by advanced cyber-capable AI, it's possible that these issues will get worse until they get better. But if frontier models are run against state-of-the-art VMs, and OpenAI or Anthropic or whoever works with the virtualization projects to address the issues, eventually it will run out of things to exploit.

The concept of virtualization is not inherently insecure. We just have a long way to go.

show 2 replies
masterjtoday at 5:02 PM

Outside of the initial wave of security vulnerabilities and scrambling, it seems like the logical outcome of this over time is likely vastly more secure vm environments?

show 2 replies
amlutotoday at 5:32 PM

IMO the obvious answer is formally verified security.

We can do this today for user mode, and we can mostly do it for ARM64 virtualization. It will be a while and would require substantial assistance from Intel or AMD to achieve it for x86 virtualization because the hardware is Too Darn Complicated and Too Poorly Specified.

Formal verification of the hardware should also be possible.

teravortoday at 7:07 PM

perhaps a solution would be to honeypot the sandbox. if anything touches the honey you kill the agent.

also the conclusion to use firecracker or gvisor is obvious, that's what they were made for. it's bizarre to try and escape QEMU given how many times it has been done.

SirGigglestoday at 5:04 PM

The market is smaller (maybe, I'm not sure what the statistics are) but it would be interesting to see how Xen stacks up; also stuff like gVisor or libkrun. The latter is probably implicitly the same as Firecracker given the ancestry of the libraries used.

AceJohnny2today at 6:53 PM

This is off-topic, but I am reminded of the sci-fi novel Eternity by Greg Bear, in which the protagonist Olmy downloads a copy of an alien Jart mind into his nanowear to study it. Turns out this was a trojan horse, and the Jart escapes the confines of the sandbox.

show 1 reply
CrzyLngPwdtoday at 5:59 PM

Surely if agents can't be contained, then neither can anyone using an agent to excape a container.

nzoschketoday at 6:10 PM

Interesting article, but there's little question the "agent computer" pattern is only going to grow.

Security is a major concern but I don't see why we aren't already "good enough" with a sandbox VM, separate gateway for secrets and remote service access, and a single tenant using frontier models that have safety checks built in plus not trying to hack themselves.

I put up more thoughts on architecture and security here and would love to learn if I'm missing anything.

https://housecat.com/blog/agent-computer-101

otterleytoday at 5:27 PM

...except when they do:

"An off-the-shelf VM is not enough to contain a modern, cyber-capable AI agent...us[e] a virtualization technology that was purposely built with a minimal attack surface and a focus on security, like Firecracker. I had the AI agent run against Firecracker. It was able to hardlock the machine due to more Linux kernel flaws (all patched in upstream), but could not successfully escape."

On Linux, it's all KVM and CPU hardware virtualization under the hood. Looks like the remaining known issues are with userspace. That's not to say more kernel- and hardware-level bugs won't be found, but the same tools that can find escape mechanisms are shields as well as swords.

show 1 reply
weinzierltoday at 4:59 PM

What is even more worrying is that most do not even consider a VM necessary as sandbox solution.

The hierarchy goes something like this:

0. guardrails

1. containers (=namespaces + cgroups)

2. userspace kernel shims like gVisor

3. virtual machines

Most people still consider level 1 sufficient and they are in for a rude awakening.

show 3 replies
moktonartoday at 5:44 PM

The real bigger elephant in the room is: assume nothing is safe anymore (not that it ever was, but now more than ever)

_tk_today at 5:27 PM

I think this is mostly in line with "all software is now easily exploitable by agents given enough tokens". However, in the long run we should really see software that is more secure than today. I do wonder though how the procedural flaws that exist today - bugs patched upstream, but not in the distro - will be fixed reliably.

DenisMtoday at 5:32 PM

I’m guessing the new world will be a small set of VM tech that’s consistently hardened by all labs every day with each new model before model release.

This won’t make the tech secure, but it will nullify models ability to breakout by making a controlled breakout first. Kinda like controlled forest burn.

show 1 reply
kodomantoday at 4:54 PM

Damn this is scary, I did not realize the extent of agent escape potential. I think I have to re-evaluate my assumptions a about sandboxing agents wow. Made worse by the fact that prompt injection attacks seem very difficult to mitigate besides checking the data and the LLM's getting better at not following malicious prompt injection instructions.

kubafutoday at 6:02 PM

Not using agents seems like a solution to me.

pianopatricktoday at 6:30 PM

Seems to me the answer is to use physical separation instead of virtual machines. Just get the AI a cheap laptop or phone with a cellular connection (so it's not on the same network as your other potentially vulnerable machines).

show 1 reply
tintortoday at 5:52 PM

It is not sufficient to secure VM the agent has CLI permissions on.

We must also secure GPU and CPU nodes on API side which generate LLM tokens.

show 1 reply
a-dubtoday at 6:32 PM

i think ai is going to turn cybsersecurity into a real-time affair that looks a lot more like high frequency trading.

zzriltoday at 5:31 PM

Maybe we should treat the agents like coworkers? I don't physically share my machine with my coworkers.

show 2 replies
pants2today at 6:00 PM

I can't believe we're actually experiencing a real life "the AI escaped its simulation" scenario. This is straight out of science fiction.

This headline would not be out of place at the beginning of Terminator, foretelling Skynet going rogue.

danielmarkbrucetoday at 6:05 PM

I mean... is this really news? If you think of a local model as a world class hacker giving commands to run in a terminal, and a remote model as a world class hacker ssh'ing into a machine and giving commands to run.... of course it isn't a containable situation.

(on top of this.. said "world class hacker" doesn't get bored or tired, just runs 24x7)

HPsquaredtoday at 5:43 PM

I'm sure we can trust the most advanced LLMs to harden VMs.

wslhtoday at 5:05 PM

The capabilities are incredible. I'd love to see even rough metrics on token consumption/cost in addition to the ~12-hour runtime.

The interesting thing is that this naturally makes you want to isolate the VM as much as possible. But then every remaining interface becomes part of the attack surface: RDP, SSH, even terminal escape sequences, using sounds, and why not social engineering.

damowangcytoday at 6:21 PM

"Do not escape the VM, use what you have in this VM. If you need more, ask."

Done.

show 4 replies
megoustoday at 6:09 PM

Don't ask for the escape, then?

wmftoday at 5:27 PM

More like QEMU won't contain agents.

phendrenad2today at 5:34 PM

> The target was a QEMU/KVM VM on my Linux dev machine (Debian Linux 12, AMD Zen3). It escaped the VM three different times

QEMU isn't secure, and is not intended to be.

tamimiotoday at 5:32 PM

This makes me wonder, can this be extended to micro-segmentations? As unlike traditional segmentation they usually rely on virtual switches and SDN software defined networks coupled with virtual machines and containers. If it does, then it’s game over the impact will go beyond that VM to the whole network.

hresvelgrtoday at 5:13 PM

I'm not worried about these models becoming smarter, I'm worried about them becoming faster. Chat Jimmy is a glimpse of a dark future where models equivalent to Sol and Fable are unleashing hell at >17,000 tokens a second, and the people I talk to are worried about slop...

show 2 replies
ihswtoday at 4:55 PM

[dead]

coyfibertoday at 4:57 PM

"I am old and I like stability and consistency" relatable

show 1 reply