A way to exclude sensitive files issue still open for OpenAI Codex
51–60 of 157 posts
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#52Earlier quoted context omitted.
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.
Often enough, when one of the agents prompts for running "sudo", and I reject it, it will do what looks very much like malicious exploration to figure out how to handle things anyway, including once hijacking a separate shell's pty where I did have a valid sudo session already in order to execute some commands.
We don't yet have the capability to make these models behave in a consistent, deterministic, or safe manner yet, so a first party solution isn't even necessarily that much better. Especially if it gives a false sense of security.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#53You 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…
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#54Bind mounts can work fine. Setting them up does require root though. Easiest would be if the harness offered to enable containment. Awkwardly, it would require root.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#55Earlier quoted context omitted.
Not sure I agree? It’s not like gitignore should be independent from git
The difference is that git is a traditional programming tool which executes deterministically. agents are not deterministic tools, they're not sandboxes or container runtimes or languages with capabilities models. They're a way to run arbitrary commands. It would be like saying that "xterm" should have a ".xtermnoexec" list of commands you can't run, or that VLC should have an option for actors it won't show. termina…
- Changing directories with cd.
- Setting or unsetting the values of SHELL, PATH, HISTFILE, ENV, or BASH_ENV.
- Specifying command names containing /.
- Importing function definitions from the shell environment at startup.
- Parsing the values of BASHOPTS and SHELLOPTS from the shell environment at startup.
... some other things mainly preventing you from escaping or disabling the restricted mode.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#56I 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 remo…
> 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...`
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#57Bind mounts can work fine. Setting them up does require root though. Easiest would be if the harness offered to enable containment. Awkwardly, it would require root.
In fact, it's possible to set up bind mounts without root on a modern Linux system, using a user namespace and a mount namespace.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#58Earlier quoted context omitted.
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
#59Earlier quoted context omitted.
Or just have a corporate contract that provides assurances. Though really I’m skeptical that much corporate info is secret for competitive or privacy reasons. Mostly it seems to be for liability / discovery reasons. Which are still legit of course, but ideas are a dime a dozen and every company has more than they know what to do with. It’s the resourcing and execution that are hard.
> Or just have a corporate contract that provides assurances. After the massive copyright infringements and recent "who care's about the law anyway" stance of corporate America, trusting this could be a grand mistake.
Just treat it like a contract worker. They may violate their NDA. That doesn’t mean you never use any for any purpose ever. It’s a risk that’s been managed since before computers.
Re: A way to exclude sensitive files issue still open for OpenAI Codex
#60You 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…
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.