Topic starter
15/10/2026 10:09 am
TL;DR: Truffle Security found that most tested LLMs still recommend hardcoding API keys and passwords, and that the problem persists across popular coding assistants and IDE workflows because models inherit insecure patterns from training data and context handling. The practical issue is not just bad autocomplete, but a new pathway for credential exposure that shifts review and filtering to the point of code generation.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “LLMs are Teaching Developers to Hardcode API Keys”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: LLM-assisted coding can normalise hardcoded API keys and passwords unless organisations enforce controls at the point of generation, not only during review.
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.
👉 Read Truffle Security's analysis of LLMs teaching developers to hardcode API keys →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/10/2026 10:12 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: LLMs are teaching developers to hardcode API keys