AI-generated code is outpacing appsec controls, and attackers know it

At a glance

What this is: This is a Checkmarx analysis of how AI coding agents are increasing software volume, vulnerability density, and the speed at which attackers can exploit exposed weaknesses.

Why it matters: It matters to IAM and security practitioners because AI-assisted development expands the attack surface around developer credentials, code pipelines, and the governance model for machine-speed software creation.

By the numbers:

• Roughly 70% of a typical enterprise application is made up of open-source components.
• 81% of organizations knowingly ship software with vulnerabilities they’ve already identified.

👉 Read Checkmarx's analysis of AI-generated code risk and agentic appsec

Context

AI-generated code is changing application security because the pace of creation now exceeds the pace of human review and remediation. In practice, that means more code reaches production with less contextual understanding of why it was written, which dependencies it relies on, and which risks were introduced along the way. For IAM and security teams, the issue is not just software quality. It is the control gap created when identity, developer workflow, and automated code generation all intersect.

The article frames a real governance problem for modern software delivery: developers are now responsible for securing a much larger and more complex codebase, while attackers can inspect the same code paths for weaknesses at machine speed. Where AI systems also touch toolchains through MCP-connected workflows, the boundary between software development and machine-operated action becomes more sensitive. That is why application security has to be treated as a live control plane, not a post-build review step.

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-assisted coding tools complicate security assurance for enterprise software?

A: They increase code output faster than teams can prove the output is safe. Security assurance is slower because it depends on review, testing, and validation of behaviour, especially where access and trust are encoded in the application. The gap widens when organisations treat generation speed as the same thing as control maturity.

Q: How do security teams know if AI tool configuration is creating hidden execution risk?

A: Look for machine-wide settings stored in locations writable by standard users, especially if those settings control hooks, startup actions or shell commands. Then verify whether the application validates ownership, ACLs and file provenance before loading configuration. If it does not, the tool is effectively accepting untrusted runtime instructions from the host filesystem.

Q: What should organisations do when developers are shipping more code than security can review?

A: Introduce automated controls inside the development pipeline, tighten access to build and deployment identities, and use policy to block high-risk dependency patterns. The goal is to make risk decisions before code reaches production, not after. If review happens too late, remediation becomes incident response by another name.

Technical breakdown

Why AI-generated code increases vulnerability density

AI coding systems can accelerate output without carrying the same contextual judgement a human developer uses when making trade-offs. That creates code that functions syntactically but can still embed insecure patterns, incomplete validation, weak dependency choices, and inconsistent logic. The core issue is not that AI always writes bad code. It is that it writes code at a scale and speed that overwhelms the normal feedback loop between authoring, review, and remediation. Once the code exists, attackers only need one missed weakness to gain leverage.

Practical implication: security teams need controls that inspect code as it is created, not after the development context has been lost.

How open-source dependency trust becomes an attack surface

Modern applications inherit a large share of functionality from open-source packages, which makes dependency trust a central part of software risk management. The problem is that developers often assume upstream packages are benign and current, while attackers exploit registry poisoning, typosquatting, malicious updates, and stale dependencies. AI coding assistants can make this worse by suggesting package names or library patterns that look plausible but are not verified. In other words, dependency selection has become both a productivity layer and a threat vector.

Practical implication: teams should combine software composition analysis with package validation and allowlisting for high-risk build paths.

Why agentic development needs machine-speed application security

As coding workflows become more agent-driven, security tools must be able to participate in the pipeline automatically rather than waiting for human review. That means deterministic controls like SAST, SCA, and infrastructure-as-code scanning still matter, but they need to be paired with orchestration that can prioritise findings, suppress duplicates, and trigger remediation fast enough to match release velocity. The important shift is architectural: security is no longer just detecting defects. It is governing a continuously changing software production system where code, dependencies, and actions may all be machine-mediated.

Practical implication: build automated security decision points into CI/CD so code risk is handled before deployment, not after incident response.

Threat narrative

Attacker objective: The attacker objective is to turn accelerated development into a durable software supply chain weakness that enables compromise, data theft, or downstream exploitation.

1. Entry occurs when attackers target developer workflows, package registries, or code-generation paths that have become part of the software supply chain. Credential theft and dependency abuse provide the initial foothold.
2. Escalation follows when malicious packages, injected prompts, or compromised build assets are used to introduce vulnerable logic, exfiltrate secrets, or alter code paths at scale.
3. Impact is realised when vulnerable code is deployed into production and exploited faster than human teams can review, prioritise, and remediate it.

NHI Mgmt Group analysis

AI-generated code has created an appsec velocity problem, not just a quality problem. The security challenge is no longer limited to finding defects. It is that defects are being introduced at a rate that overwhelms the traditional human review model and stretches remediation windows beyond what defenders can manage. For identity and access programmes, that means developer tooling, build systems, and code-signing trust must be treated as governed assets, not informal productivity layers. The practitioner conclusion is simple: if creation is machine-speed, control must be machine-speed too.

