TL;DR: AI coding tools are accelerating insecure code, secret leakage, and dependency risk faster than many AppSec programmes can absorb, with Xygeni citing 35 new CVEs in March 2026 from AI tools, 62% of AI-generated code containing flaws per CSA, and AI-assisted commits leaking secrets at more than twice the human rate. The security model has to shift from review-heavy workflows to continuous controls that match development velocity.
At a glance
What this is: AI-generated code is increasing vulnerability density, secret leakage and risky dependency introduction faster than traditional AppSec controls can keep up.
Why it matters: IAM, NHI and application security teams need continuous controls because AI-assisted development can expose credentials, trust weak dependencies and bypass review assumptions.
By the numbers:
- The Georgia Tech Vibe Security Radar project recorded 35 new CVEs in March 2026 directly attributable to AI coding tools.
- CSA research found that 62% of AI-generated code contains design flaws or known vulnerabilities.
Context
AI-generated code changes the security problem from isolated coding mistakes to systematic exposure at development speed. The key issue is not simply more bugs, but more predictable failure patterns, more secret leakage paths and more dependency choices that outpace traditional AppSec review.
That creates a genuine governance gap for application security, NHI and secrets management programmes because the control point shifts earlier in the software lifecycle. When AI tools can introduce secrets, insecure dependencies and flawed authentication logic before a human reviewer sees them, manual review alone is no longer a sufficient boundary control.
Key questions
Q: What breaks when AI code review tools are allowed to analyse untrusted pull requests?
A: The review workflow itself becomes an attack surface. Prompt injection in comments, documentation, or code can steer the model, expose secrets, or trigger unsafe actions if the tool has privileged access. Teams should treat untrusted pull requests as hostile inputs and require manual approval before automated security scanning runs.
Q: Why do AI-assisted commits increase secret exposure risk?
A: AI-assisted workflows increase secret exposure because developers often paste credentials into prompts or generated snippets, and those values can then appear in code, scripts, logs or historical commits. Once that happens, the exposure outlives the original change. Continuous scanning and immediate revocation are necessary because the credential lifecycle is now the real attack surface.
Q: What do organisations get wrong about scanning AI-generated code?
A: The common mistake is treating more scanning as a complete answer. In reality, high-volume findings create noise unless teams can prioritise exploitability, exposure, and business impact. Organisations also miss the governance layer, where AI tools and agents need ownership, permission boundaries, and auditable actions.
Q: How should teams govern AI-suggested dependencies and package trust?
A: Teams should treat AI-suggested dependencies as untrusted until validated. That means checking for typosquatting, malware behaviour, suspicious install scripts and package provenance before installation, then enforcing exact pinning and build-time policy. The goal is to stop hallucinated or malicious packages from becoming an easy supply chain entry point.
Technical breakdown
Why AI-generated code creates repeatable security failure patterns
Large language models generate code by predicting likely continuations from training data, not by reasoning about security outcomes. That means they can produce code that is syntactically correct and functionally plausible while still missing auth checks, token expiry handling, CSRF protection or safe cryptographic choices. The failure is structural: AI optimises for the next likely token, not the surrounding threat model. In practice, this shifts the risk from isolated developer mistakes to repeatable pattern reproduction across many repositories and teams.
Practical implication: treat AI-generated code as a higher-risk input class and scan it for known insecure patterns at every commit.
How AI-assisted workflows expand secrets exposure and secret leakage
AI-assisted development increases the chance that credentials will enter prompts, generated snippets, CI scripts and logs. Once a secret appears in those paths, it can escape through repositories, build systems or historical commits long after the original change. This is especially important for NHI governance because API keys, tokens and service credentials are often the easiest values to paste into an AI prompt and the hardest to track once they spread. The control problem is not just detection, but lifecycle enforcement across all places secrets can surface.
Practical implication: combine continuous secret scanning with automated revocation so exposed machine credentials cannot remain valid after discovery.
Why AI-suggested dependencies create supply chain exposure
AI tools often recommend packages by name, but they do not verify whether those packages are legitimate, malicious, typosquatted or only superficially similar to trusted libraries. That matters because hallucinated or deceptive package names can be turned into a direct supply chain path, especially when developers accept suggestions under time pressure. Standard CVE-driven scanning is not enough when the risk begins before installation. Security teams need package reputation, malware behaviour and dependency graph context, not just version comparison.
Practical implication: validate AI-suggested dependencies with malware and typosquatting checks before they are allowed into the build pipeline.
NHI Mgmt Group analysis
AI-generated code is now a control-design problem, not just a code-quality problem. The article shows that the risk is systematic, with flaws repeating across output patterns rather than appearing as one-off defects. That means organisations cannot rely on review queues built for human pace. The decisive issue is whether security controls operate at AI speed, not whether developers write faster.
Secret exposure becomes an NHI governance problem as soon as AI tools touch credentials. When prompts, generated code or CI scripts can carry API keys, tokens and service credentials, the boundary between application security and non-human identity security disappears. The article supports a named concept here: AI-assisted secret sprawl, where machine credentials leak across prompts, code and pipelines faster than ownership and revocation processes can track. Practitioners need to govern issuance, detection and revocation as one lifecycle.
Pipeline controls matter more than code review when AI output is voluminous and fast. Review-heavy operating models assume developers can slow down enough for humans to inspect what matters. That assumption breaks when AI assistants increase both commit volume and defect density. Security teams should move critical checks left into the IDE and build pipeline, because that is where the organisation still has a chance to block exposure before release.
The supply chain risk from AI-generated code is broader than vulnerable code alone. AI tools can suggest unsafe dependencies, hallucinated package names and maliciously similar packages, which means provenance and package trust become first-class controls. This strengthens the case for policy enforcement around dependency selection, artifact integrity and build-time gatekeeping. The practitioner lesson is simple: if the build can accept AI suggestions uncritically, the attack surface is already expanded.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
AI-assisted secret sprawl: once credentials enter prompts, generated code and CI scripts, ownership and revocation become harder than detection alone. Security teams need to govern machine credentials as a live lifecycle, not as static text that can be found later.
The development model is shifting faster than many AppSec programmes can retool, which means the most effective control is increasingly the one that blocks exposure before code leaves the IDE or pipeline. Continuous scanning, policy enforcement and dependency trust checks have to operate as one system, not as separate review layers.
For practitioners
- Enforce SAST on every AI-assisted commit Scan every commit, not just pull requests, and tune findings for the failure classes AI tools repeatedly introduce: missing authentication, CSRF, SSRF, insecure deserialisation and hardcoded credentials.
- Add continuous secrets scanning and automatic revocation Cover repositories, pipeline logs, historical commits and container images, then revoke exposed API keys, tokens and service credentials immediately after detection.
- Block untrusted dependencies before install Require malware detection, typosquatting analysis and exact version or digest pinning for dependencies suggested by AI tools, especially where package names are unfamiliar or newly introduced.
- Move guardrails into the IDE and pipeline Use build-time blocks for new critical findings, new secrets and policy-breaking packages so developers cannot treat security alerts as optional suggestions.
- Monitor AI coding tool behaviour for anomalies Watch for unexpected workflow file changes, unusual network calls from coding assistants and abnormal access to secrets stores from developer workstations.
Key takeaways
- AI-generated code is not simply faster code. It is a higher-volume source of repeatable security defects, secret leakage and risky dependency choices that legacy review models struggle to absorb.
- The article’s evidence points to a widening gap between development velocity and control coverage, especially where secrets, build pipelines and package trust are concerned.
- The practical response is to move security controls earlier, automate revocation and enforce build-time guardrails so AI output cannot bypass governance by speed.
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 CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | AI-assisted code is leaking API keys, tokens and other machine credentials into repos and pipelines. |
| NHI-07 — Long-Lived Secrets | The article’s core risk is exposed secrets remaining valid long enough to be exploited. | |
| NHI-03 — Vulnerable Third-Party NHI | AI-suggested dependencies can introduce compromised or deceptive third-party packages into builds. | |
| Recommendation — Scan code, logs and build output for leaked NHI secrets and revoke exposed credentials immediately. Shorten secret lifetime and enforce automatic rotation whenever AI workflows handle credentials. Validate third-party packages before use and block dependencies with suspicious provenance or behaviour. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes credential exposure and downstream data or access theft paths. |
| Recommendation — Map AI-assisted secret exposure to credential access and exfiltration techniques in detection content. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | AI tools should not inherit broad access to secrets, repos or pipelines by default. |
| Recommendation — Restrict AI coding tools to the minimum repository and secrets access needed for their task. | ||
Key terms
- AI-assisted Secret Sprawl: The spread of machine credentials through prompts, generated code, build scripts and logs as AI tools accelerate development. It becomes a governance problem when ownership, rotation and revocation no longer keep pace with where secrets are copied or persisted.
- Agentic coding assistant: An AI-assisted development tool that can decompose tasks, choose actions, and execute parts of a workflow inside the editor. In security terms, it behaves like a non-human identity when it can access code, tools, and terminals on behalf of a developer, so governance must cover its runtime behaviour.
- 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.
- Supply Chain Trust: Supply chain trust is the confidence that the people, software, hardware, and services used to build and run a system are authentic, intact, and behaving as expected. In security practice, it depends on verifying provenance, integrity, dependencies, and update paths across suppliers, build systems, and operational handoffs.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to govern machine credentials, secrets and access at the same pace as modern development.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org