TL;DR: Hardcoded credentials, API keys and database strings can leak into AI code review, public LLM prompts and training data, according to Doppler’s analysis, where redaction is brittle and secrets can be echoed back or memorised. The architectural fix is to keep secrets out of code entirely and inject them only at runtime.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Doppler's blog post: AI workflows can expose hardcoded secrets through code review, prompt logging and training, making runtime secret separation the decisive control.
Why it matters: This matters because developers increasingly move code and context into AI systems, which means credential handling now has to account for model prompts, logs and training data as leak paths.
Context
AI-assisted development changes where secrets can escape. When code, diffs or stack traces are pasted into model-backed tools, the credential is no longer protected by the same boundaries that apply to source control or local files.
The core governance issue is that redaction is a detection problem, while secret placement is an architecture problem. If the sensitive value still exists in the code path, the AI workflow can expose it through logging, memory, or generated output.
Treat secrets management as a runtime design decision, not a cleanup step after disclosure. Once the secret is in the clipboard, the workflow has already expanded the blast radius.
Key questions
Q: What is the safest way to keep API keys out of AI code review?
A: Keep API keys out of the source material that AI tools inspect. Store credentials in a managed secret store, inject them at runtime and ensure review systems only see variable names or references. That removes the secret from prompts, logs and training sets before the AI workflow can copy it or retain it.
Q: Why do redaction filters miss secrets in LLM workflows?
A: Redaction filters miss secrets in LLM workflows because they usually scan visible prompts and outputs, not every transient place data can appear, such as retrieved context, tool calls, logs, traces, embeddings, cached prompts and copied snippets. They also fail on partial matches, base64, structured fields and secrets split across messages. Controls include secret-aware DLP, prompt and output scanning, tool allow-lists, and secret scanning before logging or retrieval.
Q: How does runtime secret injection reduce credential exposure?
A: Runtime secret injection reduces credential exposure by keeping secrets out of source code, build artefacts and long-lived environment variables, then loading them only when a workload or agent needs them. The credential is fetched at execution time from a secrets manager or vault, scoped to the task, and can be rotated or revoked without redeploying. It fits the phrase runtime secret injection naturally.
Q: What should teams do first when a live secret is found in logs?
A: Treat it as an exposed credential, not a logging event. Revoke the secret, replace it with a narrower credential if possible, and confirm which systems accepted the old token before the revocation completed.
Technical breakdown
Why AI workflows create new secret exposure paths
AI development tools create multiple disclosure surfaces that traditional secret controls do not cover. A prompt sent to a hosted model can be retained for abuse monitoring or future training, a fine-tuned model can memorise rare high-entropy strings, and an automated review system can echo sensitive values into comments or logs. These are different mechanisms, but they share one property: the secret leaves the developer-controlled boundary before any defensive control can act. The problem is not just accidental sharing. It is that AI systems transform a single pasted secret into stored prompts, training artefacts and generated output. See the LLM Provider API Key Security and LLMjacking Guide.
Practical implication: Inventory every AI touchpoint where code or logs can be ingested and treat each as a potential secret disclosure path.
Why redaction fails as a primary control
Redaction works only when the sensitive pattern is known, the input format is predictable and the transformation preserves enough context for the model to remain useful. In practice, secrets appear in custom formats, unusual wrappers and code snippets that regex-based filters miss. Over-redaction can also remove the context a model needs to review code correctly, which pushes teams to weaken the filter or bypass it. That makes sanitisation a compensating control at best. It cannot guarantee that secrets never reach the model, and it cannot solve training-data leakage after the fact. Read Guide to the Secret Sprawl Challenge.
Practical implication: Use redaction as a safety net, not as the mechanism that protects credentials moving through AI tools.
Runtime secret injection breaks the leakage chain
Runtime secret injection separates the application’s logic from the credential itself. Developers and AI tools interact with variable names, configuration references and code structure, while the actual secret is resolved only when the workload runs. That changes the exposure model in a useful way: a pasted code snippet no longer contains the secret value, so the AI cannot leak what it never received. This approach also reduces the chance that training data contains live credentials, because repository content remains symbolic rather than secret-bearing. The remaining risk shifts to the secret store and its access paths, which is where governance belongs. Read the Ultimate Guide to NHIs: Static vs Dynamic Secrets.
Practical implication: Move credentials out of source code and into a managed runtime source so AI tools only see references, not values.
Threat narrative
Attacker objective: The attacker or unintended consumer obtains usable secrets that can be reused to access cloud services, APIs or internal systems.
- Entry occurs when developers paste code, diffs or tracebacks containing secrets into AI tools or when automated review systems ingest sensitive repository content.
- Credential exposure follows when prompts, logs or training sets retain those values instead of discarding them after the session.
- Impact occurs when the leaked credential is reproduced in model output, reused by an attacker, or exposed in logs that broaden the disclosure surface.
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.
- Microsoft Azure OpenAI abuse by Storm-2139: Storm-2139 used API keys leaked by Microsoft customers to hijack Azure OpenAI, bypass safety guardrails and resell access to generate harmful content.
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 leakage in AI workflows is a placement problem, not a filtering problem. The dangerous assumption is that secrets can safely exist in code until a redaction layer removes them. AI workflows break that assumption because the credential may already have entered prompts, logs or training data before the filter runs. The practical conclusion is that the security boundary must move upstream, before code ever reaches an AI system.
Context leakage is now an identity governance issue. AI code review bots, hosted prompts and fine-tuning pipelines all consume machine-readable artefacts that may contain live credentials. That makes secrets governance part of the identity lifecycle, not just an application-security task, because the credential has to be owned, scoped and removed across every place it can be copied.
Runtime secret separation is the control that changes the risk profile. When credentials are injected only at execution time, AI tools see references rather than values, which removes the most common disclosure mechanism. That does not eliminate all risk, but it collapses the exposure window and makes leak response tractable.
Secret sprawl across AI tooling creates an AI workflow exposure surface. Each place a model can inspect code, store prompts or generate output becomes a possible secret-handling boundary. Organisations need to govern that surface as a first-class part of NHI and secrets management, not as an incidental side effect of developer productivity.
The best fix for AI secret leakage is architectural, not behavioural. Developer training still matters, but it cannot reliably override convenience, speed or automation. Practitioner teams should treat AI tooling as an untrusted transport layer for sensitive values and design their stack so the value never travels through it.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Secrets Management Guide
What this signals
Secret leakage in AI workflows is moving upstream into development habits. The next governance test is not only whether secrets are stored securely, but whether code review and prompt usage can be designed so sensitive values never enter the AI path in the first place.
AI workflow exposure surface: Every prompt, review bot, log stream and training job that can ingest code becomes a potential credential-handling boundary. Organisations that still rely on prompt filtering will keep losing ground to faster, more embedded AI usage.
As AI adoption expands, secret management has to move closer to workload execution. The programme that wins here is the one that makes runtime injection the default and treats all AI tooling as an untrusted transit layer for sensitive values.
For practitioners
- Remove hardcoded secrets from code paths Replace embedded credentials, API keys and database strings with runtime references so AI tools only receive symbolic values.
- Treat AI prompts as disclosure surfaces Classify code review bots, chat assistants and fine-tuning jobs as places where sensitive input may be logged, retained or reused.
- Use runtime secret injection by default Keep secrets in a managed store and resolve them only when the application runs, so repository content stays non-sensitive. Read the Ultimate Guide to NHIs: Static vs Dynamic Secrets.
- Plan for immediate credential rotation after exposure Assume any secret that reaches a prompt, log or training set must be treated as compromised and revocation needs to be fast. See the API Key Management Guide.
- Reduce dependency on regex-based sanitisation Use filtering only as a fallback, because pattern matching will miss non-standard tokens and can degrade review quality when it is too aggressive.
Key takeaways
- AI-assisted development can leak credentials through prompts, logs and training data before traditional controls ever see them.
- The main evidence is that AI-related secret exposure is already a live problem, not a theoretical one, with secrets appearing in both training corpora and service abuse cases.
- Keeping secrets out of source code and injecting them only at runtime is the control that most directly reduces exposure in AI workflows.
Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · Ultimate Guide to NHIs: Static vs Dynamic Secrets · LLM Provider API Key Security and LLMjacking Guide · API Key Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | AI workflows create secret leakage paths through prompts, logs and training data. |
| NHI-07 — Long-Lived Secrets | The article argues for runtime injection instead of exposing durable credentials to AI systems. | |
| Recommendation — Remove secrets from code paths and revoke any credential that reaches an AI workflow. Shorten credential lifetime by injecting secrets at runtime rather than storing them in source code. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central when exposed secrets must be rotated quickly. |
| Recommendation — Apply IA-5 to manage issuance, rotation and revocation for application credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The topic is about limiting what exposed credentials can access if leaked through AI tooling. |
| Recommendation — Restrict entitlements so exposed application credentials have the smallest possible blast radius. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat pattern centres on attackers obtaining usable secrets from AI workflows. |
| Recommendation — Map AI secret exposure cases to credential access activity and hunt for reuse of leaked keys. | ||
Key terms
- Runtime Secret Injection: A pattern that retrieves credentials only when a process starts, rather than storing them in files or source control. For AI developer tools, it reduces secret persistence, limits accidental disclosure, and keeps the credential tied to a specific execution session.
- LLM Memorisation: LLM memorisation is the tendency of a large language model to retain and reproduce specific training examples or rare text from its training data. It matters when the model can emit sensitive or proprietary content that was present during training, especially if prompts elicit verbatim or near-verbatim recall.
- Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines, typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
- Prompt retention: Prompt retention is the storage of user prompts, chat history, or model context after a conversation ends. It matters because sensitive data can persist outside the original system boundary, creating privacy, compliance, and deletion challenges when organisations cannot prove what was kept, for how long, or where it was copied.
Deepen your knowledge
NHI governance, agentic AI identity, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on November 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org