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.
A way to exclude sensitive files issue still open for OpenAI Codex
21–30 of 157 posts
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#22Earlier quoted context omitted.
Just be aware that AI agents will explore alternate means of accessing said files: https://news.ycombinator.com/item?id=48348578
If you’re already running codex as a different user to limit its file permissions, why would you add it to the docker group?
A good but altogether separate note from the point I’m making: this lack of access is seen as an obstacle to overcome, and other means of access will be tried if available.
It’s a different mental model than a first party solution to “ignore” files.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#23You 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…
Just be aware that AI agents will explore alternate means of accessing said files: https://news.ycombinator.com/item?id=48348578
Yes. Any sane IT department would not allow external AI services, only local ones. It is just too easy for your company's data to end up on the wrong servers. If not through faulty file permissions, then through employees who simply post company ideas.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#24The 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).
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#25Do not store secrets in the repository in files, but inject them during runtime. Then the agents have no way to access them.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#26There should be a standard around .agentignore file similarly to what happens with .gitignore file. Of course this could still be workarounded by agent bash command tools, but at least basic operations like reading and so on should be checked and prevented.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#27I 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.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#28Earlier quoted context omitted.
Just be aware that AI agents will explore alternate means of accessing said files: https://news.ycombinator.com/item?id=48348578
If you’re already running codex as a different user to limit its file permissions, why would you add it to the docker group?
Lack of knowledge and the desire to have it run containers for things.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#29You 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…
Yes, this was solved decades ago. How do you stop a human from reading one of your files? chmod 600
> How do you stop a human from reading one of your files?
Call the police!
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#30I 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/drop