AI-generated code is widening risk velocity in application security

At a glance

What this is: This is Veracode’s analysis of how AI-generated code is changing application security by increasing security debt, risk velocity, and the gap between code production and remediation capacity.

Why it matters: It matters because IAM, NHI, and broader security teams are all dealing with the downstream effects of faster software change, including exposed secrets, weak authorization boundaries, and controls that do not scale with developer throughput.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Veracode's analysis of AI-generated code and application security risk

Context

AI-generated code is changing application security because the volume of code entering the SDLC is rising faster than many organisations can review, test, and remediate it. The primary application security issue is not that AI always writes broken code, but that it increases risk velocity, making security debt compound faster than traditional controls can absorb. That is now a governance problem for application teams, identity teams, and security leaders alike.

The article also intersects with identity security where generated code handles authentication, access checks, secrets, and service-to-service trust. When AI helps produce code with hard-coded secrets, weak authorization logic, or poor boundary handling, it directly affects NHI governance, IAM enforcement, and the integrity of machine identity controls. In that sense, the starting position described here is no longer atypical; it is becoming common in organisations that have adopted AI coding tools without changing their control model.

Key questions

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

A: Security teams should treat AI-generated code as a controlled identity event, not just a development artifact. Require human approval, traceable authorship, scoped workload identities, and evidence of intent before production promotion. The goal is to preserve provenance and limit blast radius when generated logic behaves unexpectedly.

Q: Why do AI-generated code changes increase application security risk?

A: AI-generated code can increase risk because it accelerates output faster than review, testing, and secret hygiene can keep up. The issue is not only flawed logic. It is also the possibility that tokens, credentials, unsafe dependencies, or insecure defaults are reproduced at scale across the delivery pipeline.

Q: What do security teams get wrong about secure-by-design AI governance?

A: They often treat secure-by-design as a policy label instead of an enforceable operating model. Real security requires least privilege, logging, data minimisation, and output controls that can be tested and audited. Without those controls, secure-by-design becomes a statement of intent rather than proof that the AI stays inside approved boundaries.

Q: How do organisations know whether AI-assisted development is staying secure?

A: Measure the share of AI-generated changes that pass security checks on the first review, the number of risky dependencies blocked before install, and the time taken to remediate findings that escaped into branches or test environments. If those numbers worsen as adoption grows, the programme is scaling risk faster than control coverage.

Technical breakdown

Why AI-generated code increases risk velocity

AI coding tools optimise for plausibility, speed, and syntactic correctness. That means they can produce code that compiles and passes tests while still introducing insecure patterns such as missing input validation, weak access checks, or hard-coded secrets. The technical problem is not only vulnerability generation, but the mismatch between code production rate and the organisation’s ability to review and remediate. Once that gap opens, risk accumulates as security debt across applications, dependencies, and deployment pipelines.

Practical implication: measure remediation throughput against code throughput, not just vulnerability counts.

How insecure patterns survive in AI-assisted development

Large language models learn from mixed-quality training data, so they can reproduce common anti-patterns when prompted loosely. In application security terms, that means familiar issues such as SQL injection, cross-site scripting, insecure direct object references, and exposed secrets can be recreated at scale. The deeper failure mode is missing application context. The model does not know tenant boundaries, data classification, or the authorisation model of the target system, so it often omits controls that are specific to the environment.

Practical implication: enforce policy checks and secure reference patterns before generated code reaches review or merge.

Why the software supply chain becomes a multiplier

AI-assisted development increases reliance on packages, snippets, and generated dependencies, which expands the software supply chain attack surface. Some suggestions will be outdated; others may be vulnerable; some may not even exist and can create a path to typosquatting or malicious dependency adoption. This is why secure development can no longer be treated as a code-only issue. It must include dependency governance, composition analysis, and controls that understand how generated code changes the trusted software bill of materials over time.

Practical implication: tie composition analysis and dependency approval to every AI-assisted build path.

Threat narrative

Attacker objective: Attackers aim to turn AI-assisted development speed into a durable exposure surface by exploiting insecure code, exposed secrets, and supply chain weakness before defenders can remove them.

1. Entry occurs when AI-generated code introduces insecure patterns or hard-coded secrets into active application workflows, often because developers accept plausible output under delivery pressure.
2. Escalation happens when those flaws are promoted into production, where attackers can abuse weak authorisation, exposed credentials, or vulnerable dependencies to reach adjacent systems.
3. Impact follows when the organisation accumulates enough security debt that remediation slows, attack surface expands, and business systems become easier to compromise or disrupt.

NHI Mgmt Group analysis

AI-generated code is turning application security into a risk velocity problem. The core issue is no longer whether insecure code can be found. It is whether organisations can detect and remove it faster than AI-assisted development creates it. That shifts the centre of gravity from point-in-time review to continuous control, especially where secrets, access logic, and dependency decisions are embedded directly into code. Practitioners should treat security debt as an operational metric, not an abstract concern.

