AI-generated code is exposing secrets faster than AppSec can catch

At a glance

What this is: This is an AppSec analysis of how AI-generated code amplifies vulnerabilities, secret exposure, and dependency risk across the SDLC.

Why it matters: It matters to IAM practitioners because AI-assisted development increases the chances that secrets, tokens, and privileged pipeline access are exposed or misused before conventional controls can react.

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.
• CSA research found that 62% of AI-generated code contains design flaws or known vulnerabilities, even when developers use the latest foundational models.
• The CSA research note on vibe coding security puts AI-assisted secret exposure at 3.2% of commits versus 1.5% for human-only commits.

👉 Read Xygeni's analysis of AI-generated code risk and AppSec controls

Context

AI-generated code is not just a productivity issue. It changes the risk profile of application development by increasing the volume of code, the speed of commits, and the likelihood that insecure patterns or secrets reach repositories before humans can validate them. In practice, that creates a governance problem for AppSec, IAM, and NHI teams because the attack surface now includes credentials, tokens, and pipeline access embedded in AI-assisted workflows.

The core failure is that traditional controls were designed for human-paced review and familiar vulnerability classes. AI-assisted development introduces systematic defects, including missing authentication, weak authorization, exposed secrets, and unsafe dependencies, at a pace that makes point-in-time review too slow. For identity teams, the intersection is direct: secrets, service accounts, and CI/CD credentials are increasingly being handled in environments where lifecycle control is weakest.

Key questions

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. The right response is broad secrets discovery, fast remediation, and ownership mapping across repositories, pipelines, chat systems, and endpoints. If the organisation cannot inventory where a secret exists, it cannot safely rotate or revoke it.

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. That combination makes secrets more likely to appear in code, logs, or old commits, and those secrets can remain valid long after discovery.

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. A complete control needs continuous repository scanning, history coverage, and revocation workflows tied to detection.

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.

Technical breakdown

Why AI-generated code creates systematic AppSec failures

Large language models generate code by pattern completion, not by reasoning about application security. That means they reproduce common insecure constructs that appear statistically normal in training data, including missing auth checks, weak session handling, and hardcoded secrets. The issue is not random defect generation. It is repeatable structural drift toward working code that is not safe by default. Security tools tuned for conventional bug classes can miss these patterns when the code is functionally correct but architecturally unsafe.

Practical implication: tune SAST and code-quality gates for security-relevant AI failure modes, not just syntax or common CVEs.

How secrets leak through AI-assisted development workflows

Secrets exposure increases when developers paste credentials into prompts, reuse snippets from generated code, or move too quickly to review output. The result is often a secret that appears in application code, build scripts, logs, or historical commits. Pre-commit hooks help, but they do not cover every path, especially web-based editors, CI-generated scripts, or legacy branches. Continuous detection and automated revocation matter because exposed secrets remain exploitable long after the commit that introduced them.

Practical implication: combine repository-wide secrets scanning with history coverage and automated revocation, not just pre-commit checks.

Why AI-suggested dependencies need malware-aware SCA

AI assistants often recommend packages without reliable supply chain validation, which creates room for typosquatting, slopsquatting, and malicious install scripts. Standard CVE-first scanning is not enough because a package can be dangerous before any published vulnerability exists. Behavioural inspection of install scripts, dependency graph analysis, and reachability-aware prioritisation are all needed to decide whether a suggested dependency is actually safe to use in production pipelines.

Practical implication: treat AI-suggested packages as untrusted until malware checks, naming analysis, and reachability filtering all pass.

Threat narrative

Attacker objective: The attacker aims to turn AI-speed development mistakes into reusable access, code execution, or downstream compromise across the software supply chain.

1. Entry occurs when an AI-assisted workflow introduces a secret, unsafe dependency, or insecure code pattern into the repository or build pipeline.
2. Credential access follows when exposed tokens, API keys, or service-account secrets are harvested from commits, logs, history, or generated artefacts.
3. Escalation and lateral movement happen when those credentials grant broader pipeline, repository, or cloud access than the original code change required.
4. Impact is data theft, environment compromise, or supply chain propagation through trusted development systems.

