Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

31–40 of 157 posts

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

#31

Post by londons_explore »

cowsandmilk wrote: post #15
TheDong wrote: 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 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...

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

#32

Post by jofzar »

mbid wrote: 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…

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.

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

#34

Post by brookst »

londons_explore wrote: post #31
cowsandmilk wrote: post #15

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

But that means the process can’t use the key for network requests, right?

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

#35

Post by MattDamonSpace »

cowsandmilk wrote: post #15
TheDong wrote: 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.

Not sure I agree?

It’s not like gitignore should be independent from git

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

#36

Post by tomrod »

KHRZ wrote: post #18
wodenokoto wrote: post #11

Earlier quoted context omitted.

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!

How would it prevent an agent from writing a script that discovers the secret file? It's not magic.

It can't. As others pointed out, its the wrong layer to implement the security feature. The agent needs to operate in an isolated user / container.

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

#38

Post by tiew9Vii »

hoppp wrote: 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 secrets are in files, not env vars.

That way when using sandboxing the agent can never see the configs or secrets as outside the working directory.

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

#39

Post by mbid »

jofzar wrote: post #32
mbid wrote: 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…

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.

Yeah I should add a video to the README.

Have you tried running `rumpel codex foo123` in one of your repositories, asking it to commit something, then `rumpel merge foo123` to get the changes back to your local checkout? Use a different terminal for the merge command, or detach from the codex session with `ctrl-a d`. You can also look at the commit first with `rumpel review foo123`, or get a shell inside the agent environment via `rumpel enter foo123`.

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

#40

Post by brookst »

amelius wrote: post #23
lelandfe wrote: post #12

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.

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.

Post reply on HN