[TheDong]

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 the codex process is unable to access those files, hence using a container, or unix permissions, or deleting the files. Which you can already do.

I imagine this isn't resolved primarily because people expect it to apply to bash tool use, not just the "read" and "edit" tools, and people also expect those files to still be accessible i.e. if the agent invokes "make", which makes it impossible to solve perfectly.

[cowsandmilk]

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.

[embedding-shape]

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.

[atomicnumber3]

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 _exact hubris_ non-engineers have long accused engineers of - and we have indeed been too often guilty of - they themselves turn out to be JUST as guilty of! Just like engineers thought all sales did was bother people, and all marketing did was send emails, and all support did was tell people to turn it off and on again, and all product did was copy google... they all apparently thought all engineers did was tik-tak-click-clack type code all day and when it compiled it was done. Not knowing how much higher-order... well, engineering, there is to it.

Where are all the CTOs during all of this? I thought someone was supposed to be sticking up for their org? Sales, marketing, etc all seem to have entrenched C-suite people keeping their fiefdoms resistant to erosion by outsourcing, downsizing, etc. But all our CTOs seems to have collectively thrown us to the wolves.

[tern]

I suspect most people don't even know there's a there there.

For instance, while I now know that file systems have permissions, before I became a programmer, I spent maybe ten years thinking of permissions as a special, obscure system thing that you should never touch.

For that matter, I suspect many people don't know basic things like that a file system isn't inherently the operating system.

And, where would you go to learn this information? Your Mac doesn't ship with a manual—how would you know one exists? Furthermore, I would wager that perhaps most people have never learned how anything works requiring a manual and are simply unaware that that's a thing.

All to say, I'm not sure "refusal" is the right term.

[tingletech]

When I was an undergraduate biology student in 1991 a suitemate told me I should go to some desk in some building over by Muir and get an account on the VAX. There were strange rooms all over campus that were open 24/7 and were loaded with green and amber screen terminals with integrated keyboards. Lots of sessions for CS lectures were held in these rooms and there was always interesting notes on the white boards (most rooms still had black boards or green boards, but think the chalk was too dusty so these rooms usually had the white boards.

Once I saw an instruction that was circled with an arrow pointing to is that said:

  man man
  man -k -or- apropos

and that was how I learned about computers.

I just typed `man man` in a terminal on my Mac, and luckily its still there.

[MattDamonSpace]

Not sure I agree?

It’s not like gitignore should be independent from git

[TheDong]

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.

[SoftTalker]

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.

[8organicbits]

Does that work? I've never seen it used. It seems easy to escape.

The docs seem to suggest using alternate approaches.

> Modern systems provide more secure ways to implement a restricted environment, such as jails, zones, or containers.

https://www.gnu.org/software/bash/manual/html_node/The-Restr...

[SoftTalker]

I don't think I've ever seen it used. I think the idea was back in the day when you wanted to let a user have a shell login (because that's the only way you could use a shared computer) but wanted to confine them to a specific directory and prevent them running anything that wasn't in the pre-defined PATH that you set for them.

[jxf]

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

[londons_explore]

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

[brookst]

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

[mcintyre1994]

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.

[jgalt212]

I'm a fan of belt and suspenders.

[lelandfe]

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

[martylamb]

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.

[cowsandmilk]

If you’re already running codex as a different user to limit its file permissions, why would you add it to the docker group?

[lelandfe]

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.

[TheDong]

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.

[jen20]

Lack of knowledge and the desire to have it run containers for things.

[amelius]

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.

[brookst]

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.

[amelius]

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

[brookst]

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.

[SoftTalker]

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

[jrvarela56]

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.

[nicce]

> I imagine this isn't resolved primarily because people expect it to apply to bash tool use, not just the "read" and "edit" tools, and people also expect those files to still be accessible i.e. if the agent invokes "make", which makes it impossible to solve perfectly.

Also, why would they add a feature to prevent data collection, if the data makes the company even more valuable and you might even get good deals from the current government if you provide the access for this data?

[kstenerud]

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.

[nativeit]

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?

[jstanley]

> Why is it necessary for an agent to upload every bit of data it sees to OpenAI at all?

The LLM is running at OpenAI. The agent doesn't see anything that doesn't get sent to OpenAI.

It's like running a compiler in the cloud and asking why you need to send your source code to it when you only want the binary to be on your local PC. It's because that's where the processing is going on and it can't process what it can't see.

> why should the data exist permanently anywhere but in its original location?

Sure, they don't necessarily have to retain it permanently.

[FergusArgyll]

Yes, this was solved decades ago. How do you stop a human from reading one of your files?

  chmod 600

[re-thc]

> How do you stop a human from reading one of your files?

Call the police!