Securing GenAI code requires trust controls beyond scanning

At a glance

What this is: Veracode says GenAI coding tools are accelerating software delivery while also increasing vulnerable code, security debt, and supply chain exposure.

Why it matters: IAM, PAM, and security teams should treat AI-assisted development as a governance problem because trust, policy enforcement, and dependency control now need to happen before code reaches production.

By the numbers:

• AI coding assistants introduce known security vulnerabilities directly into production codebases in 45% of cases.
• The 2026 State of Software Security report shows an 20% YoY increase in highly-exploitable and highly-severe security debt.
• Security pass rates have remained stubbornly flat at approximately 55%.

Context

GenAI code security is now a governance problem, not just a code-quality problem. When AI assistants can produce compilable code faster than teams can review, validate, and remediate it, the risk shifts from obvious defects to accumulated security debt that stays hidden until release.

The security gap is especially relevant to identity and access programmes because modern development depends on secrets, dependencies, CI/CD permissions, and runtime trust decisions. If those controls are weak, AI-assisted delivery can expand the blast radius of vulnerable code long before traditional review catches up.

Key questions

Q: What control gap makes AI-generated code harder to trust before release?

A: The gap is that generation speed now outruns review, testing, and remediation capacity. AI-assisted code can be syntactically correct and still carry exploitable flaws, unsafe dependencies, or hidden trust assumptions. Security leaders need release gates that require evidence of policy compliance, not just a completed scan.

Q: Why do AI coding agents increase supply-chain risk?

A: AI coding agents can choose tooling, install packages, and edit lock files in ways that may bypass the controls humans expect in a managed environment. That widens the blind spot around untracked software and makes package provenance harder to enforce. The practical response is to restrict agent permissions, inventory their workspaces, and review their install behaviour like any other privileged automation.

Q: What are the signs that AI-driven security automation is creating hidden technical debt?

A: Hidden technical debt often appears when teams need custom code for every new use case, spend heavily on consulting to keep workflows running, or see time-to-value slip as the environment changes. Another warning sign is a rigid platform that cannot adapt to local processes without breaking downstream integrations. Those conditions raise total cost of ownership and slow operational improvement.

Q: How should security teams govern AI-assisted coding tools in the IDE?

A: They should treat AI-assisted coding tools as part of the control surface, not just a developer convenience. That means applying policy at the point of code generation, controlling which plugins and packages can run, and logging every allow, block, and override with identity and context. The goal is to keep untrusted code from becoming trusted software.

Technical breakdown

Why AI-generated code increases security debt

Large language models optimise for plausibility and developer usefulness, not for secure design. That means the code they generate can be syntactically correct, test cleanly, and still embed injection flaws, unsafe defaults, weak error handling, or insecure dependency choices. The core mechanism is a mismatch between code generation speed and control speed: the model can create risk faster than security and engineering teams can inspect, prioritise, and remediate it. In practice, that creates a backlog of latent defects that behaves like compound interest. Practical implication: shift security checks into the moment code is written, not after features are merged.

Practical implication: move validation as far left as possible and treat AI output as untrusted until proven safe.

How hallucinated dependencies become supply chain risk

AI assistants often suggest third-party packages to satisfy a prompt, but some of those package names are fabricated or poorly validated. Attackers can register those names in public repositories and seed them with malicious code, turning a helpful suggestion into a software supply chain compromise. This is not a generic dependency issue. It is a trust failure in the path from generated recommendation to installed artifact, where developers may accept a plausible package name without independent verification. Practical implication: every AI-suggested dependency needs inventory, reputation, and provenance checks before it enters the build.

Practical implication: verify provenance before dependency installation and block unknown packages by policy.

Why scan-based assurance is no longer enough for GenAI code

Static and dynamic testing remain necessary, but they do not answer the bigger question of whether software is safe enough to ship. AI-assisted development changes the control objective from flaw detection to trust evidence. A scan can show that a vulnerability exists, but it cannot by itself prove that policy, dependency provenance, remediation status, and runtime exposure are all under control. That is why organisations need governance across the full delivery chain, from developer prompts to pipeline enforcement to release decisions. Practical implication: define shipping criteria that require evidence, not just scan completion.

Practical implication: tie release approval to policy evidence, dependency integrity, and verified remediation, not scan volume.

Threat narrative

Attacker objective: The attacker objective is to get malicious or vulnerable code accepted into the software supply chain so it reaches production with legitimate developer trust.

