Earlier quoted context omitted.
Docker Sandboxes is using microVMs, not containerization.
That's an implementation detail. They do that because less capable OSes don't have direct support for sandboxes.
No, that's not why.
Docker Sandboxes – Disposable, isolated sandboxes for AI agents
421–424 of 424 posts
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#422Earlier quoted context omitted.
The docs mention it can be bypassed for configured domains.
Yes, I read it. That means that it doesn’t work in those cases. Btw, as a developer it’s very easy to have something like that. It’s not as trivial as it seems at all. I encountered with similar problems all the time, with similar solutions (mainly for security theater reasons) in the past. There are websites which simply doesn’t work if you replace certificates, regardless of browser or CA for example.
Yes, I've worked with people who have run into issues with "security" solutions like ZScaler. I have tried it with some APIs (like GitHub) and it does work. Not to say it will work in your case.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#423Earlier quoted context omitted.
It only replaces the token in the HTTP header that is sent to the server. Whatever you wrote in your files isn't touched by the proxy.
It sends a request to requestb.in and reads the public log of the headers. There are ways.
But requestb.in is not api.github.com so the proxy wouldn't replace anything.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#424Earlier quoted context omitted.
Once you have a vm, the container provides next to no additional security benefits. It's just unnecessary overhead at that point.
That's not correct. Virtio devices have different security properties and many of them expose the host system to considerable risks. Using containerization on the host is one way to limit the latter. See e.g. https://github.com/libkrun/libkrun/#security-model for more details.
Well, I stand corrected! Thanks for the link