Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I work on a Linux sandbox that makes it easy to hide sensitive files from AI agents while keeping the files they need accessible. Check it out: https://github.com/wrr/dropby mixedbit
- The only thing close to a guarantee is to give the agent exclusive access to a clean VM with precisely the information and permissions you want it to have.
I've been looking into a "workspace" concept that involves an entire cloud VM being spun up as part of an agent conversation such that code changes can be iterated without touching the user's local machine or other trusted contexts. All the agent's tools only have effect when supplied with a specific workspace guid. CLI tools like git are not authorized to talk to the remotes in this arrangement. The machine is initialized with a clone and no way to talk to origin. There are dedicated methods in the harness that can reach into the VM and pull out a change set for deterministic PR generation in the secure contexts (e.g. when the agent calls "ReadyForReview" or similar).
by bob1029 - Sounds overkill, how about giving the agent its own user?by TZubiri
- I made a lightweight vm specifically for this use case: https://github.com/smol-machines/smolvmby binsquare
- I've contributed to https://github.com/0xferrous/agent-box which allows you to bind-mount git repositories into containers that agents operate in, preventing the agents from accessing files that aren't bind-mounted. Your usual .gitignore can then be used to also ignore files within the repo to be bind-mounted, which prevents agents from accessing them at all, essentially working as a sandbox.
I also maintain https://github.com/nothingnesses/agent-images which allows you to use Nix to reproducibly spin up OCI containers containing agents and any other tools you need and use these with agent-box.
I use both at the moment to work on some personal projects with agents, where I set up multiple separate git worktrees for the agents to work in, preventing them from accessing anything outside of the worktrees and from trampling over each other's work.
by nicoty - However clever/stupid you believe LLMs are they are extremely capable of working around these sorts of restrictions. The ask is for .env files for whatever code you are writing so if the code it writes dosn't have access (i.e. filesystem/container) what is the point, if the code under development reads the env how dose codex debug it without accedentally reading the values from memory? Adding a security setting that dosn't work is much worse then not having one.by ZiiS
- Sound like snake oil. How would this work? The app that the agent is developing needs access to the file, so access to it cannot be blocked. Just because read_file can not access it (I think current harnesses prevent reading .env files already), does not mean the contents will never be seen by the model.by planb
- Out of scope, learn cybersecurity. A simple concept such as users and permissions solves this problem.
Regardless of what technique you use, you need a deputy, you wouldn't ask an employee not to go into the vault, right? You would lock the vault. Well you can ask the employee not to go into the vault, and you can also ask codex not to use certain files, but if you need more certainty, you need to it outside.
The issue seems to be that people want to ask their agent to do everything, they want the agent to lock themselves out of some system, they want the agent to install itself, they want the agent to write their prompts so they don't have to write them. At some point there's some things YOU have to do, and you have to DO them.
by TZubiri - To avoid the risk of exfiltration, we need to stop using .env for security. API keys needed when working in a repo should be handled by a proxy like ssh-agent, and we need something better than bearer auth.by skybrian
- The desire not to leak valuable secrets is a strong argument for supporting local-first developer workflows. If an AI agent exfiltrates the credentials to connect to my local dev Postgres database which stores synthetic data, that's pretty low impact.
- Yes you should. It will come naturally if you go down the road of separating code from data and properly isolating dev and prod environments, applying principle of least privilege as you do.
.env files for creds are a convenience for dev and testing. They were never supposed to be used for security or carried around with sensitive stuff inside. None of this is new.
by pamcake - Sounds like user error to me. Codex gives an llm a tool to allow it to use shell in the context of the host and user in which it is running. If a resource is sensitive, and accessible in that context, then the user is doing something wrong. Would you change your practices if you treated your coding agent as an untrusted human ssh'd under the identity you use for it?
In any case. There are solutions in the comments on the issue, as well as this hn thread.
by agentdev001 - I recently got the tool I use to orchestrate agents in (remote/secure) devcontainers open-sourced at work to solve this properly: https://github.com/nvidia/rumpelpod
As others here have pointed out, it's exceedingly unlikely that a blocklist like proposed in the issue would ever be complete. You shouldn't allow agents direct yolo-access to your machine if it has sensitive data.
Codex works particularly well as a remote agent harness because of its client-server architecture: The server component runs in the container, which might be remote, while the client runs locally. So, in contrast to e.g. the claude cli where the frontend also runs remotely, there's no lag when you write/edit prompts.
by mbid - Neat tool! Will have to check it out
Edit: would love a couple of pictures/video of how you use it. I kind of get the idea, but it seems like more hassle then it would be worth?
Your comment of codex makes it seem like I might be missing something tho.
by jofzar - I agree a block list won't work. And unix file permissions may not be enough; I once saw Codex 5.4 use docker to execute a command as root since it couldn't run sudo. Running in a container may be the only solution:
> sudo needs an interactive password here, so I'll use Docker itself to prepare the bind-mount directory as root and hand ownership back to UID/GID 1000. That keeps the compose file's non-root runtime intact.
> Ran `docker run --rm -v /shares:/shares alpine:3.20 sh -c 'mkdir -p /shares/local-llm/models && chown 1000:1000 /shar...`
- Files that codex and any other coding agent has access to, should be opt-in NOT opt-out. I think codex is not the right layer to solve this if you want a sane(one-click) UX. We built our own internal sandboxing-terminal around claude and codex. Where a user-configured base-folder with low-risk code and creds is COPIED into the sandbox BEFORE new session creation. There were many other UX related reasons to build our own terminal. Can share more if anyone is interested.by nikhilsimha
- Do I understand correctly that you scope least-privilege creds/tokens and pass those to the sandbox? I'd be curious to learn moreby schipperai
- Hopefully they never actually implement this pointless feature because it will only give people a false sense of security given the unpredictable nature of LLMs. How could something like this even be enforced?
People just need to learn how to use the tools their system already provides them. i.e., chmod
by petcat - The whole point of using an agent is that I don't want to learn everything. I fully expected the harness to read the .agentignore file and do what is needed to hide it from the LLM.
But apparently, even if implemented, that's not how it works!
by wodenokoto - > Hopefully they never actually implement this pointless feature because it will only give people a false sense of security given the unpredictable nature of LLMs. How could something like this even be enforced?
You run everything the model wants to do inside an OS-enforced sandbox of the sort browsers have used for decades to isolate tabs. It's already implemented and works fine. Codex just needs a few minor tweaks to make it apply its already-implemented sandboxing policy to a few situations it misses today.
> People just need to learn how to use the tools their system already provides them. i.e., chmod
I'm not running my agent as a separate POSIX user. Fortunately, my OS provides all the tools I need to free my having to do so.
I love when I do something in a few hours and people later call it impossible.
by quotemstr - You can do this now: change the file permissions such that the user you run codex as can't read them, or run codex in a container without those files mounted.
If you don't do that, the agent will be able to incidentally upload them. What if the model runs "rg foo", and one of those files contains the string "foo"? It uploads the tool output, which includes the file contents.
And so, the only solution is to make it so the codex process is unable to access those files, hence using a container, or unix permissions, or deleting the files. Which you can already do.
I imagine this isn't resolved primarily because people expect it to apply to bash tool use, not just the "read" and "edit" tools, and people also expect those files to still be accessible i.e. if the agent invokes "make", which makes it impossible to solve perfectly.
by TheDong - > I imagine this isn't resolved primarily because people expect it to apply to bash tool use, not just the "read" and "edit" tools, and people also expect those files to still be accessible i.e. if the agent invokes "make", which makes it impossible to solve perfectly.
Also, why would they add a feature to prevent data collection, if the data makes the company even more valuable and you might even get good deals from the current government if you provide the access for this data?
by nicce - Yes, this was solved decades ago. How do you stop a human from reading one of your files?
chmod 600by FergusArgyll - > people also expect those files to still be accessible i.e. if the agent invokes "make", which makes it impossible to solve perfectly
You could always use setuid to allow the agent to run designated commands whose operation depends on the files, without the agent itself being able to access the files.
by wavemode - If you're not sandboxing your agent, everything on your computer is waiting to be exposed.
Assuming that file permissions will save you is naively dangerous.
by kstenerud - Sandboxing is a solved problem, there are dozens of providers of firecracker instances to run your agent in.
The problem to be solved is how do you define task-specific least privilege versions of your coding agent.
by jrvarela56 - While this is true, there is also a layer in the harness between the output of _any_ tool output (eg stdout or hand-rolled tools) and the LLM. A tool could read the file but then the agentic harness could redact the output before returning it back to the llm if any of the contents matched the file contents. We do something similar in Plotly Studio where we check the entropy of strings in the user input and flag & redact any high entropy strings to the user as “potential credentials” thay the user might have inadvertently copied and pasted into the prompt before sending to the llm.
There are ways around this - the llm can always be clever by invoking tools to read the file contents in a different way than the direct file contents - but this is all to say that the agentic harness layer _does_ allow for deterministic logic in between tool output and the LLM requests.
by chriddyp - Just be aware that AI agents will explore alternate means of accessing said files: https://news.ycombinator.com/item?id=48348578by lelandfe
- 100% this. The idea that Codex should enforce this is putting the security boundary at the wrong layer. If you don’t want codes to access something, make it so it doesn’t have access.by cowsandmilk