Using Proxies to Hide Secrets from Claude Code

Re:Using Proxies to Hide Secrets from Claude Code by jackfranklyn on Tuesday January 13, 2026 @01:17PM (#46605250)

The proxy pattern here is clever - essentially treating the LLM context window as an untrusted execution environment and doing credential injection at a layer it can't touch.

One thing I've noticed building with Claude Code is that it's pretty aggressive about reading .env files and config when it has access. The proxy approach sidesteps that entirely since there's nothing sensitive to find in the first place.

Wonder if the Anthropic team has considered building something like this into the sandbox itself - a secrets store that the model can "use" but never "read".

[ Parent | on HN ]

Re:Using Proxies to Hide Secrets from Claude Code by iterateoften on Sunday January 18, 2026 @08:56PM (#46674236)

It could even hash individual keys and scan context locally before sending to check if it accidentally contains them.

[ Parent | on HN ]

Re:Using Proxies to Hide Secrets from Claude Code by JoshuaDavid on Monday January 19, 2026 @12:22AM (#46675332)

That's how they did "build an AI app" back when the claude.ai coding tool was javascript running in a web worker on the client machine.

[ Parent | on HN ]

Re:Using Proxies to Hide Secrets from Claude Code by mike-cardwell on Monday January 19, 2026 @08:14AM (#46678627)

> a secrets store that the model can "use" but never "read".

How would that work? If the AI can use it, it can read it. E.g:

    SECRET=$(echo $(secret-store "foo") > file; cat file)

You'd have to be very specific about how the secret can be used in order for the AI to not be able to figure out what it is. You could provide a http proxy in the sandbox that injects a HTTP header to include the secret, when the secret is for accessing a website for example, and tell the AI to use that proxy. But you'd also have to scope down which URLs the proxy can access with that secret otherwise it could just visit a page like this to read back the headers that were sent:

https://www.whatismybrowser.com/detect/what-http-headers-is-...

Basically, for every "use" of a secret, you'd have to write a dedicated application which performs that task in a secure manner. It's not just the case of adding a special secret store.

[ Parent | on HN ]

Re:Using Proxies to Hide Secrets from Claude Code by ashwinr2002 on Tuesday January 20, 2026 @07:40PM (#46699738)

This seems like an under-rated comment. You are right, this is a vulnerability and the blog doesn't talk about this.

[ Parent | on HN ]

Re:Using Proxies to Hide Secrets from Claude Code by ironbound on Monday January 19, 2026 @08:15AM (#46678634)

Sounds like an attacker could hack Anthropic and get access to a bunch of companies via the credentials Claude Code ingested?

[ Parent | on HN ]

Re:Using Proxies to Hide Secrets from Claude Code by ipython on Monday January 19, 2026 @10:41AM (#46680182)

I guess I don't understand why anyone thinks giving an LLM access to credentials is a good idea in the first place? It's been demonstrated best practice to separate authentication/authorization from the LLM's context window/ability to influence for several years now.

We spent the last 50 years of computer security getting to a point where we keep sensitive credentials out of the hands of humans. I guess now we have to take the next 50 years to learn the lesson that we should keep those same credentials out of the hands of LLMs as well?

I'll be sitting on the sideline eating popcorn in that case.

[ Parent | on HN ]

Re:Using Proxies to Hide Secrets from Claude Code by edstarch on Monday January 19, 2026 @12:13PM (#46681597)

While sandboxing is definitely more secure... Why not put a global deny on .env-like filename patterns as a first measure?

[ Parent | on HN ]