4 ms·

It's because containers share the kernel with the host. Generally it's just not considered a security boundary. (Note that containers have come a longer way in

It's because containers share the kernel with the host. Generally it's just not considered a security boundary. (Note that containers have come a longer way in the security side btw) So it's a mostly security thing.

debarshri 9mo ago
But in the context of agents. Does it matter?
- tptacek 9mo ago
  Depends. Probably not usually. I've thought about this a bunch and I think the serious "threat" here isn't the agent acting maliciously --- though agents will break out of non-hardened sandboxes! --- but rather them exposing some vulnerability that an actual human attacker exploits.
  - deleted 9mo ago
    [deleted]
  - buu700 9mo ago
    I'd also add that I just don't like the idea in principle that I should have to trust the agent not to act maliciously. If an agent can run rm -rf / in an extreme edge case, theoretically it could also execute a container escape. Maybe vanishingly unlikely in practice, but it costs me almost nothing to use a VM just in case. It's not impossible that certain models turn out to be poorly behaved, that attackers successfully execute indirect prompt injection via malicious tutorials targeting coding agents, or that some shadowy figure runs a plausibly deniable attack against me through an LLM API.
  - debarshri 9mo ago
    This is a genuine concern. But this sounds a bit independent of the execution environment. It could either be containers or VMs.
    - tptacek 9mo ago
      On a local machine, yeah, I think it's pretty situational. VMs are safer, but in risk management terms the win is sometimes not that significant. In a multitenant cloud environment, of course, totally different story.
      - DeborahEmeni_ 9mo ago
        I’ve been experimenting with this recently. Running services inside microVMs instead of plain containers makes the threat model easier to reason about, especially for multi-tenant or untrusted workloads. I’ve been trying it out on Northflank and the trade-offs become pretty obvious.
- aghilmort 9mo ago
  security matters if want to demarc where agents can play. running agent inside of strong VM is usually where starts container not enough for that full isolation only sees files you want it to etc
- binsquare 9mo ago
  Imo it's even more important in context of agents, if these agents are as good as it's going to get with as much access as we let them.
- starlust2 9mo ago
  One could theoretically use a prompt injection attack to exploit a privilege escalation vulnerability on the kernel.
ATechGuy 9mo ago
What about VMs? They offer strong isolation, as they don't share kernels, and have long been a foundational piece for multi-tenant computing. Then, why would we put an extra layer on top and rebrand it as an AI agent sandboxing solution? I'm genuinely curious what pushes everyone to build their own and launch here Is it one of those tarpit ideas: driven by own need and easy to build?

debarshri 9mo ago

But in the context of agents. Does it matter?

tptacek 9mo ago
Depends. Probably not usually. I've thought about this a bunch and I think the serious "threat" here isn't the agent acting maliciously --- though agents will break out of non-hardened sandboxes! --- but rather them exposing some vulnerability that an actual human attacker exploits.
- deleted 9mo ago
  [deleted]
- buu700 9mo ago
  I'd also add that I just don't like the idea in principle that I should have to trust the agent not to act maliciously. If an agent can run rm -rf / in an extreme edge case, theoretically it could also execute a container escape. Maybe vanishingly unlikely in practice, but it costs me almost nothing to use a VM just in case. It's not impossible that certain models turn out to be poorly behaved, that attackers successfully execute indirect prompt injection via malicious tutorials targeting coding agents, or that some shadowy figure runs a plausibly deniable attack against me through an LLM API.
- debarshri 9mo ago
  This is a genuine concern. But this sounds a bit independent of the execution environment. It could either be containers or VMs.
  - tptacek 9mo ago
    On a local machine, yeah, I think it's pretty situational. VMs are safer, but in risk management terms the win is sometimes not that significant. In a multitenant cloud environment, of course, totally different story.
    - DeborahEmeni_ 9mo ago
      I’ve been experimenting with this recently. Running services inside microVMs instead of plain containers makes the threat model easier to reason about, especially for multi-tenant or untrusted workloads. I’ve been trying it out on Northflank and the trade-offs become pretty obvious.
aghilmort 9mo ago
security matters if want to demarc where agents can play. running agent inside of strong VM is usually where starts container not enough for that full isolation only sees files you want it to etc
binsquare 9mo ago
Imo it's even more important in context of agents, if these agents are as good as it's going to get with as much access as we let them.
starlust2 9mo ago
One could theoretically use a prompt injection attack to exploit a privilege escalation vulnerability on the kernel.

ATechGuy 9mo ago

What about VMs? They offer strong isolation, as they don't share kernels, and have long been a foundational piece for multi-tenant computing. Then, why would we put an extra layer on top and rebrand it as an AI agent sandboxing solution? I'm genuinely curious what pushes everyone to build their own and launch here Is it one of those tarpit ideas: driven by own need and easy to build?