Hardcoded Credentials in AI Coding Tool Config Files Expose Sensitive Data
Research by Hush Security found that 12% of analyzed AI coding tool configuration files on GitHub contained hardcoded credentials, posing significant identity security risks.
Hush Security's latest report, "The State of MCP Configuration: The Identity Security Gaps," has uncovered a widespread issue of hardcoded credentials within configuration files for AI coding tools, commonly found on public GitHub repositories. The research team analyzed approximately 82,000 such configuration files and discovered that a significant 12% contained hardcoded credentials. These exposed API keys and tokens could grant unauthorized access to connected services and systems, highlighting critical gaps in how these powerful AI development tools are secured.
The analysis focused on identifying configuration filenames used by major AI coding agents across public GitHub repositories. Researchers examined environment values and authentication headers, categorizing how credentials were stored. The identified categories included hardcoded values, references to environment variables, client-managed prompts, secret manager integrations, placeholders, and empty fields. To detect potential secrets within hardcoded values, the team employed provider-specific patterns and Shannon entropy, a measure of randomness, to flag likely sensitive information.
It is important to note that the figures presented are considered lower-bound estimates. Hush Security's GitHub code search capabilities index default branches, exclude forks, and limit results per query. Therefore, the actual number of exposed credentials may be higher. In cases where configuration files were general-purpose and only optionally contained MCP settings, researchers specifically sampled files that declared an MCP server. The research team explicitly stated that they did not attempt to authenticate with any services using the discovered credentials.
Further details from the report indicate that a substantial portion of the hardcoded secrets lacked any vendor-recognizable token format. Specifically, 55% of these exposed credentials did not conform to known patterns, including 31% classified as opaque bearer tokens intended for internal MCP servers. For values that did not match known provider formats, researchers relied on factors such as key names, length, entropy, and character patterns to infer their nature. Their assessment concluded that these were predominantly vendor API keys, bearer tokens, and database passwords, with non-secret identifiers forming a negligible portion.
The research also shed light on the persistence of sensitive data within Git repositories. Even when secrets are removed from the current version of a file, Git's version control history can retain them in earlier commits. Researchers investigated 7,681 credential-bearing configurations and found 243 instances where a secret had been removed from the latest file version but remained accessible in a previous commit. This underscores the necessity of rotating credentials at the provider level, as simply deleting them from the current configuration does not eliminate the exposure from the repository's history.
Micha Rave, CEO of Hush Security, emphasized the inadequacy of traditional security practices in this context. "The instinct every security team has trained for years – to scan for secrets, block the commit, and rotate what leaked – isn’t nearly enough here," Rave stated. He further explained that the highest-risk credentials often match no known pattern, lack clear ownership, and have no expiry, creating a significant population of exposed access tokens. The report found that 24% of the hardcoded credential literals were of types designed to be broad-scope and non-expiring, with 53% of classified credentials offering organization-, account-, workspace-, or database-wide access. Additionally, 80% of credentials with defined expiration policies did not expire by default.
These exposed credentials are particularly concerning given the capabilities of MCP (Machine Configuration Platform) connections. These connections can grant AI agents permissions to interact with critical assets such as source code, databases, and cloud infrastructure on behalf of users or organizations. These agents function as non-human identities, leveraging credentials for authentication without requiring direct human intervention for each task. As the adoption of such AI agents grows, organizations face an increasing challenge in tracking their machine identities, associated permissions, responsible parties, and the appropriate end dates for their access.