The only thing that caught people's attention was that it was applied to "AI Agents".
> At Greptile, we run our agent process in a locked-down rootless podman container so that we have kernel guarantees that it sees only things it’s supposed to.
This sounds like a runc container because they've not said otherwise. runc has a long history with filesystem exploits based on leaked file descriptors and `openat` without NO_FOLLOW.
The agent ecosystem seems to have already settled on VMs or gVisor[2] being table-stakes. We use the latter.
1. https://github.com/opencontainers/runc/security/advisories/G...
It looks like the author just discovered the kernel and syscalls and is sharing it - but, it's not exactly new or rocket science.
The author probably should use the existing sandbox libraries to sandbox their code - and that has nothing to with AI Agents actually, any process will benefit from sandboxing, that it runs on LLM replies or not.
"Early civilizations had no concept of zero..."
- Access to files in the repositorie(s)
- Access to the patch/diff being reviewed
- Ability to perform text/semantic search across the codebase
That doesn’t require running the agent inside a container on a system with sensitive data. Exposing an API to the agent that specifically give it access to the above data, avoiding the risk altogether.
If it's really important that the agent is able to use a shell, why not use something like codespaces and run it in there?
- Access to repo history
- Access to CI/CD logs
- Access to bug/issue tracking
My point is whitelisting is better than blacklisting.
When a front end need access to a bunch of things in a database. We usually provide exactly what's needed through an API, we don't let it run SQL queries on the database and attempt to filter / sandbox the SQL queries.
CuriouslyC•4mo ago
dakshgupta•4mo ago
arjvik•4mo ago
lomase•4mo ago
kjok•4mo ago
CuriouslyC•4mo ago
kketch•4mo ago
The real issue is that containers are being used as a security boundary while it’s well known they are not. Containers aren't a sufficient isolation mechanism for multi-tenant / untrusted workloads.
Using them to run your code review agent again puts your customers source code at risk of theft, unless you are using an actual secure sandbox mechanism to protect your customers data which from reading the article does not seem to be the case.