1. Entry begins when developers use AI coding assistants to generate application code or recommend dependencies inside ordinary build workflows.
2. Credential and supply chain exposure follows when insecure code patterns, hallucinated packages, or weakly vetted libraries are accepted into repositories and pipelines.
3. Escalation occurs as those flaws propagate into production, where exploitable code, hidden backdoors, or malicious dependencies expand attack surface and trust failure.
4. Impact is the accumulation of security debt that increases exploitability, slows remediation, and raises the likelihood of production compromise.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.

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

Trust is now the governing control, not scanning volume. GenAI code changes the security problem from finding bugs after the fact to proving that generated code, suggested dependencies, and pipeline actions are acceptable before release. That is a control model shift, not a tooling tweak. If software can be generated at machine speed, governance must shift to machine-speed evidence. Practitioners should treat trust as a release gate, not a post-build report.

Security debt is becoming a lifecycle liability in software delivery. The article’s 45% figure and the flat pass-rate trend point to a structural mismatch between generation speed and remediation capacity. This is not just about more findings. It is about compounding exposure that widens as code volume grows faster than review, testing, and repair. Security leaders should expect backlog inflation unless they change where controls live in the delivery chain.

Hallucinated dependency risk is the clearest identity bridge in GenAI code security. The trust problem is not only code quality; it is also whether a prompted package recommendation can be treated as a valid software identity. Unverified dependencies behave like unmanaged machine identities because they enter the environment with assumed legitimacy and uncertain provenance. Practitioners should govern package trust with the same discipline they apply to privileged access and secrets lifecycle controls.

Agent-generated development requires policy that executes, not policy that is read. The article’s call for systems to govern agents reflects the reality that developer guidance alone will not keep pace with AI-assisted delivery. Security rules need to be enforced in IDEs, pipelines, and release gates where decisions actually happen. Teams that keep relying on manual review will find that their process assumptions no longer match the way code is produced.

Software trust is becoming a cross-domain governance issue. GenAI code touches application security, supply chain integrity, secrets handling, and access control in one workflow. That makes it relevant to IAM, PAM, and NHI teams as well as AppSec leaders. The practitioner takeaway is simple: if AI can influence what gets built, what gets installed, and what gets deployed, then governance must cover each of those decision points.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
• Read next: AI Coding Agents Security Guide

What this signals

GenAI code security debt: the real problem is not whether AI can generate working code, but whether organisations can prove that generated code is safe enough to ship. That shifts the control point from scanning output to governing inputs, dependencies, and release authority across the SDLC.

The next pressure point is trust in the software supply chain. Package provenance, secret handling, and pipeline permissions now sit on the critical path for AI-assisted development, so teams that still treat AppSec as a post-build activity will continue to accumulate hidden exposure.

For practitioners

• Embed security policy in developer workflows Enforce secure coding and dependency rules directly in the IDE and CI/CD path so AI-generated snippets are checked before merge, not after release.
• Block untrusted AI-suggested packages Require provenance, reputation, and vulnerability checks for every new package suggested by an AI assistant before it can enter the build.
• Treat release approval as evidence-based Define shipping criteria that require proof of remediation, dependency integrity, and policy compliance rather than relying on scan completion alone.
• Review secrets and credential handling in generated code Check AI-produced code for hardcoded credentials, weak authentication flows, and unsafe logging paths before it reaches shared branches.
• Govern AI-assisted development as a control plane Map who can prompt, approve, install, and deploy AI-generated changes so that access, accountability, and release authority are explicit.

Key takeaways

• AI coding assistants are accelerating feature delivery while also increasing the volume of vulnerable code that reaches production.
• The evidence points to a security debt problem, not just a code quality problem, because remediation capacity is not scaling with generation speed.
• Teams need release criteria that prove trust, policy compliance, and dependency integrity before AI-assisted code is allowed into production.

Key terms

• GenAI Code Security: GenAI code security is the discipline of governing code produced by generative AI so that it is not only functional, but also safe to ship. It combines model evaluation, workflow verification, remediation prioritisation, and policy controls around where AI-generated code is allowed to enter production.
• Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
• Software Supply Chain Risk: Software supply chain risk is the chance that code, build, deployment, or dependency paths are altered in ways that affect downstream systems. For AI code assistants, this risk rises when the tool can change source, trigger pipelines, or influence infrastructure definitions.
• Trust Control: A trust control is any mechanism that decides whether a user, session, or action should be allowed to proceed on a platform. In fraud-heavy environments, it combines identity signals, behavioural signals, and risk scoring to determine whether the current actor matches the expected account context.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to modern software delivery and AI-assisted workflows.