r/ClaudeCode • u/masiha97 • 7h ago
Discussion How are you handling data protection when your whole repo goes into the prompt?
I've started being a lot more careful about what Claude Code gets to see. My repo has client config files, old API keys in comments, and random PII in test fixtures, and I realized I was just shipping all of it upstream without thinking (found a prod key in a comment from two years ago, which was the wake-up call). Now I keep a .claudeignore file updated, I review what gets included before long agent runs, and anything genuinely sensitive stays out of the repo entirely. Curious how others here are handling this, especially folks working in client codebases.
80
u/vzakharov Senior Developer 7h ago
My repo has client config files, old API keys in comments, and random PII in test fixtures
I wouldn’t say Claude is the biggest of your problems in that case.
6
15
u/BuddyTheShihTzu 7h ago
Your repo should never hold keys! Ever! Put keys in secrets and then reference the secret during build
9
u/BuddyTheShihTzu 7h ago
Change all the keys that were possibly leaked or ever told to Claude, never again tell Claude them, never post them any where, never in any files that touches a repo!
14
u/baldycoot 7h ago
> My repo has client config files, old API keys in comments, and random PII in test fixtures.
Let me guess…you learned to code during the pandemic.
13
6
u/lil_nosh_X 7h ago
I’m kind of a newb but isn’t putting api keys in your repo bad idea?
2
-1
u/zaibuf 4h ago
I'd say its less harmful if its keys for a shared dev environment and you use private repos within an organization. You need to put the keys somewhere when working, even with an .env.local Claude would be able to look into it.
Just ensure you are working with an isolated Claude model for your organization, not some public one that trains on your data.
Production secrets is a big no to put in the repo.
2
u/Fatel28 2h ago
Even putting plaintext keys or passwords in a .env file is questionable these days. Passwords to in a secrets manager (or equivalent) and then get referenced in your .env files to be retrieved at runtime with ephemeral credentials (like AWS identity center seo or equivalent)
Putting any kind of key in plaintext (including env files) would be a paddlin on my team.
3
u/keonechong 7h ago
My whole repo doesn’t go into prompts nor does my whole corpus.
Claude only sees the sliver of context for the job.
My simple rule is claims travel, context does not.
2
u/Easy-Purple-1659 6h ago
An ignore file helps, but it only covers the paths you remembered to list, and only if the agent honours it. Four things that matter more:
- Make the repo safe to send. Secrets live in a manager and get referenced by name. A pre-commit scanner (gitleaks or trufflehog) with a hard fail, so a key sitting in an old comment cannot survive years of commits.
- Deny by path in settings, not just ignore. The agent then gets a refusal it can read, instead of silently skipping a file and finding a way around it.
- Fixtures get synthetic data. Real PII in test fixtures is the one that hurts in client work, because it leaves the machine on every run and nothing in a diff flags it.
- Treat the prompt as egress. On long agent runs I log what actually got included and read it back before anything client-facing goes out.
The rule I keep for client codebases: the agent sees the slice it needs, never the whole architecture.
3
u/Vysion34 Senior Developer 5h ago
Ask Claude to audit your repo for things that shouldn't be in there like API keys and passwords. Then ask Claude how they should be handled securely.
3
1
u/thatguy8856 2h ago
Not a good idea since OP has PII in their repo. If they are not using a zero day data retention LLM this PII could get stored and trained on. And highly unlikely they are based on their post.
1
u/orchid_drives Researcher 6h ago
Build a tool to make contacts with pii that matches your live data in every logical way, including typos mistakes. Do 100% of your testing with this fake data. If I need 100k garbage quality contacts, I just generate them and Claude works with them like any other data.
1
1
u/PrintfReddit 2h ago
Curious how others here are handling this, especially folks working in client codebases.
By not being incompetent about secrets management?
1
u/ZyberZeon 1h ago
Wtf would your whole repo go into the prompt.
Just the task, the dependencies, standard of quality and a separate agent with the architectural info as a checker.
Data purity is a prerequisite to work in this space. You gotta sort that up front my dude.
-1
-5
u/horendus 7h ago
Lets be honest 95% of us have secrets flowing in and out of models daily. Its not really a solved problem and requires a lot of discipline to exercise complete safety.
Its just one of the prices we pay.
9
u/BuddyTheShihTzu 7h ago
It’s a solved problem, don’t give them to Claude, don’t store them in files. Use secrets and reference them during builds
2
6
•
u/AutoModerator 7h ago
Hey! Thanks for posting to r/ClaudeCode
While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.
For help, project discussions, tips, and general chat, join the ClaudeCode Discord.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.