They increase exposure because developers move faster, paste more context into prompts, and review output for function before security. That combination makes secrets more likely to appear in code, logs, or old commits, and those secrets can remain valid long after discovery.
Why This Matters for Security Teams
AI-assisted development changes where secrets are introduced, duplicated, and overlooked. Prompts often include source snippets, environment variables, API keys, or stack traces so the model can produce a working fix quickly. That increases the number of places a secret can be copied, and it reduces the chance that a human reviewer notices exposure before code is committed. The result is not just accidental disclosure in the repository, but also secret propagation into tickets, chat tools, build logs, and generated examples. NIST’s NIST Cybersecurity Framework 2.0 is a useful anchor here because it treats protection as a lifecycle issue, not a one-time scan.
Security teams also need to account for the fact that AI output can normalize insecure patterns. If an assistant suggests hardcoded credentials, test tokens, or copied connection strings, developers may accept them as temporary and then forget to remove them. Current guidance suggests this is less a model flaw than a workflow flaw: fast iteration, broad context sharing, and weak secret handling combine to create repeat exposure across the software delivery chain. In practice, many security teams encounter secret sprawl only after a repository leak, a cloud key alert, or an incident response review rather than through intentional governance.
How It Works in Practice
The exposure risk grows at several points in the development lifecycle. First, developers paste sensitive context into prompts to help the model understand code paths, failures, or infrastructure. Second, generated code may include placeholders that are replaced with real secrets during local testing or automation. Third, chat histories, IDE plugins, and code review tools can retain prompt content longer than intended. Once a secret appears in any of those places, it can be indexed, cached, or copied into downstream artifacts. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because secret handling depends on disciplined access control, logging, and configuration management.
- Minimise prompt context by redacting credentials, tokens, and production identifiers before submission.
- Use short-lived credentials and automated rotation so any leaked secret has a reduced window of value.
- Scan source control, pull requests, and build output for exposed secrets before merge and release.
- Separate assistant access from production systems so AI tools do not inherit broad authority.
- Require review of generated code for hardcoded secrets, logging leaks, and insecure fallback logic.
This also intersects with non-human identity governance because many exposed secrets belong to service accounts, API keys, and automation identities rather than people. The OWASP Non-Human Identity Top 10 is especially relevant where development assistants touch CI/CD, deployment pipelines, or cloud automation. Anthropic’s first AI-orchestrated cyber espionage campaign report also illustrates how AI can accelerate operational abuse when sensitive access material is available. These controls tend to break down when teams allow unrestricted prompt sharing into production-connected environments because the same secret then travels through multiple unmanaged tools.
Common Variations and Edge Cases
Tighter secret controls often increase friction for developers, requiring organisations to balance delivery speed against the effort of redaction, scanning, and approval steps. That tradeoff is real, but current best practice is evolving toward automation rather than manual discipline alone. In mature environments, secret detection runs in the IDE, pre-commit hook, CI pipeline, and cloud runtime so developers get fast feedback without needing to remember every rule.
There is no universal standard for this yet, especially where teams use local models, third-party coding assistants, or agentic tools that can write files and trigger actions. The risk profile changes when the assistant has repository access, shell access, or deployment authority, because a single prompt can produce and persist secrets across multiple systems. In those cases, governance should treat the assistant as a privileged non-human identity with constrained scope, short-lived tokens, and auditable actions. For teams building toward stronger operational control, the NIST cybersecurity and control frameworks should be used alongside identity governance so secret exposure is managed as an access and lifecycle problem, not just a code-quality issue.
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 ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Secret exposure is fundamentally an access and protection problem across the delivery chain. |
| NIST AI RMF | GOVERN | AI-assisted workflows need accountability for how prompts, outputs, and tools handle sensitive data. |
| OWASP Non-Human Identity Top 10 | NHI-2 | Service accounts and API keys often carry the leaked secrets in AI-assisted delivery. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege reduces the blast radius when assistants or developers expose credentials. |
| MITRE ATLAS | Adversarial use of AI can exploit exposed secrets and accelerate downstream abuse. |
Limit who and what can see secrets, then continuously verify protection across code, tools, and pipelines.
