Live data from Hacker News

A way to exclude sensitive files issue still open for OpenAI Codex

github.com

51–60 of 157 posts

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#52

Earlier 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.

Weirdly, the existing first party solutions around denying commands don't seem to help here.

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

#53
post #4

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…

[dead]

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#54
post #37

Bind 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

#55
post #49

Earlier 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…

bash actually has a "restricted" mode which is sort of like that. In restricted mode, the following are disallowed:

- 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

#56
post #27

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 remo…

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...`

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#57
post #54
post #37

Bind 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.

podman is my favorite tool for this.

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#58
post #23

Earlier 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.

Yet many use public github, and human developers accidently push secrets and other "not for public" files all the time.

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#59
post #47
post #40

Earlier 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.

It’s a risk. But odds are the upsides from the legal settlements would far outweigh the losses from your super secret memos about q3 budget planning being trained on.

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

#60
post #4

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…

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.

It seems insane to me that so many people are OK with this. Why is it necessary for an agent to upload every bit of data it sees to OpenAI at all? Particularly if my agents can’t remember anything beyond a single session, why should the data exist permanently anywhere but in its original location?
Post reply on HN