TL;DR: Nearly every one of 1,500 AppSec leaders surveyed reported breaches tied to vulnerable code, while less than one in five organisations have governance policies for autonomous code, according to Checkmarx. The shift from code scanning to continuous, agentic intelligence makes software security a governance and validation problem, not just a detection problem.
At a glance
What this is: Checkmarx argues that AI-generated code turns application security into a governance and validation problem, not just a scanning problem, because code volume, supply-chain exposure, and autonomous workflows are rising together.
Why it matters: IAM, AppSec, and platform teams need to treat machine-generated code as a governed software supply chain, because validation, provenance, and runtime trust now shape security outcomes.
By the numbers:
- Nearly every one of the 1,500 AppSec leaders surveyed reported breaches tied to vulnerable code.
- Less than one in five organisations have governance policies in place to manage autonomous code in 2026.
Context
AI-generated code changes the control problem from isolated code review to governed software production. When generation speed rises faster than review capacity, teams lose the ability to rely on periodic scanning alone and must validate provenance, intent, and policy alignment throughout the development lifecycle. For identity and access teams, the same shift matters because machine-written software increasingly depends on API credentials, service identities, and delegated permissions.
The core governance gap is not whether scanning still has value. It is whether the organisation can explain what code came from where, what assumptions it carries, and which controls continuously verify it after creation. In that setting, secure development becomes a trust management problem across human developers, AI-assisted developers, and autonomous tooling.
Key questions
Q: What breaks when AI generated code is secured only with traditional static scanning?
A: Traditional static scanning often produces too much noise and too little context for AI generated code. Without contextual analysis, teams can miss exploitable paths, waste time on low value findings, and delay fixes. The practical failure is not detection alone, but poor prioritization and slow remediation across the pipeline.
Q: Why does AI-assisted development create a governance problem beyond code quality?
A: AI-assisted development changes who creates code, how fast it moves, and how difficult it is to trace. That creates a governance problem because security teams can inherit accountability without having equivalent visibility or control over the generation and approval process. The challenge is not just code quality, but enforceable oversight across the lifecycle.
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 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.
Technical breakdown
Why code scanning loses coverage in AI-driven delivery
Traditional static scanning assumes code is written, reviewed, and merged in a way that leaves a stable artefact to inspect. AI-generated code breaks that assumption by increasing output volume, shortening feedback loops, and producing changes whose origin and intent may be opaque to reviewers. Scanning still finds defects, but it does not establish whether the code was produced under approved guardrails, whether the prompt or model introduced risky logic, or whether the result matches the team’s standards. That is why AI-driven AppSec needs continuous validation, not just periodic detection.
Practical implication: Move security checks closer to creation and merge points, and treat provenance and policy verification as part of the control stack.
How agentic AppSec changes the control model
Agentic AppSec shifts security from a passive review function to an active control system that can correlate findings, explain risk, and guide remediation in context. The article’s point is not that scanning disappears, but that correlation, prioritisation, and runtime awareness become more important as AI accelerates development. In practice, this means the control plane has to understand whether code is human-authored or machine-authored, what phase of the SDLC it entered, and whether the surrounding environment still reflects the original risk assessment. That is a governance problem as much as an engineering one.
Practical implication: Build controls that classify code origin, connect findings across SDLC stages, and preserve traceability from commit to runtime.
Why software supply chain integrity is now an AppSec requirement
The article treats the software supply chain as the bigger risk because AI makes packaging, reuse, and propagation faster than manual oversight can reliably track. When generated code, models, and dependencies move together, the organisation must trust more than the source repository. It has to trust the build path, the dependencies, the artefacts, and the security feedback loop that corrects unsafe output. That is where AppSec overlaps with supply-chain governance, especially when a weakness in one generated component can spread across many downstream systems.
Practical implication: Verify build provenance, dependency trust, and artefact integrity as part of application security, not as a separate afterthought.
Threat narrative
Attacker objective: The attacker objective is to exploit the speed and trust of AI-assisted software delivery to push vulnerable or manipulated code into production environments at scale.
- Entry occurs through AI-driven development workflows that produce and merge code faster than human review can absorb.
- Credentialed access and supply-chain trust then allow vulnerable or manipulated code to reach shared repositories and downstream environments.
- Escalation happens when weak logic, hidden assumptions, or malicious dependencies propagate into production-facing systems and security tooling loses context.
- Impact is broader exposure across applications, APIs, and delivery pipelines, with breaches tied to vulnerable code becoming harder to prevent at scale.
Breaches seen in the wild
- Checkmarx KICS supply chain attack 2026: Credentials stolen via Trivy let attackers poison Checkmarx KICS Docker images, VS Code extensions and Actions to steal developer secrets.
- Fake Dependabot commits 2023: Stolen GitHub tokens were used to push fake Dependabot commits to hundreds of repos, adding workflows that stole Actions secrets.
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
AI-generated code governance is now a control problem, not a tooling problem. The article describes a world where code output outpaces human review and where provenance matters as much as vulnerability detection. That changes the centre of gravity from scan coverage to governed software production. Practitioners should treat machine-generated code as a policy-bound asset with lifecycle controls, not just as another source of findings.
Continuous validation is the missing control when code creation becomes asynchronous. Periodic scanning assumes a human-readable change process and a stable review window, but AI-assisted development compresses both. The result is a validation gap between generation, merge, and runtime that classic point-in-time checks cannot close on their own. Teams should use that gap as the design target for new control layers.
Software supply chain integrity is the named concept that best captures the new risk pattern. The article links AI-generated code, dependencies, and build trust into one operational problem. Once code, models, and tooling all contribute to the final artefact, provenance has to become part of security assurance. Practitioners should align AppSec, platform engineering, and supply-chain governance around verified build paths.
Identity is now embedded in application security through service access and delegated permissions. AI-generated software does not just introduce code risk, it also consumes secrets, tokens, and service identities to function. That means IAM, PAM, and AppSec controls are converging around how code is authorised to act. Practitioners should govern non-human access as part of the software delivery trust model.
The market is moving toward security systems that explain, correlate, and enforce, not just detect. The article’s argument is that the next control layer must understand context across the SDLC and respond in time to matter. That does not remove traditional AppSec. It raises the expectation that AppSec must continuously prove why a change is safe, not only flag that it is risky. Practitioners should plan for control stacks that combine static, dynamic, and runtime assurance.
What this signals
Software supply chain integrity is becoming the most practical way to describe the security gap created by AI-generated code. Once generation, dependency selection, and build automation all accelerate together, teams need controls that verify origin and preserve traceability across the delivery path.
The operational signal for practitioners is that AppSec is moving closer to identity and access governance. AI-assisted development uses secrets, tokens, and service identities to create software, so the security model must govern both the code and the non-human access behind it.
For practitioners
- Define governance for AI-generated code Require teams to label machine-generated changes, record the source workflow, and route them through policy checks before merge.
- Add provenance checks to the SDLC Verify where code came from, which model or assistant influenced it, and whether the build path preserves integrity from commit to artefact.
- Correlate findings across static, dynamic, and runtime controls Use one triage path that connects SAST, DAST, SCA, and runtime signals so risky generated code is handled in context.
- Govern non-human access used by development tools Inventory the secrets, tokens, and service identities used by AI-assisted workflows, then scope and review those permissions separately from human access.
Key takeaways
- AI-generated code increases the burden on AppSec because teams must validate provenance and policy alignment, not just find defects after the fact.
- The article’s own data points to a governance gap, with vulnerable code already linked to breaches and autonomous-code policies still uncommon.
- Practitioners should move toward continuous validation, build provenance checks, and tighter control of the non-human access used by development tooling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Agentic Skills Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI-generated code and agentic workflows create trust and privilege questions around machine-authored changes. |
| Recommendation — Apply ASI03 controls to govern how AI systems gain, use, and justify access during software delivery. | ||
| OWASP Agentic Skills Top 10 | Permission Inheritance in Skill Execution | AI-assisted development workflows can inherit permissions across chained tasks and tools. |
| Recommendation — Limit inherited permissions in chained AI workflows and review each tool boundary separately. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Generated code and autonomous tooling expand paths to credentials and downstream data exposure. |
| Recommendation — Map AI-assisted delivery risks to credential access and exfiltration techniques in your threat model. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article frames AI-driven AppSec as a governance issue, not only a technical detection problem. |
| Recommendation — Establish governance for AI-assisted code with accountability, documentation, and validation controls. | ||
| CIS Controls v8 | CIS-5 — Account Management | AI development tooling relies on service accounts, tokens, and other non-human access paths. |
| Recommendation — Review and reduce AI tooling accounts under CIS-5 to keep non-human access limited and traceable. | ||
Key terms
- Agentic AppSec: An application security model that embeds detection, remediation, and policy enforcement into AI-assisted development workflows. It treats AI coding tools and remediation agents as part of the security control plane, not just productivity software that developers use informally.
- Software Supply Chain Integrity: Software supply chain integrity is the assurance that code, dependencies, build systems, signing keys, and release processes have not been altered in unauthorized ways. It requires verifying provenance, controlling dependencies, protecting build and deployment pipelines, and detecting tampering so that software delivered to users matches what was intended and reviewed.
- 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.
- Continuous validation: Continuous validation is the practice of re-checking user, device, or session risk after login instead of trusting access indefinitely. It recognizes that identity assurance can drift during a session, especially when endpoint state or user context changes after authentication.
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 the broader software and security programmes they run.
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