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

Using proxies to hide secrets from Claude Code

joinformal.com

Post reply on HN
Print view View original

11–20 of 61 posts

Re: Using proxies to hide secrets from Claude Code

#11

Post by samlinnfer »

brunoborges wrote: post #9
samlinnfer wrote: post #6

Here's the set up I use on Linux: The idea is to completely sandbox the program, and allow only access to specific bind mounted folders. But we also want to have to the frills of using GUI programs, audio, and network access. runc ( https://github.com/opencontainers/runc ) allows us to do exactly this. My config sets up a container with folders bind mounted from the host. The only difficult part is setting up a trans…

Any particular reason why you shared these files in a gist rather a repo?

Yeah you're right, a repo is better: https://github.com/dogestreet/dev-container

I've made it clonable and should be straightforward to run now.

Re: Using proxies to hide secrets from Claude Code

#12

Post by samlinnfer »

idorosen wrote: post #10
samlinnfer wrote: post #6

Here's the set up I use on Linux: The idea is to completely sandbox the program, and allow only access to specific bind mounted folders. But we also want to have to the frills of using GUI programs, audio, and network access. runc ( https://github.com/opencontainers/runc ) allows us to do exactly this. My config sets up a container with folders bind mounted from the host. The only difficult part is setting up a trans…

try firejail insread

Not even close to the same thing, with this setup you can install dev tools, databases, etc and run inside the container.

It's a full development environment in a folder.

Re: Using proxies to hide secrets from Claude Code

#14

Post by keepamovin »

I think people's focus on the threat model from AI corps is wrong. They are not going to "steal your precious SSH/cloud/git credentials" so they can secretly poke through your secret-sauce, botnet your servers or piggy back off your infrastructure, lol of lols. Similarly the possibility of this happening from MCP tool integrations is overblown.

This dangerous misinterpretation of the actual possible threats simply better conceals real risks. What might those real risks be? That is the question. Might they include more subtle forms of nastiness, if anything at all?

I'm of the belief that there will be no nastiness, not really. But if you believe they will be nasty, it at least pays to be rational about the ways in which that might occur, no?

Re: Using proxies to hide secrets from Claude Code

#15

Post by ekidd »

samlinnfer wrote: post #6

Here's the set up I use on Linux: The idea is to completely sandbox the program, and allow only access to specific bind mounted folders. But we also want to have to the frills of using GUI programs, audio, and network access. runc ( https://github.com/opencontainers/runc ) allows us to do exactly this. My config sets up a container with folders bind mounted from the host. The only difficult part is setting up a trans…

I have a version of this without the GUI, but with shared mounts and user ID mapping. It uses systemd-nspawn, and it's great.

In retrospect, agent permission models are unbelievably silly. Just give the poor agents their own user accounts, credentials, and branch protection, like you would for a short-term consultant.

Re: Using proxies to hide secrets from Claude Code

#16

Post by chrisweekly »

jclarkcom wrote: post #7
TheRoque wrote: post #5

At the moment I'm just using "sops" [1]. I have my env var files encrypted uth AGE encryption. Then I run whatever I want to run with "sops exec-env ...", it's basically forwarding the secrets to your program. I like it because it's pretty easy to use, however it's not fool-proof: if the editor which you use for editing the env vars is crashing or killed suddently, it will leave a "temp" file with the decrypted vars…

I do something similar but this only protects secrets at rest. If you app has an exploit an attack could just export all your secrets to a file. I prototyped a solution where I use an external debugger to monitor my app, when the app needs a secret it generates a breakpoint and the debugger catches it and then inspects the call stack of the function requesting the secret and then copies it into the process memory (in…

clever

Re: Using proxies to hide secrets from Claude Code

#17

Post by hobs »

keepamovin wrote: post #14

I think people's focus on the threat model from AI corps is wrong. They are not going to "steal your precious SSH/cloud/git credentials" so they can secretly poke through your secret-sauce, botnet your servers or piggy back off your infrastructure, lol of lols. Similarly the possibility of this happening from MCP tool integrations is overblown. This dangerous misinterpretation of the actual possible threats simply be…

Putting your secrets in any logs is how you get those secrets accidentally or purposefully read by someone you do not want to read it, it doesn't have to be the initial corp, they just need to have bad security or data management for it to leak online or have someone with a lower level of access pivot via logs.

Now multiply that by every SaaS provider you give your plain text credentials in.

Re: Using proxies to hide secrets from Claude Code

#18

Post by dtkav »

I'm working on something similar called agent-creds [0]. I'm using Envoy as the transparent (MITM) proxy and macaroons for credentials.

The idea is that you can arbitrarily scope down credentials with macaroons, both in terms of scope (only certain endpoints) and time. This really limits the damage that an agent can do, but also means that if your credentials are leaked they are already expired within a few minutes. With macaroons you can design the authz scheme that *you* want for any arbitrary API.

I'm also working on a fuse filesystem to mount inside of the container that mints the tokens client-side with short expiry times.

https://github.com/dtkav/agent-creds

Re: Using proxies to hide secrets from Claude Code

#19

Post by samlinnfer »

ekidd wrote: post #15
samlinnfer wrote: post #6

Here's the set up I use on Linux: The idea is to completely sandbox the program, and allow only access to specific bind mounted folders. But we also want to have to the frills of using GUI programs, audio, and network access. runc ( https://github.com/opencontainers/runc ) allows us to do exactly this. My config sets up a container with folders bind mounted from the host. The only difficult part is setting up a trans…

I have a version of this without the GUI, but with shared mounts and user ID mapping. It uses systemd-nspawn, and it's great. In retrospect, agent permission models are unbelievably silly. Just give the poor agents their own user accounts, credentials, and branch protection, like you would for a short-term consultant.

The other reason to sandbox is to reduce damage if another NPM supply chain attack drops. User accounts should solve the problem, but they are just too coarse grained and fiddly especially when you have path hierarchies. I'd hate to have another dependency on systemd, hence runc only.
Post reply on HN