By NHI Mgmt Group Editorial TeamBased on Veracode: “AI, Application Security, and the Illusion of Control” (March 12, 2026)

TL;DR: AI-generated code is accelerating software delivery while also increasing latent vulnerabilities, dependency sprawl, and remediation backlog pressure, according to Veracode. The critical shift is that insecurity is becoming a throughput problem, so security must scale as a continuous control system rather than a late-stage review step.


At a glance

What this is: Veracode argues that AI-generated code is accelerating delivery while widening latent security debt through insecure patterns, missing context, and dependency sprawl.

Why it matters: This matters because IAM, PAM, and application security teams must treat code generation as a governance and control-scale problem, not just a developer productivity gain.


Context

AI-generated code changes the security problem from isolated defects to sustained control pressure. When code is produced faster than review, testing, threat modelling, and remediation can scale, security debt accumulates even if the output compiles cleanly. In application security, that turns governance into a throughput issue rather than a late-stage quality check.

The identity angle is indirect but real because insecure code often hard-codes trust assumptions into authentication, authorization, secrets handling, and tenant boundaries. For IAM and application security practitioners, the question is no longer whether AI can write code, but whether the surrounding controls can keep pace with the volume and speed of change.


Key questions

Q: What breaks when AI-generated code is reviewed without security gates?

A: What breaks is the assumption that a clean-looking diff is a safe diff. AI-generated code can hide unsafe defaults, dependency issues, and weak validation that basic review misses. Without CI-enforced tests and security checks, the merge process becomes a distribution channel for defects rather than a control point.

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 and engineering teams get wrong about AI-assisted development?

A: They often confuse faster output with better control. AI assistants can generate code quickly, but they do not automatically preserve architecture, reuse patterns, or the source of truth. If teams only measure throughput, they may miss the fact that they are borrowing speed from the future and creating systems that are harder to govern.

Q: How should organisations govern AI tools that analyse source code?

A: Set evidence thresholds, require secondary validation for high-impact findings, and define who owns the final decision. Governance should cover prompt scope, output format, reviewer sign-off, and auditability. That keeps AI in an advisory role and prevents noisy model output from becoming an unreviewed security decision.


Technical breakdown

Why AI-generated code produces risk velocity

AI-generated code is not inherently broken, but it is optimised for plausibility and usefulness rather than secure intent. That means it can produce syntactically correct code that reproduces known flaw patterns, omits context-specific access checks, and accelerates the creation of dependency and configuration risk. The security problem is therefore not just defect introduction. It is defect accumulation at a rate that outpaces review, testing, and remediation capacity. Once throughput rises faster than control capacity, risk becomes a flow problem, not a point-in-time quality problem.

Practical implication: Practitioners should measure security control capacity against code output rate, not just vulnerability counts.

How insecure context gets baked into generated code

Large language models do not understand the target system’s authorization model, data sensitivity, tenancy boundaries, or runtime assumptions unless those constraints are made explicit. As a result, they often omit the controls that matter most in real systems: input validation, access checks, secure defaults, safe configuration, and environment-specific handling. That is why AI-assisted code can look correct while still weakening security posture. In application terms, the missing context is as dangerous as the visible bug because it encodes the wrong trust model into production code.

Practical implication: Treat context injection, secure coding rules, and policy enforcement as mandatory inputs to AI-assisted development workflows.

Why the software supply chain gets noisier with AI-assisted development

AI-assisted development can widen software supply chain risk by suggesting outdated packages, vulnerable libraries, and even dependencies that do not exist. That matters because modern applications already depend on large component ecosystems, and every new dependency expands the attack surface. When rapid code generation is combined with dependency sprawl, security teams lose visibility into what is actually being shipped and why. The result is not just more vulnerabilities. It is more uncertainty about provenance, maintainability, and the trustworthiness of the build path.

Practical implication: Combine software composition controls with dependency governance so generated code cannot introduce unmanaged packages into production.


Threat narrative

Attacker objective: Exploit insecure code paths and weakened software supply chain controls to create durable application risk at scale.

  1. Entry occurs through AI-generated code that enters development workflows faster than security review can keep up, creating a widened window for insecure logic to reach production.
  2. Credential or control abuse follows when generated code reproduces unsafe authentication, access, or secrets-handling patterns that create exploitable trust assumptions.
  3. Impact comes from latent vulnerabilities, dependency sprawl, and remediation backlog growth that increase the likelihood and blast radius of compromise.

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

