AI-generated code is widening application security risk at scale

At a glance

What this is: AI-generated code is accelerating software delivery while introducing a measurable security gap, with Veracode finding that nearly half of generated code contains flaws.

Why it matters: This matters because IAM, NHI, and broader security teams will increasingly inherit applications and services built faster than traditional review, raising governance pressure around code review, secrets handling, and runtime trust.

By the numbers:

• 45% of AI-generated code contains security flaws.
• 97% of developers have used AI tools.
• Only 55% of AI-generated code was secure.
• Cross-site scripting code failed security checks 86% of the time.

👉 Read Veracode's analysis of AI-generated code security risks

Context

AI-generated code is now part of mainstream software delivery, which means security teams are no longer assessing only human-written logic. The governance problem is that generation speed can outpace review, testing, and ownership, especially when teams rely on prompts to produce code that looks correct but has hidden security defects.

For identity and access programmes, the intersection is practical rather than theoretical. AI-assisted development can introduce unsafe authentication flows, weak input handling, and exposed secrets into applications that later connect to IAM, secrets management, and non-human identity controls. That makes secure code review, policy enforcement, and runtime validation part of identity governance as much as application security.

The starting position described here is now typical rather than exceptional: most development teams are already using AI tooling, while many still depend on manual review habits designed for slower release cycles.

Key questions

Q: How should security teams govern AI-generated code in production environments?

A: Security teams should treat AI-generated code as normal production code with extra provenance risk. Require architectural review, test coverage, static analysis, and approval before merge. Then bind the agent and the build pipeline to least privilege, short-lived credentials, and complete audit logging so implementation speed does not outrun control.

Q: Why do AI coding assistants create security debt even when code compiles?

A: Because compilation only proves syntax, not safety. AI models can produce code that works functionally while still introducing injection flaws, unsafe error handling, weak authentication, or risky dependencies. Security debt grows when teams accept that output without verification, since every unchecked suggestion can become a future remediation item.

Q: What do security teams get wrong about AI-generated code risk?

A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows. The more important control point is the moment the agent is allowed to initiate the action. If that step is not governed, testing becomes a detection layer rather than a prevention layer.

Q: How can organisations reduce risk from AI tools without banning them?

A: Organisations can reduce risk by approving specific tools, limiting the data classes they may access, and enforcing scope restrictions for high-risk integrations. That approach supports productivity while keeping sensitive data out of unmanaged systems. The objective is controlled enablement, not unrestricted adoption.

Technical breakdown

Why AI-generated code can look correct but still be insecure

AI coding tools optimise for syntactic plausibility and local task completion, not for application-wide security reasoning. They can produce code that compiles and behaves as requested while missing context about trust boundaries, sanitisation requirements, authentication state, or data sensitivity. That is why a model can generate secure-looking output while still embedding SQL injection, XSS, or cryptographic weaknesses. The core limitation is not just code quality, but the absence of true semantic understanding of the surrounding system.

Practical implication: AppSec teams should treat generated code as untrusted input until it passes automated and human security review.

How security debt accumulates in AI-assisted development

Security debt grows when insecure code is merged quickly, then remains in production longer than anyone expects. In AI-assisted workflows, that debt can compound because vulnerable snippets are copied across repositories, embedded into prototypes, and reused in production paths without clear origin tracking. Remediation becomes harder when no single developer can explain the design decision behind the flaw. The result is not just more bugs, but weaker accountability for fixing them.

Practical implication: organisations need traceability for AI-generated code, including review records and ownership for remediation.

Why runtime and dependency controls still matter

Static scanning alone is not enough because AI-generated code can introduce issues that only appear when the application runs, such as unsafe data handling or insecure dependency behaviour. AI tools may also suggest libraries or packages that are outdated, vulnerable, or even non-existent, creating supply chain exposure alongside code defects. Runtime testing, dependency verification, and policy checks therefore remain necessary controls, especially in release pipelines that move quickly from prompt to production.

Practical implication: teams should combine SAST, DAST, and software composition analysis rather than relying on a single gate.

Threat narrative

Attacker objective: The attacker objective is to exploit insecure AI-assisted code paths to gain data access, execute malicious input, or compromise connected systems.

