4 ms·

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.

• FergusArgyll 4mo ago
  Yes, this was solved decades ago. How do you stop a human from reading one of your files? chmod 600
  • deleted 4mo ago
    [deleted]
  • re-thc 4mo ago
    > How do you stop a human from reading one of your files? Call the police!
    • aleph_minus_one 4mo ago
      > > How do you stop a human from reading one of your files? > Call the police! Rather: Send the Marines. With intro: https://www.youtube.com/watch?v=eFvxqQTh3m4 https://www.youtube.com/watch?v=eFvxqQTh3m4 Without intro: https://www.youtube.com/watch?v=HHhZF66C1Dc https://www.youtube.com/watch?v=HHhZF66C1Dc
• lelandfe 4mo ago
  Just be aware that AI agents will explore alternate means of accessing said files: https://news.ycombinator.com/item?id=48348578 https://news.ycombinator.com/item?id=48348578
  • cowsandmilk 4mo ago
    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 4mo ago
      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 4mo ago
        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.
        • lelandfe 3mo ago
          OTOH it lets you file a bug report :) As opposed to, "well, you should have ran it in a container if you didn't want your baby photos deleted"
    • jen20 4mo ago
      Lack of knowledge and the desire to have it run containers for things.
• nicce 4mo ago
  > 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?
• cowsandmilk 4mo ago
  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.
  • londons_explore 4mo ago
    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 4mo ago
      But that means the process can’t use the key for network requests, right?
    • mcintyre1994 4mo ago
      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.
  • MattDamonSpace 4mo ago
    Not sure I agree? It’s not like gitignore should be independent from git
    • jxf 4mo ago
      .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.
• kstenerud 4mo ago
  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 4mo ago
    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 4mo ago
      > 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.
  • efxhoy 4mo ago
    How could an agent bypass file permissions?
    • kstenerud 4mo ago
      By exploiting a root escalation. Or just finding a file/dir you forgot to set a tight enough mode on (happens a lot in systems where the default is insecure).
  • SubiculumCode 4mo ago
    What is your sandbox approach? Any good guides? Something about asking a LLM for advice on how to sandbox LLMs.....
• jrvarela56 4mo ago
  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.
  • sheremetyev 4mo ago
    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 https://github.com/sheremetyev/sandfence
    • valleyer 4mo ago
      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)?
  • niyikiza 4mo ago
    We've been using Tenuo which for task-scoped authorization. Its integration for Claude Code: https://github.com/tenuo-ai/claude-governance https://github.com/tenuo-ai/claude-governance
• mohsen1 4mo ago
  [dead]
• chriddyp 4mo ago
  While this is true, there is also a layer in the harness between the output of _any_ tool output (eg stdout or hand-rolled tools) and the LLM. A tool could read the file but then the agentic harness could redact the output before returning it back to the llm if any of the contents matched the file contents. We do something similar in Plotly Studio where we check the entropy of strings in the user input and flag & redact any high entropy strings to the user as “potential credentials” thay the user might have inadvertently copied and pasted into the prompt before sending to the llm. There are ways around this - the llm can always be clever by invoking tools to read the file contents in a different way than the direct file contents - but this is all to say that the agentic harness layer _does_ allow for deterministic logic in between tool output and the LLM requests.
• quotemstr 4mo ago
  > 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. That's quite inconvenient. I want to run my coding agent in a restricted version of my regular user context, not something that drives like a separate machine. > 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. You have codex run rg in the sandbox, and the sandbox can't read foo. Why is this model so difficult to understand? Codex already runs a variety of commands under a bwrap/seatbelt/etc. sandbox. I've merely extended Codex to run everything in a sandbox. Escalation isn't a matter of whether to run a command in a sandbox or not: it's a matter of which sandbox policy to apply to whatever it is the model asked to do. > the only solution is to make it so the codex process is unable to access those files That's not true. Restrictions need apply only to the tools the model runs, not the Codex process itself. You can always insert a process-and-sandbox boundary between the harness and its tools. Codex inserts this boundary most of the time anyway. I've extended my Codex to do it all the time, even for things like the read-a-file tool. Works fine. > I imagine this isn't resolved primarily because people expect it to apply to bash tool use, Yeah? Applying it to the shell tool [1] is trivial. It's actually harder to apply the sandbox to non-shell tools. It just isn't hard conceptually: you define a sandbox policy, writing down what's allowed and not, and just filter everything the model does through this policy via OS-level lightweight sandboxing tools. Seriously. It's not that hard. And you don't have to sandbox the Codex process itself. I honestly have no idea why people think it's necessary to do so. The model has no ability to make Codex-the-POSIX-process do arbitrary things. [1] I refuse to call it the "bash tool" when most users are running zsh in it. Name things appropriately.
• wavemode 3mo ago
  > people also expect those files to still be accessible i.e. if the agent invokes "make", which makes it impossible to solve perfectly You could always use setuid to allow the agent to run designated commands whose operation depends on the files, without the agent itself being able to access the files.