LLMs are teaching developers to hardcode API keys

At a glance

What this is: Truffle Security reports that popular LLMs often recommend hardcoding API keys and passwords, even when secure alternatives are available.

Why it matters: This matters because AI-assisted coding can turn secret management into a generation-time problem, forcing IAM and application security teams to stop credential leaks before code is written.

By the numbers:

• Truffle Security tested 10 popular LLMs and found that most of them recommend hardcoding API keys and passwords.

👉 Read Truffle Security's analysis of LLMs teaching developers to hardcode API keys

Context

LLM-assisted coding is now part of the development workflow, which means security decisions increasingly happen before code review and sometimes before a developer understands the risk. When a model suggests hardcoded API keys or passwords, the problem is not just a bad snippet. It is a governance failure in the interaction layer between AI assistance, developer experience, and secret handling.

For IAM and NHI programmes, this is a familiar pattern in a new place: secrets appear where they should never exist, then spread through repositories, prompts, logs, and generated code. The article shows that AI coding tools can normalise insecure credential handling unless the surrounding environment applies guardrails, filtering, and review discipline. That makes secret governance part of AI governance, not a separate afterthought.

Key questions

Q: What should teams do first when an AI coding assistant suggests hardcoded credentials?

A: Stop the secret from reaching source control, then classify it as an NHI exposure. The first control should be output blocking or rewriting, followed by secret scanning on the branch and immediate rotation if a real credential was exposed. Manual review alone is too late once the suggestion is copied into code.

Q: Why do LLMs increase the risk of exposing PII, passwords, or API keys?

A: LLMs can increase exposure risk because they may ingest sensitive material during training or inference, then reproduce it later in unexpected ways. Overfitting, poor sanitization, weak access controls, and prompt injection all raise the chance that confidential data will surface in plain text. The risk is amplified when models interact with multiple users or shared knowledge sources.

Q: How can security teams tell whether AI lifecycle controls are working?

A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current. If those signals are fragmented across platforms, the programme may be documenting governance rather than enforcing it. Continuous traceability is the practical test.

Q: What is the difference between secure prompting and secret scanning for AI-generated code?

A: Secure prompting tries to prevent the model from suggesting secrets in the first place, while secret scanning detects exposed credentials after they appear in code. Both matter, but prompting is preventive and scanning is detective. Teams need both because generation-time errors can happen faster than review can catch them.

Technical breakdown

Why LLMs keep suggesting hardcoded secrets

LLMs predict likely code patterns from training data, so they often reproduce insecure examples when those examples are common in public repositories. If insecure credential handling appears frequently enough in the training corpus, the model can treat it as a plausible default unless the prompt, system instructions, or post-processing steer it away. That is why secure documentation alone is not enough. The model is not reasoning about organisational secret policy; it is pattern-matching code completion against an imperfect data set.

Practical implication: Treat model output as untrusted code generation and add credential-safe prompting and filtering at the point of use.

Why IDE context changes the secret exposure risk

The same model can behave differently depending on whether it is used in a chat panel, inline editor, or tool-integrated workflow. That is because surrounding context, system prompts, and application-level filters shape the output. An IDE can detect that a completion contains hardcoded credentials, but detection alone is not enforcement. If the tool only warns and does not rewrite or block the suggestion, the insecure pattern still survives the interaction and can be copied into production code.

Practical implication: Place policy enforcement in the assistant workflow, not only in developer training or manual review.

Why AI-generated code becomes an NHI governance problem

Hardcoded API keys are non-human identities in a degraded form: they are machine credentials created without lifecycle discipline, visibility, or offboarding. Once they enter source control, they expand the attack surface across build systems, repositories, and downstream services. This is where NHI governance and secure development intersect. The control failure is not just exposure, but the normalisation of reusable secrets in places where short-lived, scoped credentials should have been used instead.

Practical implication: Apply NHI lifecycle controls to AI-generated code so secret creation, storage, and revocation are governed together.

Threat narrative

Attacker objective: Exploit AI-assisted coding to increase the volume of reusable secrets that end up exposed in repositories and application workflows.