Security debt is now an engineering governance issue, not just a vulnerability management issue. The article is right to frame insecure output as compounding debt because every unreviewed snippet becomes future attack surface. This is especially relevant to identity and access logic, where generated code often touches authentication, session handling, API authorisation, and service credentials. The named concept here is risk velocity, which describes how quickly new exposure is created relative to the organisation’s fix rate. Practitioners should measure the gap, not just the backlog.

Identity controls are part of the application security response, not a separate lane. AI-generated code often handles service-to-service authentication, secrets retrieval, and token use, which means NHI governance is directly implicated when development accelerates. If service accounts, API keys, and certificates are embedded in code paths without lifecycle control, the security problem becomes identity sprawl as much as code quality. That makes secret inventory, workload identity, and least-privilege service design essential to reducing the attack surface. Practitioners should connect SDLC controls to identity governance.

Secure-by-design fails when it remains guidance instead of enforced infrastructure. The article’s strongest point is that training alone cannot outcompete incentives, speed, and tool-generated ambiguity. In practice, secure-by-design only scales when policy is executable in pipelines, approved patterns are automated, and remediation is embedded where engineers already work. That aligns with NIST CSF and NIST SP 800-53 thinking, but the operational lesson is simpler. If the secure path is not the easiest path, AI will amplify the insecure one. Practitioners should move policy from documentation into control points.

The market signal is shifting from discovery to governed remediation. AI coding will keep raising code volume, so tools that only surface findings will create more noise than value. The discipline now needs controls that reduce unsafe generation, validate context, and shorten the time between detection and fix. For identity programmes, that means linking code generation, secret governance, and runtime access controls into one operating model. Practitioners should expect security tooling to converge around enforcement, not just reporting.

What this signals

Risk velocity will become a board-visible application security metric. When code volume rises faster than fix capacity, backlogs stop being an operational inconvenience and become evidence that the control model is failing. Security leaders should expect more pressure to show remediation speed, exposure duration, and the percentage of issues fixed inside the developer workflow rather than in downstream tickets.

Identity and application security are converging at the point of code creation. AI-assisted development increasingly touches secrets, service accounts, token handling, and authorisation logic, so NHI governance cannot sit outside engineering controls. The programme signal is clear: workload identity, secret scanning, and least-privilege service design need to move closer to the SDLC if the organisation wants to reduce exposure instead of simply documenting it.

Security debt will matter more than raw vulnerability counts. A team can tolerate some findings if it can fix them quickly, but it cannot tolerate a growing population of unremediated issues that AI keeps replenishing. The practical shift is toward governed remediation, where pipeline enforcement, composition analysis, and inline fixes reduce the time a flaw remains exploitable.

For practitioners

• Enforce policy at the code generation boundary Block insecure patterns before merge by using approved templates for authentication, access checks, logging, and secret handling in AI-assisted workflows. Make policy executable in CI and agent workflows rather than leaving it as written guidance. Use the control path that catches hard-coded secrets and missing authorisation early.
• Measure risk velocity, not just vulnerability counts Track how many issues are introduced per release, how long they remain open, and whether remediation throughput keeps pace with AI-driven code production. Pair those metrics with backlog age and fix success rate so security debt is visible as a programme-level signal.
• Tie secrets governance to the SDLC Inventory where API keys, tokens, and certificates can be introduced by generated code, then require secret scanning, rotation, and workload identity substitution before deployment. This is especially important where developers use AI to scaffold service integrations.
• Reduce dependency trust in AI-assisted builds Require composition analysis and allow-listed dependency sources for any pipeline that accepts generated code. Review unusual package suggestions, non-standard libraries, and changes to the software bill of materials before they become production defaults.
• Make remediation inline and contextual Surface precise fixes inside the developer workflow so teams can accept, adjust, or reject safe changes without leaving the IDE or pipeline. The goal is to reduce the gap between finding and fixing, which is where security debt accumulates.

Key takeaways

• AI-generated code is not just a productivity issue, because it can increase application security exposure faster than teams can absorb it.
• The most telling signal is risk velocity, which measures how quickly new security debt is created compared with how quickly it is removed.
• Practitioners should treat secrets governance, dependency control, and inline remediation as part of the same operating model as AI-assisted development.

Key terms

• Risk Velocity: Risk velocity is the rate at which an organisation creates new exposure compared with the rate at which it removes it. In application security, it is a better indicator of control health than vulnerability count alone because it captures whether code production is outrunning remediation capacity.
• 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.
• Secure-by-Design: Secure-by-design means security requirements are built into the development process rather than added after release. The practical aim is to define minimum acceptable controls early, then enforce them consistently so products cannot ship without passing baseline security checks.
• 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.

What's in the full article

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

• Specific examples of insecure code patterns that AI tends to reproduce in developer workflows
• The article's discussion of how organisations should rethink shift-left when code production outpaces review capacity
• Veracode's perspective on how AI can also help generate patches and guide remediation
• The broader argument for treating secure-by-design as an engineering platform decision rather than a campaign

👉 The full Veracode article expands on risk velocity, security debt, and the future of secure-by-design engineering

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle control. It is designed for practitioners who need to connect identity governance to modern engineering and security operations.