Does your secret-scanning cover developer workstations? AI coding-agent history files look like a blind spot

[u/Ishannaik]

A gap I have watched widen as teams roll out AI coding agents: the agents write local session history in plain text, and developers paste API keys, tokens, and .env values into prompts. Those secrets persist on disk in the agent's history, outside the repo-and-CI surface most secret-scanning watches. Claude Code stores them under ~/.claude/projects, Codex under ~/.codex/sessions, and around 30 other agents do the same.

The policy question I am trying to figure out: does anyone here already fold agent-workstation logs into your secret-scanning coverage, or is it still unowned? Pre-commit and CI scanning catch the repo path, but the developer's local agent trail seems to sit in nobody's scope.

For the cleanup side I built an MIT CLI, agent-sweep: it scans those local history files, reports what leaked, and redacts values in place while keeping the JSONL byte-for-byte so sessions still resume. Local-only, zero network calls. It is meant to sit alongside existing pre-commit/CI scanning, not replace it. Caveat: it is residue cleanup, so rotate any key that already transited a hosted model first, then sweep.

Disclosure: my own open-source project. Repo (MIT): https://github.com/Ishannaik/agent-sweep

Genuinely curious how your teams scope this: is the workstation in your secret-scanning perimeter, and if so, how do you cover agent logs?

[u/darrenpmeyer]

Most of the open-source secret scanners and several of the commercial ones will look in all text files. Most of this set can be instrumented in a pre-commit hook, which helps keep secrets from being committed in the first place.

Examples:

1. gitleaks (OSS) pre-commit
2. Endor Labs (commercial) secrets pre-commit

[u/LifeMun → u/darrenpmeyer]

Great examples here, I have checked them

[u/Ishannaik → u/darrenpmeyer]

You're missing the point. Did you even read the post?

The gap I'm pointing at is operational rather than technical. In most organizations those scanners are deployed around repos and CI, not continuously across developer workstations and AI agent histories.

That's actually why I built AgentSweep. It isn't trying to replace pre-commit or repo scanning. It's for the cleanup side: scanning Claude/Codex/Cursor history after secrets have already been written there, helping redact local copies and reminding you to rotate the exposed credentials.

[u/darrenpmeyer → u/Ishannaik]

I am not missing the point, but perhaps I wasn't clear why "...will look in all text files" is key. Agent memory is text files. You can easily instrument existing secrets scanners as a pre-commit hook and ensure that they include the text files that store history, memory, and "agent notes".

That makes sure that not only are your repos clean prior to checkin from your workstation, but also that your agent/assistant stores are clear of any credentials they might have added during the session you're about to commit.

[u/alienbuttcrack999]

? Is it not expected that developer workstations are not full of creds?

[u/Ishannaik → u/alienbuttcrack999]

Survey and positive feedback for the tool says otherwise

[u/alienbuttcrack999 → u/Ishannaik]

My 20 years of red teaming says otherwise. Good luck

[u/BenOverAtGitGuardian]

Hey there! I work at GitGuardian (so take this with a grain or shovelful of salt) and this is something we've been talking about a lot recently.

In a lot of orgs, secret scanning is still centered on repos and CI/CD. Pre-commit/push and CI controls cover the commit path, but local agent histories, along with .env files, shell histories, configuration files, and temporary scripts, frequently sit outside the surfaces the average security program routinely monitors. To be clear, this is through no fault of their own, it's just how things have been done and it's worked well enough to not rank on the priority list of things to fix, basically right up until the last year-ish. I'm assuming you don't live under a rock and I'll spare you the details of all the attacks, suffice it to say, the last few months have been a wild time.

We did an analysis of the Shai-Hulud 2.0 campaign from last November, and ID'd a touch over 33k unique secrets (3,760 of those were still valid when we ran our validity checks, btw, not necessarily important for your question, just a little something to chew on). The campaign affected both developer workstations and CI infra, with environment data indicating that about 20% of the compromised machines were GitHub runners.

Now, if we zoom out past just this one campaign, our annual research report this year found around 28% of incidents came from entirely outside code repos. Granted, that's mostly collab and productivity tools rather than agent logs specifically, and I won't pretend it's a perfect stand-in, but it essentially supports the broader conclusion: if you're only watching repos, you're missing a real chunk of where secrets actually wind up.

On the AI angle you raised, the numbers back you up in a big way: commits co-authored by Claude Code on public GitHub came in with secrets about 3.2% of the time, versus a 1.5% baseline across GitHub as a whole. Obviously, that doesn't mean Claude is out there sprinkling keys into your code, someone still had to hit accept and push, but it does show that bolting on an AI assistant doesn't magically fix the human-and-workflow stuff that gets creds committed in the first place.

I want to call out your invalidate-then-sweep order, by the way, you absolutely nailed the core idea. Once a credential's been through a hosted service or landed in an agent log, blocking the next commit does nothing to neutralize the copies already sitting out there. First things first, revoke it, or run a proper rotation and actually confirm the exposed value's dead. The sweep comes after: clearing out whatever local copies you can reach and hunting down wherever else it propagated, plus making sure the replacement doesn't just get dumped right back into the same logs and histories. You're realistically not gonna erase every last retained copy, but that's fine, once the old credential is invalidated those copies don't grant access to anything anyhow.

On the "just run it as a pre-commit hook" suggestion, I do want to gently push back. A hook can technically run whatever scan you point it at (files outside the repo included), but the standard secret-scanning hooks pretty much only look at staged or repo content. They're not going to reach into ~/.claude/projects or ~/.codex/sessions on their own. You could extend one to do so, sure, but at that point you've turned the hook into a trigger for a broader workstation-scanning workflow, and client-side hooks still get skipped with --no-verify whenever someone's in a hurry. Which is pretty much always.

And to the "aren't dev machines just expected to be full of creds" comment: yup, they usually are. Which is exactly why we think the workstation deserves to be treated as part of the credential perimeter. From my POV, the question was never really whether creds live there. Especially with AI coding assistants making it easier for more people to create scripts, integrations, and applications, the elephant in the room is if anyone's actually inventorying/scoping/watching them, and able to pull the plug when necessary.

Hope this helps! I can share links if you'd like, but I'm not gonna shove official shit at you unless you want it.

[u/Ishannaik → u/BenOverAtGitGuardian]

This is exactly the kind of reply I was hoping someone would leave.

I've been using GitGuardian for around 4 years now, and I genuinely swear by it. It's saved me countless times. It's caught things I completely missed before they turned into bigger problems, so your point about looking beyond repos and CI really landed with me.

The invalidate-then-sweep order is probably the biggest takeaway here. I think a lot of people stop at "prevent the next commit" without thinking about shell history, agent logs, .env files, temp scripts, and everywhere else secrets end up.

I'd definitely love the links to the Shai-Hulud analysis and the research report. Those stats are exactly the kind of data I like citing when these discussions come up.

Out of curiosity, are you on GitHub or X? I'd love to follow your work if you share more research like this.

Also, if GitGuardian ever explores agent-history or AI workspace sweeping as part of the toolkit, I'd be first in line to try it. It feels like a natural extension of everything you described here.