Risk velocity is now the more useful application security metric than raw vulnerability count. When code production accelerates, backlog size alone stops telling the full story. What matters is whether the organisation can reduce risk as quickly as it creates it. That reframes governance from reporting exposure to managing the rate of exposure creation and closure. Practitioners should treat risk velocity as the operational signal that security capacity is lagging engineering throughput.

AI-assisted development exposes a control gap, not just a code-quality problem. The article shows that insecure output is a symptom of missing context, weak policy enforcement, and over-reliance on post-hoc review. Secure code is not just a developer habit; it is the product of surrounding guardrails that make unsafe choices hard to ship. That is why application security must move from advisory review toward enforced control points in the delivery pipeline.

Security debt has become a governance debt in AI-enabled SDLCs. Once insecure patterns can be generated faster than teams can review them, accountability has to move earlier in the workflow. The named concept here is security throughput gap: the widening mismatch between code velocity and control velocity. If the gap is not governed, organisations inherit a larger attack surface with less time to understand it.

Secure by design only works when the secure path is the easiest path. The article is right to reject training as a standalone answer because incentives and friction dominate behaviour under delivery pressure. In practice, this means secure defaults, approved patterns, executable policy, and automated remediation matter more than awareness campaigns. For identity-dependent applications, that also means access, secrets, and authorisation patterns must be embedded into the paved road.

Application security and identity governance are converging around the same failure mode. Generated code can embed broken assumptions about authentication, privilege, and tenant boundaries, which turns IAM policy into a downstream dependency of software quality. That intersection matters because code that mishandles identity is not just vulnerable code; it is governance debt that crosses appsec, IAM, and NHI controls. Practitioners should govern the code path where identity assumptions are created, not only the control where they are later reviewed.

From our research library:

What this signals

Security throughput gap: AI-assisted development changes the unit of control from individual defects to the rate at which defects enter the system. That means organisations need to govern code generation, dependency intake, and remediation capacity as one delivery loop, not as separate teams or tickets. When review cannot keep pace, security debt becomes a structural property of the SDLC rather than an exception.

Application security programmes that still rely on late-stage review will struggle most, because generated code amplifies the exact friction points that already slow remediation. The practical response is to make secure defaults, policy enforcement, and inline fixing part of the developer workflow so the secure path remains the fastest path.


For practitioners

  • Implement risk velocity tracking Measure the rate at which new vulnerabilities, insecure dependencies, and security exceptions are created versus closed in each delivery stream.
  • Enforce secure coding guardrails in pipelines Convert authentication, input handling, logging, and dependency rules into executable checks that block unsafe AI-generated code before merge.
  • Tighten software composition controls Require approved dependency sources, lockfiles, and package provenance checks so generated code cannot introduce unmanaged libraries.
  • Reduce review noise and backlog drag Tune static analysis and remediation workflows so developers receive fewer, higher-confidence findings that can be fixed inline.

Key takeaways

  • AI-generated code is not just creating more software, it is increasing the pace at which insecure patterns, unsafe dependencies, and security debt enter the environment.
  • Only 44% of developers are reported to follow security best practices for secrets management, according to the State of Secrets in AppSec, which shows how behaviour gaps can widen as code velocity rises.
  • The control challenge is no longer only finding vulnerabilities, but making security capacity scale with development throughput through executable policy, dependency governance, and inline remediation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, OWASP SAMM, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP ASVSV8 — AuthorizationGenerated code often omits access checks and trust boundaries, which maps to authorization failures.
V14 — Data ProtectionThe article highlights insecure defaults, secrets handling, and unsafe data handling in generated code.
Recommendation — Enforce V8 checks on generated code that touches access decisions or tenant boundaries. Apply V14 requirements to generated code that stores, transmits, or logs sensitive data.
OWASP SAMMGovernance — GovernanceThe article is fundamentally about embedding security into SDLC governance and automation.
Recommendation — Use SAMM governance practices to make secure coding rules executable in delivery pipelines.
NIST CSF 2.0PR.DS-10 — ConfidentialityAI-generated code can expose secrets and sensitive data if security controls are not enforced.
Recommendation — Strengthen PR.DS-10 controls where generated code handles secrets or sensitive data.
CIS Controls v8CIS-16 — Application Software SecurityThe post is about securing code generation, review, and remediation in the SDLC.
Recommendation — Apply CIS-16 to embed secure development checks into code review and build workflows.

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 Composition Risk: Software composition risk is the exposure created by third-party libraries, packages, and dependencies used in an application. AI-assisted development can increase that risk by suggesting outdated, vulnerable, or non-existent components that expand the attack surface.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It helps security and identity practitioners connect governance, lifecycle control, and operational risk in modern environments.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org