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

91–100 of 157 posts

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

#91

Post by bob1029 »

TZubiri wrote: post #70
bob1029 wrote: post #24

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

Sounds overkill, how about giving the agent its own user?

It's really not overkill if you have good tools to work with. Hyper-V is quite capable of providing ephemeral workspaces on timescales measured in minutes. Especially with nested virtualization. One big machine with fast local disks can provide very short cold start times for a golden image stored on the same.

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

#92

Post by valleyer »

sheremetyev wrote: post #79
jrvarela56 wrote: post #50

Earlier quoted context omitted.

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.

I'm running Codex/Claude in native macOS sandbox with access just to the project folder (plus read-only access to Git repo), and expand to other folders if necessary - https://github.com/sheremetyev/sandfence

Codex (at least) already imposes the macOS sandbox on the shell commands it runs. If it wants to run something without sandbox imposition, the harness makes me approve it manually.

Is the difference with your script mostly that you choose to impose a stricter sandbox profile (and not allow any user-approved exceptions at runtime)?

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

#93

Post by tmp10423288442 »

jxf wrote: post #45
MattDamonSpace wrote: post #35

Earlier quoted context omitted.

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.

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

Only if you’re absolutely sure that it’s never been pushed to a public repository. I would treat a push of a private key to GitHub as a much higher emergency than it being sent to OpenAI (or even being accidentally used in a Google search), since there are bots that actively scan GitHub for private keys, such that your private key might be found within a few minutes of push.

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

#94

Post by wonnage »

embedding-shape wrote: post #44
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.

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.

I mean based on all the "coding is solved" hype that's what these companies are aiming for

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

#95

Post by cataphract »

atomicnumber3 wrote: post #72
embedding-shape wrote: post #44

Earlier quoted context omitted.

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.

We managed to generate probably-correct code, which can then be probably-corrected recursively to get to something that runs (usually). This made everyone scream and lose their minds saying that code is finished, people think they don't need a technical cofounder anymore, think they don't need engineers anymore, etc. Then they're, at varying speeds, finding out they're wrong. It seems oddly circular to me that the _e…

That is not a fault that's specific to engineers. Lots of smart lawyers think they can learn basically anything over a weekend of hard study. It's probably a blind spot of intelligent people.

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

#96

Post by Sanzig »

binsquare wrote: post #78
bob1029 wrote: post #24

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

I made a lightweight vm specifically for this use case: https://github.com/smol-machines/smolvm

Thanks so much for building smolvm! I liked it so much that I vibe coded a little bash wrapper around it to handle creating ephemeral VMs for Pi: https://github.com/neuroblaze/smol-pi

Consists of two scripts, one to build an OCI image (customizable by editing the Dockerfile that comes with it) and another to handle smolvm invocation. The invocation script mounts the current working directory under /workspace in the VM and the user's ~/.pi directory under /root/pi, and handles any other setup (eg: I have some convenience flags set up to specify a block all/block local/block internet/allow all for network access).

One issue I ran into, it doesn't seem like smolvm cleans up disk images from ephemeral VMs, so my script has to do that itself. Is this a known bug or intended behaviour?

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

#97

Post by amelius »

SoftTalker wrote: post #58
amelius wrote: 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.

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

Exactly proving the point.

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

#98

Post by binsquare »

Sanzig wrote: post #96
binsquare wrote: post #78

Earlier quoted context omitted.

I made a lightweight vm specifically for this use case: https://github.com/smol-machines/smolvm

Thanks so much for building smolvm! I liked it so much that I vibe coded a little bash wrapper around it to handle creating ephemeral VMs for Pi: https://github.com/neuroblaze/smol-pi Consists of two scripts, one to build an OCI image (customizable by editing the Dockerfile that comes with it) and another to handle smolvm invocation. The invocation script mounts the current working directory under /workspace in the V…

smolpi looks great!

and smolvm does clean up ephemeral runs if the machine run exits gracefully. I'll take a deeper look into this edge case and fix it today.

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

#99

Post by efxhoy »

kstenerud wrote: post #48
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…

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.

How could an agent bypass file permissions?
Post reply on HN