Your AI coding agent just saved a password. Did anyone notice?

AI coding agents are introducing new ways to expose sensitive credentials. Recent research shows how a routine developer action can create a security risk that established scanners fail to detect.

A developer working with Claude Code approves a command.

They click "Yes, and don't ask again". It's a useful feature. Nobody wants to approve the same command repeatedly when they're trying to get work done.

But there's a catch.

If that command contains a password, Claude Code can save the entire command, including the password, in a local configuration file. And if that file gets committed to GitHub, the password goes with it.

The developer hasn't deliberately exposed a credential. They haven't written an insecure application or ignored a security warning.

They've just approved a command. Yet that ordinary interaction can have serious consequences.

Research published by Apiiro in November 2026 identified 2,539 suspected exposed secrets across 1,994 public GitHub repositories.

And when researchers tested two established secrets scanners, Gitleaks and TruffleHog, both missed 215 of the 1,122 affected Claude Code settings files.

It's a reminder that AI coding agents are changing how security risks enter the development process; and the tools designed to protect us aren't necessarily keeping pace.

Your AI agent remembers more than you think

AI coding assistants are getting better at many tasks. They can execute commands, access development environments, interact with external services and automate tasks that previously required direct developer intervention.

That's a large part of their appeal; but these capabilities also change how sensitive information moves through the development environment.

Credentials can appear in commands executed by agents, configuration files used to manage their behaviour, and other artefacts created during development.

Take Claude Code's permission settings. When a developer selects "Yes, and don't ask again", an approved command can be recorded in .claude/settings.local.json. The file is intended for local configuration, but if it isn't properly excluded from version control, it can end up in a shared or public repository.

A password that was only needed to execute one command can suddenly become a stored credential with a much longer lifespan.

The problem isn't necessarily the individual developer's judgement. It's that an apparently harmless interaction can have consequences that aren't immediately visible. And as organizations give AI coding agents more autonomy, those consequences are getting harder to anticipate.

The scanner didn't see it. But GitHub did.

Apiiro's researchers examined 104,185 publicly accessible Claude Code local settings files. They found 1,122 containing suspected secrets, including database passwords, API tokens and other credentials.

To understand whether existing security tools would identify them, the researchers tested Gitleaks and TruffleHog.

The results were pretty revealing.

Gitleaks flagged 564 of the affected files. TruffleHog flagged 643. And both missed 215.

That's 19.2% of affected files escaping detection by either scanner in this particular test.

Many of the missed credentials were embedded in commands rather than appearing in conventional API key formats. A database password passed as an argument to a command, for example, might look like an ordinary string to a tool relying on recognizable patterns.

The findings don't mean secrets scanning is ineffective. They demonstrate that credentials can appear in forms that established detection approaches struggle to identify. 

We've explored this in more detail in this post, Code Security False Positives: What Matters?, including how to assess whether your existing security scanners are detecting genuine risks.

And there’s a broader challenge here.

AI agents are creating new places for secrets to hide, while you could still be scanning for expected places. That has an impact when security teams are tasked with speeding up development without increasing business risk.

Deleting a secret doesn't undo the damage

There's another finding from the research that we shouldn’t overlook.

Apiiro discovered 734 suspected secrets in historical versions of affected files that were no longer present in the current versions. In other words, the credentials had been removed from the latest files, but remained in repository history.

That's a problem because Git remembers.

Deleting a credential from a file doesn't necessarily remove it from earlier commits, forks or copies of the repository. And if the credential remains valid, the exposure can continue long after the original mistake has been corrected.

Effective remediation could involve rotating credentials, reviewing access and checking for other copies.

For large enterprises with thousands of developers working across extensive repository estates, that can pose a substantial security challenge.

The initial exposure might have taken seconds, but understanding its full impact can take much longer.

AI agents are changing the rules of enterprise security

At the FT Live Future of AI Summit in London, one concern came up repeatedly in our conversations with technology leaders: AI security.

It was described as one of the biggest risks keeping boards awake at night. Enterprises are investing heavily in AI coding tools, with the expectation that they'll help developers produce more software, faster.

But as those tools get more autonomous, they're also changing the nature of the development environment.

A coding assistant that only suggests code presents a different security challenge from an agent that can execute commands, access credentials and interact with external systems. The more authority an agent has, the more important it is to understand how that authority is exercised.

This isn't an argument against AI coding agents. Nor is it a reason to require developers to manually approve every routine operation. But organizations need to recognise that the controls designed around traditional development practices may not cover every behaviour introduced by autonomous tools.

AI agents have more freedom to act; security teams need an equally clear view of what those actions leave behind – including the commands agents execute, the files they create and the sensitive information they may inadvertently preserve.

You can't protect what you don't know your agents are doing

The Claude Code research highlights a problem that goes beyond one AI tool or configuration setting. Security risks are emerging from the way developers interact with AI agents, not solely from the code those agents produce.

And those risks can persist in files and repository histories long after the original task has finished.

This changes where you need to focus attention.

Agent permissions and secure configuration matter. So does preventing credentials from being exposed in commands wherever possible. But prevention alone won't catch every mistake.

Organizations also need detection controls capable of recognizing credentials in less predictable contexts, alongside processes for investigating and remediating exposures.

‍

If this is something you’re concerned about, book an individual security workshop with our team to review your current secrets detection approach and explore ways to strengthen your controls.

Book a bespoke security workshop here. 

‍