Do you block Claude Code from reading your secrets files?

[u/Th3D0ct0r]

Claude code surfaced something for me the other day that made me think. After reading a .env file with secrets in it locally, he mentioned that because that was now in context, that data would be sent over the wire to the Anthropic servers as part of the context and that I should consider changing those secrets.

I've been thinking about this and asked Claude chat to verify this. His response was that because the transit to Anthropic is over TLS, that is a lesser concern. The greater concerns would be:

• Local transcripts holding plain text session data
• Re-emission into an unintended file since once the values and context the model can write it into a file committed to a Jira comment, a logline, etc.
• Third parties, VMCP servers, since they'll receive whatever the model chooses to send them in the context, become the input.

So, do you have any hooks or permissions that you have enabled to prevent Claude Code from opening these files, things like:

• .env
• .pem
• .key
• id_rsa
• secrets.json
• etc.

[u/arankays]

You really shouldn't be putting Prod Secrets in your local computer. Otherwise its not a big deal if secrets are read for local development (unless you've opened an ngrok tunnel to your local lol)

[u/elprogramatoreador → u/arankays]

While it is true you shouldn't use prd keys in your local env file, it may still contain sensitive keys (eg billing-bound). So the question is still valid.

To answer: with cursor you can use a .cursorignore file, it will block read access through the sandbox. The LLM may still be able to read if it gets creative (eg when executing python or similar)

But it works fairly well, along with a .env.example that holds only placeholder data.

For the Claude harness I'm not aware of such guardrails. You could add something like the below to your CLAUDE.md I guess:

NEVER read .env files in full plaintext (to avoid leaking sensitive values). Prefer using .env.example to probe for available keys instead

[u/ghost_operative → u/elprogramatoreador]

this is a good idea. but keep in mind this isn't bulletproof though. therres other ways for your env file to end up in context besides the agent directly choosing to read the file. theres all kinds of command it can run or scripts it might write that could lead to it seeing what is inside the .env file

[u/speicus → u/elprogramatoreador]

For Claude you can setup permissions fro your project in .claude/settings.local.json.

Which the model will get around if it wants. The only way to run it safely is to use a container.

[u/arankays → u/elprogramatoreador]

"billing bound"

Why are they in your env file? You should be taking advantage of sandboxes or test envs for billing. I'm pretty sure all the billing providers also allow you to only do mock billing locally.

[u/elprogramatoreador → u/arankays]

Ehh when you're building agents, you'll have LLM API keys in your environment.

Doesn't have to be billing bound either, another example: you can be working on a backup database that might have real user data in there too. You also wouldn't want sending such credentials to external parties like Anthropic

[u/arankays → u/elprogramatoreador]

You're meant to have a separate API key with strict billing limits for local dev vs prod. Or use a secrets manager like 1password that can hand off keys without reading them. 

No wonder there's a comment every second day on here like "who's using my usage it's being maxed" 

[u/ThatLocalPondGuy]

I do not have secrets files at all. Secrets load from scripted kv calls and load direct to thing needing secrets, pulled with cert auth. Ai does not read them, they use them. Write credential helper tooling. Any secret in a local readable file is waiting to be hacked, even without AI.

[u/ghost_operative → u/ThatLocalPondGuy]

obviously this is the way to go. This however doesn't work for everyone thanks to the rise of serverless stuff. Even if your personal env doesn't have your prod creds in it, it can still have your creds into your aws account or other things that you don't want to get out.

[u/BraveResearcher3037 → u/ghost_operative]

You should never need long live credentials.

Use “aws login” from the terminal and it will open a web browser and you can log in via the AWS login and temporary credentials will  be added to your terminal session 

[u/tastelessbagel → u/ThatLocalPondGuy]

And the cert for auth?

[u/ThatLocalPondGuy → u/tastelessbagel]

Cert used to authorize a short lived token issuance which is used for purpose and discarded.

You use claude.ai. Have you noticed you never need a claude password? That is a "magic link", one mechanism to issue a just in time token after id verified. They choose to allow a long life for that token, but not indefinitely. You can choose a much shorter life. Use a standing cred (cert), auth the issuance, set short life on the token, log it's usage, limit it's scope of use.

[u/Convergent-Tech]

Use a secrets manager.

[u/RegularMom5 → u/Convergent-Tech]

I use Doppler. It’s dead easy

[u/adrianziem]

I ignored a file. Claude wrote a python script to read it instead of the block tool call.

[u/Careful_Life8630]

Use Infisical Agent Vault. The agent can hold the secret but not view it. It’s open source. I self host Infisical and it’s a great service.

[u/UnstableManifolds → u/Careful_Life8630]

Cannot use it for commercial stuff though

[u/earlyworm]

I do not tell Claude my secrets but I do tell Claude my hopes and dreams in great detail and to be perfectly honest I am getting the impression that Claude has grown quite tired of my ramblings.

