Notifications
Clear all
Topic starter
20/08/2026 5:53 pm
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.
NHIMG editorial — based on content published by Xygeni: AI-generated code is exposing secrets faster than AppSec can catch
By the numbers:
- The Georgia Tech Vibe Security Radar project recorded 35 new CVEs in March 2026 alone directly attributable to AI coding tools, up from 6 in January.
Questions worth separating out
Q: How should security teams handle secrets in AI-generated code?
A: Security teams should treat AI-generated code as another source of credential exposure, not as a special case.
Q: Why do AI-assisted development workflows increase secret exposure risk?
A: They increase exposure because developers move faster, paste more context into prompts, and review output for function before security.
Q: What breaks when organisations rely on pre-commit hooks alone for secrets protection?
A: Pre-commit hooks miss web-based editors, CI-generated scripts, legacy branches, and any workflow where the secret is created after the developer’s local check.
Practitioner guidance
- Enforce SAST on every commit Run security scanning on each commit, not only on pull requests, and tune rules for AI-generated failure modes such as missing auth, SSRF, CSRF, and hardcoded credentials.
- Add repository-wide secrets scanning with history coverage Scan active branches, full commit history, and pipeline logs so secrets introduced by AI-assisted workflows are found even after they leave the current code path.
- Automate secret revocation on detection Tie secrets findings to immediate invalidation of exposed tokens, API keys, and certificates because the exposure window can be short enough for attacker use within hours.
What's in the full article
Xygeni's full research covers the operational detail this post intentionally leaves for the source:
- Benchmark details behind the 100% true positive rate and 16.7% false positive rate claim for Xygeni SAST.
- Detection coverage for more than 800 secret types across repositories, pipeline logs, IaC files, and container images.
- The Malware Early Warning engine and suspect dependency analysis used to detect typosquatting and suspicious install scripts.
- IDE and pipeline workflow examples showing how DevAI, SCA, and secrets scanning fit into one development session.
👉 Read Xygeni's analysis of AI-generated code risk and AppSec controls →
AI-generated code and secrets exposure: are your controls keeping up?
Explore further
20/08/2026 6:32 pm
AI-generated code has created a secrets governance problem, not just a code-quality problem. The article shows that secret leakage can happen at the pace of AI-assisted development, which means lifecycle controls must move closer to creation time. AppSec teams can no longer treat exposed credentials as an isolated developer mistake when the same workflow also touches service accounts, API keys, and CI/CD tokens. The practitioner conclusion is clear: governance has to follow the code path, not the release calendar.
A question worth separating out:
Q: How should teams respond when AI-suggested dependencies are introduced into builds?
A: Block the assumption that a recommended package is safe because it installs cleanly. Require malware-aware SCA, dependency graph review, and reachability filtering, then limit build promotion until the package has been validated against policy.
👉 Read our full editorial: AI-generated code is exposing secrets faster than AppSec can catch