Developer workflow has become an identity perimeter. The article points to compromised credentials, package registries, and AI-assisted development as active exposure points. That is a governance issue for IAM and PAM as much as AppSec, because the build chain now depends on the integrity of human developer accounts, service credentials, and machine identities inside CI/CD. Where those identities are over-permissioned, attackers do not need to defeat the application first. They can enter through the pipeline. Practitioners should treat development access as production-risk access.

AI coding introduces a context-loss problem that conventional review cannot solve. Once a prompt becomes hundreds of lines of code, the reasoning behind the implementation often disappears before review begins. That creates what can be called context debt: the security burden left behind when design intent, assumptions, and trade-offs are no longer visible to the people reviewing the code. This is where AI RMF and application security controls intersect. The practical conclusion is that teams need traceable, automated governance around generated code before the context evaporates.

Security teams need to shift from static findings to governed remediation loops. Findings that sit in a backlog while release velocity accelerates are already a control failure. The article’s point about faster exploitation underscores that vulnerability management, developer education, and automation must be tied together. In NHIMG terms, this is where identity, secrets, and code governance converge. If developer identities can create, pull, and deploy code without strong controls, every other security layer inherits that risk. Practitioners should measure time-to-fix as an operational control, not a reporting metric.

What this signals

Code generation is becoming an identity and governance problem as much as an engineering one. When machine-produced code can outpace review, the decisive control is not just scanning depth. It is whether teams can govern the identities, credentials, and approval paths that let code move from prompt to production. That is where identity security and application security now overlap in practice.

Context debt is the new operational signal. When teams lose the original reasoning behind generated code before it is reviewed, they create a persistent governance gap that scanners cannot close on their own. This makes remediation workflow, provenance tracking, and build-pipeline ownership critical programme controls, especially where developer identities can deploy changes directly.

Security leaders should expect more pressure to prove control effectiveness, not just tool coverage. The right question is whether AI-assisted delivery has shortened the time between flaw creation and flaw exploitation beyond the organisation’s tolerance. For teams aligning to NIST SP 800-53 Rev 5 Security and Privacy Controls, that means treating access control, auditability, and configuration integrity as living controls in the software factory.

For practitioners

• Protect developer and pipeline identities first Inventory developer accounts, CI/CD service accounts, and automation credentials with the same rigor used for production privilege. Enforce least privilege, strong authentication, and short-lived access for build and deployment paths that can change code or push artifacts. This is where compromised access becomes code compromise, so the developer identity tier needs tighter governance than general user access.
• Pair AI-generated code review with deterministic scanning Use SAST, SCA, and infrastructure-as-code scanning in the same pipeline stage as generation or commit, not after merge. AI can help triage, but deterministic checks must validate findings and catch reproducible issues before deployment. The goal is to reduce context loss by pushing review as close as possible to code creation.
• Govern open-source usage with package validation controls Allowlist approved registries, validate package provenance, and flag typosquatting or newly introduced dependencies in high-risk projects. AI-assisted development can suggest plausible but unverified libraries, so dependency trust needs policy, not just developer judgement. Treat every new package as a supply chain decision.
• Measure remediation speed as a security control Track time from discovery to fix for both developer-introduced flaws and dependency-based risks, then set escalation thresholds for stale issues. If the backlog grows faster than remediation capacity, the programme is already failing at governance even if scanners are running. Use that metric to drive resourcing and release gating decisions.

Key takeaways

• AI-generated code increases both software volume and vulnerability density, which makes traditional human review too slow to be the primary control.
• The strongest signal of programme weakness is not scanner coverage, but the growing gap between flaw discovery and flaw remediation.
• Identity governance, pipeline controls, and deterministic scanning now need to work together if organisations want to keep AI-assisted development from becoming a security liability.

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.
• Context debt: A governance condition where security tools hold partial or stale information about data, identity, or workflow state, so decisions are made with incomplete context. The result is noisy enforcement, missed risk, and controls that cannot keep pace with distributed cloud and AI use.
• 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.
• Agentic Application: An agentic application is software in which an AI system can choose actions, call tools, and complete tasks with limited human intervention. In security terms, it behaves like an active workload that needs scoped identity, logging, and control boundaries, not just prompt filtering.

What's in the full article

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

• The NYSE interview framing behind the article’s argument on AI-assisted development and security pressure.
• The discussion of Claude Mythos, including the article’s claims about autonomous vulnerability discovery speed and exploit economics.
• The article’s perspective on agentic application security and why the vendor argues security must move into the development flow.
• The specific product context around Developer Assist, Triage Assist, and Remediation Assist, which this analysis does not evaluate.

👉 Checkmarx's full article covers the NYSE discussion, AI coding risk, and the appsec implications in more detail

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect access governance, machine identities, and emerging AI-driven risk.