Your AI Assistant Might Be Your Next Breach

How AI credentials are creating a new identity security blind spot

Open a developer’s laptop today and you are likely to find a small collection of files most security teams have never inventoried: OAuth tokens for an AI coding assistant, API keys for a handful of model providers, and a configuration file holding access tokens for GitHub, a cloud platform, an internal database, and a messaging workspace. Many of these files sit in plaintext, at predictable paths, protected by nothing more than the assumption that no one is looking.

Discussion of AI security still centers on what employees type into AI systems, and those worries about prompts and data leakage are reasonable. But the credentials these tools leave behind are turning into a larger and less understood problem, and the data suggests it is already costing organizations.

In the latest Netwrix Data & Identity Security Report, organizations where AI significantly increased the number of identities in their environment reported a 43% breach rate over the past 12 months. Where AI had not meaningfully changed the identity footprint, the rate was 11%. That fourfold gap was one of the strongest findings in a survey of more than 2,300 security and IT leaders, and it points to something worth sitting with: AI adoption has become an identity security problem.

AI is expanding the identity attack surface faster than anyone is governing it

Every AI tool needs access to something. A coding assistant might reach into source repositories, cloud platforms, CI/CD pipelines, and ticketing systems. An AI-powered business application connects to file shares, CRM data, and internal knowledge bases. Each of those connections becomes a new token, account, or permission set, and they accumulate quickly. According to the Netwrix research, 58% of organizations say more identities now have access to enterprise data, 72% report that identity-related exposure has increased, and 41% already have agentic AI running in production with access to enterprise information.

Identity governance was built around a human rhythm: someone is hired, changes roles, and eventually leaves, and access reviews catch up at each step. AI does not move on that schedule. A new integration or agent can be deployed in an afternoon and open an access path no one planned for. The visibility gap that follows is wide. The report found that 74% of organizations lack a unified view of sensitive data and the identities that can reach it, and 71% cannot quickly say which identities have access to sensitive information. When you cannot see who or what has access, every AI system you connect inherits that uncertainty along with its permissions.

The credential problem hiding in plain sight

I recently spent time examining how popular AI assistants, coding tools, and desktop applications handle the credentials they need, and the pattern was consistent across products. Authentication tokens, API keys, and OAuth credentials are routinely written to local files and configuration settings that never receive the protection enterprises apply to traditional secrets. Often these credentials reach well beyond the AI service itself.

A single workstation can hold tokens for source repositories, cloud infrastructure, collaboration platforms, and databases all at once. In several tools, credentials for multiple services are aggregated into one configuration file, so a single read gives an attacker everything in it. None of this is a new category of mistake. Security teams have spent years stamping out hardcoded passwords and plaintext secrets. What has changed is the volume and the reach. Millions of employees now run AI tools that hold persistent access to external systems, which means a compromised laptop can be a doorway into every system those tokens unlock.

Why governance keeps falling behind

The shortfall is less about missing controls than about timing. The Netwrix report found that 76% of organizations do not fully govern or monitor non-human identities, only 20% fully monitor employee use of shadow AI, and just 11% have operationalized AI governance with continuous oversight of identities, permissions, and the data those systems can touch. Plenty of organizations have written policies. Far fewer enforce them continuously, and that distinction is where the risk lives. AI systems do not pause for a quarterly access review, reaching into data and spinning up new dependencies around the clock, at a speed governance processes designed for human users were never meant to match.

Securing the identities behind AI

For most organizations, the next phase of AI security will turn on visibility more than on model choice. Teams need to know where AI-related credentials live, what those credentials can reach, and whether the access is still warranted. That means accounting for non-human identities, service accounts, and agent workflows alongside human users, and governing them on an ongoing basis rather than at intervals.

Tooling, such as the free, open-source AIHound, is starting to help with the discovery piece. They identify credentials that AI tools leave behind on employee workstations, which answers a question most teams cannot currently answer: what access already exists that no one is watching?

Discovery is the starting point, not the finish. Once you know what is on a machine, a few direct steps measurably reduce exposure:

• Tighten permissions on credential files so they are readable only by their owner, since some tools default to world-readable settings, particularly under Windows Subsystem for Linux. 
• In agent and MCP configurations, replace inline tokens with environment-variable references so secrets are not sitting in shared or version-controlled files. 
• Rotate any token that has lived in a world-readable file, a synced settings store, or git history, and treat long-lived CI/CD tokens with the same caution as a privileged password. 
• Avoid running AI tools with permission prompts disabled on any machine that holds real credentials or network access, and turn off cloud settings sync for tools that would otherwise upload local credentials. 
• For teams standardizing on a set of AI tools, it is worth checking whether each one supports the operating system’s keychain, because that single capability often separates a tool that protects credentials from one that does not.

AI is stretching the identity perimeter further and faster than most programs were built to handle, and the credentials behind these tools are the part of it that tends to go unmonitored. The work now is to find those credentials, understand what they reach, and bring them under the same governance as everything else. Every system is still only as secure as the access it grants.

_______

 About the Author

Darryl Baker is a Senior Staff Security Researcher at Netwrix, where he focuses on identity security and emerging attack techniques targeting enterprise authentication systems. With a background spanning security research, consulting, and adversary simulation, he specializes in uncovering real-world attack paths and helps organizations better defend hybrid identity environments. Darryl is also a frequent speaker, instructor, and content creator known for making deeply technical topics accessible to both practitioners and leadership audiences.