1. Entry occurs when developers accept AI-generated code into the development workflow without sufficient security review, often because the output appears functionally correct.
2. Escalation follows when insecure patterns are copied into application logic, API handling, or dependency choices, expanding the attack surface across multiple components.
3. Impact occurs when those flaws reach production and enable exploitation such as injection, data exposure, or compromise of downstream systems that trust the application.

NHI Mgmt Group analysis

AI-generated code is becoming an application security governance problem, not just a developer productivity issue. When nearly half of generated code contains flaws, the question shifts from whether AI helps teams move faster to whether review and control systems can keep pace. AppSec, IAM, and platform teams need joint ownership because insecure code often becomes the entry point for credential abuse, unsafe trust decisions, and secret exposure.

Security debt is the right concept for understanding AI-assisted coding risk. The real issue is not one flawed snippet but the accumulation of unresolved defects across repositories, pipelines, and deployments. Once insecure generation is normalised, remediation slows because teams cannot easily attribute ownership or reconstruct intent. The practitioner conclusion is that code provenance and review traceability now matter as much as scan coverage.

Context-aware controls are more defensible than tool-only trust. Static analysis, dynamic testing, and dependency validation each catch different failure modes, but none of them should be treated as a substitute for secure design review. For identity-sensitive applications, the control gap is often in the handoff between generated code and downstream authentication or secrets logic. That means security policy has to follow the code through the lifecycle, not stop at the prompt.

AppSec muscle memory will degrade if teams let AI become the primary implementation layer. Developers still need to understand why input validation, secret handling, and least privilege matter, even when a model writes the code. Without that understanding, organisations will ship more software but lose the ability to reason about where trust is being introduced. The practical conclusion is to use AI as a drafting aid, not as a substitute for secure engineering judgement.

What this signals

AI-assisted development will force security teams to move from code review as a checkpoint to code governance as a lifecycle discipline. The practical shift is toward policies that follow generated code from prompt to production, including review evidence, dependency validation, and runtime verification. For teams that also manage application identities and secrets, this is where secrets handling and access control stop being separate concerns.

Security teams should expect AI-generated code to increase the volume of weak trust decisions in downstream systems. That includes hardcoded credentials, unsafe handling of tokens, and brittle assumptions about who or what is authorised to act. In identity-heavy environments, the risk is not only vulnerable code but vulnerable delegation paths that later feed IAM and NHI controls.

Code provenance is becoming a governance signal. If teams cannot tell which parts of an application were generated, reviewed, and approved, they cannot reliably assess where security responsibility begins or ends. The most durable response is to combine engineering controls with policy, so AI output is governed rather than merely scanned.

For practitioners

• Scan AI-generated code before merge Integrate SAST into pull request workflows so generated code is checked before it reaches main branches or release candidates.
• Test running applications for runtime flaws Use DAST to catch injection, output handling, and behavioural issues that static analysis may miss once the application is executing.
• Validate every suggested dependency Apply software composition analysis and package allowlisting so AI tools cannot silently introduce vulnerable or non-existent libraries into builds.
• Document AI usage and review decisions Keep audit trails for prompts, generated code, reviewer approval, and remediation actions so teams can trace accountability when defects appear later.
• Train developers to recognise insecure patterns Build secure coding refreshers around common AI failure modes such as unsafe sanitisation, weak cryptography, and missing access controls.

Key takeaways

• AI-generated code is already creating a measurable application security problem, not a theoretical one.
• The biggest risk is security debt, because vulnerable code can spread faster than teams can assign ownership or remediate it.
• The practical response is layered governance, combining scanning, testing, dependency verification, audit trails, and developer education.

Key terms

• AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.
• 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.
• Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.

What's in the full report

Veracode's full article covers the operational detail this post intentionally leaves for the source:

• The full breakdown of vulnerability patterns across SQL injection, cryptographic failures, cross-site scripting, and log injection.
• The remediation workflow for integrating SAST, DAST, and software composition analysis into AI-assisted development pipelines.
• The developer behaviour and workflow guidance for reviewing generated code without slowing release velocity.
• The case-study detail behind Veracode Fix, including how the vendor describes remediation timing and developer acceptance.

👉 Veracode's full post covers the vulnerability breakdown, remediation workflow, and developer guidance in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It helps practitioners connect identity controls to the broader security and development programmes they run.