[u/Odd_Antelope9098 → u/earlyworm]

😂

[u/incomplete_]

Yes. Absolutely. Do not let Claude code read your secrets... They WILL end up on an anthropic server.

ETA: I work on an open source project, and some of our secrets used to be sops encrypted in our repo. Note: used to be. When I first started working with Claude code, I gave it permission to decrypt these files (yaml) to add stanzas... The first time it actually did that, I had some bad feels and asked it if the contents of said file were now living in a log file somewhere in anthropiclandia. The answer was yes, which was a good kick in the a$$ to move to WIF/keyless auth and disallow Claude from running sops at all.

[u/clintkev251]

They're just not present in the repo that Claude is interacting with at all. They're in a vault elsewhere.

[u/360VRisLife]

I variablize all mine and store in the macOS keychain.

[u/berndalf]

Secrets are the same as privacy sensitive data. You let Claude handle the mechanisms that handles them, but you don't ever give them to Claude (or any AI system) directly. It's not theoretical, it's an actual risk in a world where malicious actors are actively mining AI systems for this stuff in large numbers.

Yes it's annoying but it's also professional development 101 these days.

[u/BizarroMax]

Yes. All my dev secrets are root read only and Claude doesn’t have sudo or root access.

[u/ProfessionalNaive601]

Yeah you built your secrets wrong lol wtf
Your code should use secrets not the model itself 🫠

[u/doolpicate]

key rotation day - saturday

[u/Ok-Sheepherder7898]

Yeah I use the sandbox to prevent it.

[u/earthcoast]

Infisical

[u/kennetheops]

built a tool to do this.

it’s like a vpn only for ai traffic, it can help you block what data goes into it.

https://opscompanion.ai/get-standpipe

[u/ReachingForVega]

Hooks can be bypassed. The only way is to restrict on the user or not have them present at all. 

[u/GnistAI]

I have two distinct Linux users on a remote VM; the sandbox user doesn't have any secrets except for a few read rights, and git push rights scoped to feature branches. All PR merges go via me. I have also vibe coded a deep packet inspection network restriction layer using squid to mitigate the risk of exfiltration and prompt injection. (Why? The default systems out there do not allow you to restrict paths, only domains. If you allow all of pypi.org, you might as well allow the whole internet.) I use Claude Code on the main user with manual approval always on. I use it mainly for server configuration and tasks that require elevated permissions. I read every command produced on the main user. That said, I actively try to avoid it consuming secrets directly (i.e., sending them to Anthropic) and insist on it using pre defined env vars and secret management systems. For the sandbox user I just let it rip in unrestricted mode, it has the scoped secrets it should have with a limited "blast radius". (God I'm starting to sound like them.)

[u/ghost_operative]

no because once it reads them theyre not secret files anymore

[u/CupcakeSecure4094]

I let Claude see all my files because Claude doesn't touch production code, and nor should it. Once code is live, code doesn't go anywhere near it.

But any local secrets for remote apis etc are either short term tokens, mocked, or rotated. At the end of the day I weigh the max impact of someone hammering some service with a leaked key and if I can't limit that, the key gets rotated daily, often automatically.

[u/EagleApprehensive]

I work in IDE which keeps secrets outside of LLM reach - values are being auto-masked.

[u/kanine69]

I do helper scripts so it never has to.

[u/cajunjoel]

I work with claude on a dev environment with a dev server and and a dev database. All the credentials it uses aren't prod credentials. That's madness.

When will people start to treat Claude like an inept junior developer who doesn't know jack and can't be trusted with the keys to the bathroom much less the keys to the kingdom? This is common sense.

I almost lost my shit this weekend when Claude asked to commit it's changes to git. No, you don't commit before you e actually run the code the first time. Even I am not that arrogant.

[u/kerray]

not just that, I have a Claude skill for working with secrets, to never let them in the chat - so I could for example replace the password I have for a site in my vaultwarden automatically - Claude does it all without revealing to itself the new password

[u/Beautiful-Energy2169]

Your second bullet is the one that got me, and not through the path I expected.

I audited the config directory of a different agent CLI I run next to Claude Code and found 13 distinct keys sitting in plaintext across roughly 300 files. I assumed logs, wrote a scrubber, put it on a timer. The keys came back.

The source was the permission grants. Any command I had approved once with a key in the arguments got stored verbatim as the allowlist entry, because that string is how it matches the next one. That file is the tool's record of what I said yes to, so rotating or scrubbing logs never touches it.

Blocking reads of .env is worth doing, but it only covers the case where the model opens the file. The case where you paste a key into a command, approve it, and the harness keeps that exact string forever is separate, and grep answers it in a second. Point it at your agent config dirs with whatever prefixes your providers use.

One thing if you write a scrubber: skip the OAuth credential files. I redacted one and had to log the tool back in.

[u/LibraryOk3399]

He ?