Live data from Hacker News

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

github.com

41–50 of 157 posts

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

#41

Earlier quoted context omitted.

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.

I could imagine perhaps some system which rather than denying access might instead replace the key material from your .env key with "** redacted. This key material can be used via make, but can never be exfoltrated directly **" whenever that key is seen heading out towards the network...

OnePassword can do something like this where you put references to a path there instead of the key material, and then you wrap the invoke command with their CLI and it replaces them. So your local env file never has anything sensitive. A malicious agent could still exfiltrate if you give it access to debug tools on the running code though.

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

#42
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…

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.

I'm a fan of belt and suspenders.

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

#43
post #25

Do not store secrets in the repository in files, but inject them during runtime. Then the agents have no way to access them.

A lot of people have secrets/config files in the projects working directory but ignored by git i.e. `.env.local` So they're following best practice, not committing secrets but agents running locally can still see them even if sandboxing to the working directory. I've taken to storing configs using XDG_CONFIG_HOME and have the app auto resolve them by convention or take a cli arg to specify the config path. All secret…

Sounds like a good way to do it.

Makes me think of docker secret where the secrets are exposed as files and accessable only from inside the container.

If the development environment uses docker then thats a solution too I guess

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

#44
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…

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.

The Codex bug tracker is a great insight into how wide the knowledge gap seem to be between users. The issue where people ask them to add back /undo or whatever it is instead of just learning to use git, probably reached 100 comments at least by now. People seemingly don't really understand the computers they use on a daily basis, and refuse to learn too.

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

#45

Earlier quoted context omitted.

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.

Not sure I agree? It’s not like gitignore should be independent from git

.gitignore doesn't have the same security implications.

If you fail to prevent a private key from being added to your repository, you can reverse this and purge it from the blobs and reflog as if it never happened.

If you fail to prevent OpenAI from ingesting a private key, you have created a security incident.

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

#46
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…

Just be aware that AI agents will explore alternate means of accessing said files: https://news.ycombinator.com/item?id=48348578

Yes. I found this quickly after wrapping codex in a launcher that uses bubblewrap to exclude certain files and directories based on a config file at the project root. My best solution so far is to also include instructions for the agent that explain that it is not allowed to see certain files, and that their inaccessibility is not an error, and that it must not attempt to access them through other means (e.g. via git history, etc.).

This has been a major improvement, but it's not foolproof.

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

#47
post #40
post #23

Earlier quoted context omitted.

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.

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.

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

#48
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.

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

#49

Earlier quoted context omitted.

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.

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.

terminals run shells which run commands, it's not really deeply aware of what commands your shell ultimately run, and it's not in xterm's job to setup a sandbox and strip out executables.

VLC displays pixels, it's not up to it to figure out if those pixels are a certain actor.

codex pipes text and tool calls back and forth between OpenAI's servers, and it barely understands what that text and those tool calls are, and especially if a given tool touched a file. If you want VLC to not display an actor, you need to add a layer on top of VLC to stop it displaying a list of movies. If you want codex to not display a file's contents, you need a layer on top of codex to prevent it going near that file.

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

#50
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…

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.

Post reply on HN