3 ms·

Does this actually work? I assume an AI which wanted to read a secret and found it wasn't in .env would simply put print(os.environ) in the code and run it...

Does this actually work? I assume an AI which wanted to read a secret and found it wasn't in .env would simply put print(os.environ) in the code and run it... That's certainly what I do as a developer when trying to debug something that has complex deployment and launch scripts...

PufPufPuf 8mo ago
Good point. You would need to inject the secrets in an inaccessible part of the pipeline, like an external proxy.
- syhol 8mo ago
  Like deno sandbox https://deno.com/deploy/sandbox https://deno.com/deploy/sandbox
  - canadiantim 8mo ago
    Tailscale's new aperture also solves this elegantly: https://aperture.tailscale.com/ https://aperture.tailscale.com/
  - ctmnt 8mo ago
    But that's moving the whole LLM agent into the cloud, which creates its own difficulties. Not really a solution to the local secrets problem.
snowhale 8mo ago
[dead]
andai 8mo ago
Your concerns are not entirely unfounded. https://www.reddit.com/r/ClaudeAI/comments/1r186gl/my_agent_stole_my_api_keys/ https://www.reddit.com/r/ClaudeAI/comments/1r186gl/my_agent_... I have noticed similar behavior from the latest codex as well. "The security policy forbid me from doing x, so I will achieve it with a creative work around instead..." The "best" part of the thread is that Claude comes back in the comments and insults OP a second time!
- wrqvrwvq 8mo ago
  Every time someone announces a major ai breakthrough, the utility mode becomes a wall of ai-generated soc3 advice: > SANDBOX YOUR AGENT. Seriously. Run it in a dedicated, isolated environment like a Docker container, a devcontainer, or a VM. Do not run it on your main machine. > "Docker access = root access." This was OP's critical mistake. Never, ever expose the host docker socket to the agent's container. > Use a real secrets manager. Stop putting keys in .env files. Use tools like Vault, AWS SSM, Doppler, or 1Password CLI to inject secrets at runtime. > Practice the Principle of Least Privilege. Create a separate, low-permission user account for the agent. Restrict file access aggressively. Use read-only credentials where possible. In order to use this developer-replacement, you need accreditation from professional orgs. Maybe the bot can set all this up for you, but then you are almost definitely locked out of your own computer and the bot may not remember its password. I'm not sure what we've achieved here. If you give it your gmail account, it deletes your emails. If you "sandbox" it, then how is it going to "sort out your inbox"? It might or might not help veteran devs accelerate some steps, but as with vibeclaw, there's essentially no way to use the tool without "sandboxing" it into uselessness. The pull requests for openclaw are 99% ai slop. There's still no major productivity growth engine in llm's.
  - toraway 8mo ago
    Yeah, it seems "sandboxing" is the current catch-all buzzword in AI products to hand-wave away any security concerns. Which often raises more questions than it answers for something like a generalist dev agent that has access to an endless number of tools/APIs/etc that could allow for a trivial bypass depending on the whims of the agent while problem solving.
  - andai 8mo ago
    I just gave it a dedicated `agent` user. So it's free to blow up its own files, but not mine. (Looked into the docker stuff and realized the only thing I actually cared about was it reading/writing my files and that Unix solved that problem like 60 years ago) I'm not hooking it up to my email, but I will probably give it its own account that I can forward stuff to. For most people I think the appropriate way to run it is on a Raspberry Pi (or mac mini, as the trend goes :) I realized I could fiddle with docker and have constant inconvenience and still stress about did I set it up right.. or just give it its own box (pi or VPS) for $5 and if it blows it up I just reset it. Having Claude as my sysadmin there is fun too. I obviously wouldn't use that for anything serious though. But in a year or two, that might not even be such a bad idea. At this point reliability is really the missing feature.
ctmnt 8mo ago
It doesn't even have to change the code to get the secret. If you're using env variables to pass secrets in, they're available to any other process via `/proc/<pid>/environ` or `ps -p <pid> -Eww`. If your LLM can shell out, it can get your secrets.

PufPufPuf 8mo ago

Good point. You would need to inject the secrets in an inaccessible part of the pipeline, like an external proxy.

syhol 8mo ago
Like deno sandbox https://deno.com/deploy/sandbox https://deno.com/deploy/sandbox
- canadiantim 8mo ago
  Tailscale's new aperture also solves this elegantly: https://aperture.tailscale.com/ https://aperture.tailscale.com/
- ctmnt 8mo ago
  But that's moving the whole LLM agent into the cloud, which creates its own difficulties. Not really a solution to the local secrets problem.

snowhale 8mo ago

[dead]

andai 8mo ago

Your concerns are not entirely unfounded. https://www.reddit.com/r/ClaudeAI/comments/1r186gl/my_agent_stole_my_api_keys/ https://www.reddit.com/r/ClaudeAI/comments/1r186gl/my_agent_... I have noticed similar behavior from the latest codex as well. "The security policy forbid me from doing x, so I will achieve it with a creative work around instead..." The "best" part of the thread is that Claude comes back in the comments and insults OP a second time!

wrqvrwvq 8mo ago
Every time someone announces a major ai breakthrough, the utility mode becomes a wall of ai-generated soc3 advice: > SANDBOX YOUR AGENT. Seriously. Run it in a dedicated, isolated environment like a Docker container, a devcontainer, or a VM. Do not run it on your main machine. > "Docker access = root access." This was OP's critical mistake. Never, ever expose the host docker socket to the agent's container. > Use a real secrets manager. Stop putting keys in .env files. Use tools like Vault, AWS SSM, Doppler, or 1Password CLI to inject secrets at runtime. > Practice the Principle of Least Privilege. Create a separate, low-permission user account for the agent. Restrict file access aggressively. Use read-only credentials where possible. In order to use this developer-replacement, you need accreditation from professional orgs. Maybe the bot can set all this up for you, but then you are almost definitely locked out of your own computer and the bot may not remember its password. I'm not sure what we've achieved here. If you give it your gmail account, it deletes your emails. If you "sandbox" it, then how is it going to "sort out your inbox"? It might or might not help veteran devs accelerate some steps, but as with vibeclaw, there's essentially no way to use the tool without "sandboxing" it into uselessness. The pull requests for openclaw are 99% ai slop. There's still no major productivity growth engine in llm's.
- toraway 8mo ago
  Yeah, it seems "sandboxing" is the current catch-all buzzword in AI products to hand-wave away any security concerns. Which often raises more questions than it answers for something like a generalist dev agent that has access to an endless number of tools/APIs/etc that could allow for a trivial bypass depending on the whims of the agent while problem solving.
- andai 8mo ago
  I just gave it a dedicated `agent` user. So it's free to blow up its own files, but not mine. (Looked into the docker stuff and realized the only thing I actually cared about was it reading/writing my files and that Unix solved that problem like 60 years ago) I'm not hooking it up to my email, but I will probably give it its own account that I can forward stuff to. For most people I think the appropriate way to run it is on a Raspberry Pi (or mac mini, as the trend goes :) I realized I could fiddle with docker and have constant inconvenience and still stress about did I set it up right.. or just give it its own box (pi or VPS) for $5 and if it blows it up I just reset it. Having Claude as my sysadmin there is fun too. I obviously wouldn't use that for anything serious though. But in a year or two, that might not even be such a bad idea. At this point reliability is really the missing feature.

ctmnt 8mo ago

It doesn't even have to change the code to get the secret. If you're using env variables to pass secrets in, they're available to any other process via `/proc/<pid>/environ` or `ps -p <pid> -Eww`. If your LLM can shell out, it can get your secrets.