I have this nagging feeling with these kinds of agentic cloud products (and there seem to be so many these days): the promise is secure (as in isolated) workflows, but it’s unclear what that means when so many of the workflows themselves are privileged.
Or in other words: I often struggle to see the security value of a VM that I’m just going to load all of my sensitive credentials into anyways (since the agent needs them). The usability argument seems strong, but the security argument seems to hinge on me treating my local machine as a sort of bastion host, which I don’t think is generally true.
(This isn’t to denigrate the work itself: it seems very good. But it also seems like we’re still groping around a very weak definition of “security” for agentic workflows.)
I use codex in a VPS that I consider disposable in case it accidentally rm -rf /. The main goal for me is I don't want to babysit approvals but at the same time I don't want the AI running on the same computer I keep things like my irreplaceable photo albums etc. If it somehow breaks my VPS and takes it all down it doesn't matter I just reload from a backup.
I think traditional sandboxes are not going to be the correct abstraction. I’ve been messing around with building harnesses based on object capabilities and being able to limit exactly what an agent can access in what manner will be the way forward
With sandboxes you give your agent just what it needs and nothing more, not the whole suite of secrets living in your environment that could be exfiltrated
I have been building Odokai https://odok.ai to solve the problem you describe @woodrufw - visibility and ownership of the entire AI stack for customers.
I have this nagging feeling with these kinds of agentic cloud products (and there seem to be so many these days): the promise is secure (as in isolated) workflows, but it’s unclear what that means when so many of the workflows themselves are privileged.
Or in other words: I often struggle to see the security value of a VM that I’m just going to load all of my sensitive credentials into anyways (since the agent needs them). The usability argument seems strong, but the security argument seems to hinge on me treating my local machine as a sort of bastion host, which I don’t think is generally true.
(This isn’t to denigrate the work itself: it seems very good. But it also seems like we’re still groping around a very weak definition of “security” for agentic workflows.)
I use codex in a VPS that I consider disposable in case it accidentally rm -rf /. The main goal for me is I don't want to babysit approvals but at the same time I don't want the AI running on the same computer I keep things like my irreplaceable photo albums etc. If it somehow breaks my VPS and takes it all down it doesn't matter I just reload from a backup.
Docker Sandboxes provide secret injection using a network proxy outside the VM so the agent never has direct access to the secret: https://docs.docker.com/ai/sandboxes/security/
Note: I work at Docker
I think traditional sandboxes are not going to be the correct abstraction. I’ve been messing around with building harnesses based on object capabilities and being able to limit exactly what an agent can access in what manner will be the way forward
With sandboxes you give your agent just what it needs and nothing more, not the whole suite of secrets living in your environment that could be exfiltrated
Service accounts with proper privilege isolation should really be the norm here
[dead]
I have been building Odokai https://odok.ai to solve the problem you describe @woodrufw - visibility and ownership of the entire AI stack for customers.
[flagged]
[dead]