NHI Mgmt Group analysis

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.

Continuous secret detection is now an identity control as much as an application control. When credentials appear in prompts, generated code, or pipeline logs, the issue is no longer only vulnerability management. It becomes NHI exposure and access lifecycle failure because the secret itself is the identity. That makes revocation speed, historical scanning, and branch-wide coverage critical. The practitioner conclusion is that secrets management and AppSec must operate as one control plane.

AI-suggested dependencies expand the supply chain attack surface in a way static review does not fully capture. Slopsquatting and typosquatting work because developers assume a recommended package is legitimate if it compiles and installs. That creates a new category of security debt, which is dependency trust debt, where the risk is inherited before any vulnerability is published. The practitioner conclusion is to classify AI-suggested packages as untrusted inputs until proven otherwise.

Behavioral monitoring is becoming necessary for agentic development tools. Once coding assistants can write to repos, trigger pipelines, or query secrets, they inherit privileges that need their own oversight. Traditional developer telemetry is too coarse to distinguish normal editing from suspicious tool-driven activity. The practitioner conclusion is to apply least privilege and anomaly detection to AI coding tools the same way teams would for any other high-trust automation.

Secret sprawl is the underlying failure mode that makes AI-assisted exposure so persistent. The article’s findings reinforce a broader pattern that NHIMG sees repeatedly: secrets are scattered across code, logs, branches, and environments faster than teams can centralise control. That fragmentation aligns with the logic of the Secret sprawl challenge: secrets proliferate faster than remediation workflows, and practitioners end up managing exposure after the fact. The practitioner conclusion is to govern secret creation, storage, and revocation as one lifecycle.

What this signals

Secret sprawl is now a delivery-speed problem, not just a detection problem. AI-assisted coding compresses the time between credential creation and credential exposure, which means teams need revocation and history scanning to operate at the same cadence as development. The relevant benchmark is not whether a secret was found eventually, but whether it could be invalidated before reuse. For teams building governance around that lifecycle, the Guide to the Secret Sprawl Challenge is a useful reference point.

AppSec and IAM are converging around the same control failure. When AI code embeds tokens, service-account keys, or pipeline credentials, the problem becomes identity lifecycle control in a software delivery context. That is why short-lived credentials, automated revocation, and better secret provenance matter more than periodic review alone. Security teams should think about exposed credentials as an access management event, not only a code-scanning event.

For practitioners

• 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.
• Treat AI-suggested dependencies as untrusted inputs Require malware checks, typosquatting analysis, and reachability-filtered CVE review before allowing packages recommended by AI tools into the build.
• Limit and monitor agentic tool privileges Restrict repository write access, pipeline trigger permissions, and secrets access for AI coding tools, then monitor for unusual network calls or workflow changes.

Key takeaways

• AI-generated code increases insecure pattern density, secret leakage, and dependency risk faster than conventional AppSec workflows were built to absorb.
• The most important failure is not the presence of flaws alone, but the speed at which secrets and unsafe packages move into trusted delivery systems.
• Practitioners need continuous scanning, automated revocation, and policy enforcement at write time and build time to keep pace with AI-assisted development.

Key terms

• AI-assisted Code Generation: AI-assisted code generation is the practice of using a model to draft or modify source code for a developer. It can speed delivery, but it does not verify correctness, security, or compliance, so the output still needs the same review, testing, and change control as human-written code.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Slopsquatting: Slopsquatting is a supply-chain attack that exploits hallucinated package names suggested by AI systems. An attacker registers the invented name in a public registry and waits for a developer or build pipeline to install it. The risk sits at the intersection of model error, dependency trust, and software delivery speed.
• Agentic Development Tool: A coding assistant that can take actions in an environment, such as writing to repositories, triggering pipelines, or querying secrets. Once a tool can act rather than merely suggest, it needs explicit privilege boundaries, monitoring, and lifecycle governance like any other high-trust automation.

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.

👉 Xygeni's full post covers SAST tuning, secrets scanning, dependency checks, and agentic monitoring in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in practical terms. It helps security practitioners connect identity lifecycle controls to modern development and deployment risk.