1. Entry occurs when an LLM or coding assistant recommends hardcoded API keys or passwords inside generated code.
2. Credential exposure follows when a developer accepts the suggestion and commits the secret into source control, an IDE buffer, or an application config file.
3. Impact comes when the leaked credential can be reused to access downstream systems, APIs, or cloud resources without an obvious authentication event.

Breaches seen in the wild

• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secret hygiene is becoming a model-governance problem, not just a developer discipline problem. The article shows that LLMs can normalise hardcoded API keys because they absorb insecure patterns from training data and surface them during code generation. That changes the control point from manual review alone to the entire AI-assisted authoring flow. For practitioners, the decisive question is whether the assistant can be made to stop proposing secrets before they enter the SDLC.

Hardcoded credentials are a non-human identity failure mode with a human interface. Developers may see a convenience feature, but the underlying risk is machine credential creation without inventory, expiry, or offboarding. That makes the issue squarely relevant to NHI governance as well as application security. The field needs to treat AI-generated secrets as a lifecycle problem, not merely a secure coding mistake.

Generation-time controls need to replace review-only assumptions. Traditional governance assumes insecure code is found during review or testing, but AI assistants can create the risk earlier and faster than those controls can intervene. That means policy has to operate in the prompt, the IDE, and the output filter, with the repository scan acting as a backstop rather than the primary defence. Practitioners should design for prevention at generation time, not rely on discovery after commit.

The strongest concept here is credential synthesis drift. As models ingest insecure examples and regurgitate them in newer workflows, the ecosystem can drift toward unsafe credential handling even when developers believe they are using modern tooling. This is not a tooling bug alone. It is a governance signal that secret management, developer experience, and AI safety now share the same control surface, so teams must govern them together.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: API Key Management Guide

What this signals

Credential synthesis drift: when models repeatedly learn and reproduce insecure credential patterns, the organisation’s exposure shifts from isolated developer error to systemic secret generation risk. Security teams should assume that AI assistants can increase secret volume faster than traditional review can absorb it, which makes generation-time policy enforcement essential.

This is where NHI governance becomes operational rather than theoretical. If AI-generated code can introduce reusable machine secrets, then inventory, rotation, and revocation must extend to the assistant workflow, not just the repository or runtime.

Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.

For practitioners

• Block hardcoded secrets at generation time Add output filtering or rewriting so AI assistants cannot return API keys, passwords, or tokens in code suggestions.
• Use secure system prompts and IDE rules Configure assistant prompts, workspace rules, and coding templates to prefer environment variables, secret managers, and short-lived credentials.
• Scan AI-generated code before commit Run repository and pre-commit secret scanning on all assistant-produced code so exposed credentials are caught before merge.
• Treat AI assistants as secret producers Update NHI inventory and governance processes so any credential introduced through code generation is tracked, rotated, and revoked like any other machine secret.

Key takeaways

• LLM-assisted coding can normalise hardcoded API keys and passwords unless organisations enforce controls at the point of generation, not only during review.
• The risk is larger than bad suggestions because exposed secrets can move from prompts into repositories, configs, and downstream services very quickly.
• Security teams should combine prompt policy, output filtering, and secret scanning so AI-generated code cannot introduce reusable credentials unchecked.

Key terms

• Hardcoded Credential: A secret such as a password, API key, or token embedded directly in source code rather than retrieved from a secure vault at runtime. Hardcoded credentials are one of the most common and dangerous NHI vulnerabilities.
• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Generation-time control: Generation-time control is security enforcement applied while an AI assistant is producing output, not after the code enters the repository. It matters because machine-speed coding compresses the window for review and makes delayed detection far less effective.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full report

Truffle Security's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact Slack and Stripe prompt tests used to evaluate model behaviour.
• The IDE-specific differences between chat and inline editing workflows in VS Code.
• The observed content filter behaviour and why warning-only controls are insufficient.
• The practical prompting approaches the vendor suggests for reducing hardcoded credential suggestions.

👉 The full Truffle Security post shows the prompt tests, IDE differences, and filter behaviour in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect developer workflows, credential lifecycle controls, and broader identity security programmes.