4 ms·

Can someone elaborate with whats wrong with having containers for sandbox?

binsquare 8mo ago
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 8mo ago
  But in the context of agents. Does it matter?
  - tptacek 8mo 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 8mo ago
      [deleted]
    - buu700 8mo 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 8mo ago
      This is a genuine concern. But this sounds a bit independent of the execution environment. It could either be containers or VMs.
      - tptacek 8mo 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_ 8mo 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 8mo 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 8mo 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 8mo ago
    One could theoretically use a prompt injection attack to exploit a privilege escalation vulnerability on the kernel.
- ATechGuy 8mo 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?
Ronsenshi 8mo ago
From what I read others say at some point on HN: - resources - security - setup speed? I suppose a lot depends on how and in what environment you're dealing with agents. Resources might be an issue on Mac if you have bunch of agents running different things, trying to execute code in different containers. But that's the issue of Mac and the way containers are running in a VM there. Security-wise there were concerns with prompt injection telling agent to execute certain steps to escape from container. Possible, but I'm not aware if there were actually cases of that.
vrn21 8mo ago
Luis wrote an excellent blog about it btw: https://www.luiscardoso.dev/blog/sandboxes-for-ai https://www.luiscardoso.dev/blog/sandboxes-for-ai

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 8mo ago
But in the context of agents. Does it matter?
- tptacek 8mo 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 8mo ago
    [deleted]
  - buu700 8mo 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 8mo ago
    This is a genuine concern. But this sounds a bit independent of the execution environment. It could either be containers or VMs.
    - tptacek 8mo 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_ 8mo 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 8mo 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 8mo 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 8mo ago
  One could theoretically use a prompt injection attack to exploit a privilege escalation vulnerability on the kernel.
ATechGuy 8mo 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?

Ronsenshi 8mo ago

From what I read others say at some point on HN: - resources - security - setup speed? I suppose a lot depends on how and in what environment you're dealing with agents. Resources might be an issue on Mac if you have bunch of agents running different things, trying to execute code in different containers. But that's the issue of Mac and the way containers are running in a VM there. Security-wise there were concerns with prompt injection telling agent to execute certain steps to escape from container. Possible, but I'm not aware if there were actually cases of that.

vrn21 8mo ago

Luis wrote an excellent blog about it btw: https://www.luiscardoso.dev/blog/sandboxes-for-ai https://www.luiscardoso.dev/blog/sandboxes-for-ai