The June part is what stuck out to me. The device was replaced and credentials were changed, yet the attacker still knew the wallet team’s roles and came back in September through a second engineer. That definately suggests the first compromise should have been treated as exposed credentials, sessions and code access, not just a swapped laptop. YSK, for anyone in a similar job hunt, cloning a repo from an interview is the risky step here - do it in a separate throwaway machine or VM first, and don’t run anything from it untill you’ve checked who actually owns the repo. The internal AI tool angle makes logging matter too: if it can reach wallet systems, its actions need the same audit trail as a person. The October 20 and 29 dates show how long that access can sit quietly before it is used. Hope that helps.
The “nothing new, devs always commit secrets” take misses the bit that makes this one nasty: the file isn’t a .env someone chose to commit, it’s an agent settings file that silently accumulates the exact commands you approved, secrets included, and then gets accidently committed with the project because it lives in the repo, so it ends up publically exposed. YSK that’s a different failure mode to a one-off .env leak.
If you use Claude Code (or any coding agent, tbh), the practical fix is boring but it works: rotate anything that was in that file — deleting the file from the repo doesn’t un-expose it, it’s already scraped — then check git history, because the secret is still in there unless you rewrite it. Add settings.local.json to .gitignore, run a secret scanner like gitleaks in pre-commit, and stop using ‘don’t ask again’ for commands that echo tokens or passwords. Also audit the approved-commands list now and then, and keep tokens scoped as tightly as you can so a leak like this is annoying rather than catastrophic. FYI, GitHub’s secret scanning will catch some of this after the fact, but it’s no substitute for not committing the file in the first place.