TL;DR: Security professionals are most worried about the pace of AI and new threats, and 54% said undetected vulnerabilities are the top risk in AI-generated code, underscoring how fast plausible but insecure code can enter pipelines, according to Veracode polls. The governance problem is no longer AI adoption itself, but verification of untrusted code at commit and merge time.
At a glance
What this is: Veracode argues that AI-generated code is creating a silent AppSec failure mode because insecure but plausible code can bypass human review and standard checks.
Why it matters: This matters to AppSec, IAM, and platform teams because the security boundary is shifting left to commit and merge time, where provenance, review, and automated verification must catch what people miss.
By the numbers:
- 54% of security professionals in Veracode polls said undetected vulnerabilities were the top risk in AI-generated code.
- 54% of respondents said the pace of AI and new threats was their biggest security concern.
- 38% of respondents ranked securing the software supply chain as a top concern.
Context
AI-generated code is not risky only because it is machine-assisted. The deeper issue is that code can be syntactically valid, functionally plausible, and still contain hidden security flaws that evade cursory review.
That creates a verification problem for AppSec programmes, but also an identity and governance problem when AI-assisted development becomes a new source of untrusted inputs. Teams need to know what was generated, what was reviewed, and what was allowed to merge.
Key questions
Q: What breaks when AI-generated code is only checked after commit?
A: Post-commit controls miss the moment when risky code is created, so secrets, insecure patterns, and policy violations can enter the repository before security ever sees them. That makes audit evidence incomplete and weakens defensibility. The practical failure is timing, because detection after commit cannot prove that policy was enforced at generation time.
Q: Why do silent flaws in AI-generated code create more risk than obvious defects?
A: Silent flaws are harder to catch because they look functional enough to bypass quick review, yet they can still contain missing validation, unsafe authorization, or secrets exposure. That combination increases the chance that a defect survives to production and is inherited across future releases.
Q: How should security teams balance speed and verification in AI-assisted development?
A: Use AI to accelerate drafting, but keep the release decision grounded in the same assurance standards used for human-written code. The practical balance is not faster approval, but faster initial generation followed by consistent policy checks, human review where needed, and automatic rejection of output that exceeds quality thresholds.
Q: Should organisations treat AI-generated code as a separate governance category?
A: Yes, because AI-generated code introduces a trust problem that sits between development, application security, and identity governance. Teams need policy for what AI may generate, how outputs are validated, and how identities and secrets are handled in the resulting code. Without that, responsibility for unsafe behaviour becomes fragmented across teams.
Technical breakdown
Why AI-generated code fails human review
AI coding assistants can produce code that looks correct enough to pass a quick inspection while still embedding insecure patterns. Common examples include missing input validation, weak authorization logic, unsafe assumptions about data handling, and hardcoded secrets. The risk is not that the code is obviously malicious. The risk is that it is credible enough to be trusted before it has earned that trust. In AppSec terms, the failure happens at the boundary between creation and verification, where human reviewers are least likely to catch subtle defects at scale.
Practical implication: Treat AI-generated code as untrusted until automated and human controls have validated it.
How supply chain risk amplifies AI-assisted development
AI-generated code often enters the same pipelines as third-party libraries, templates, and copied snippets, which means it should be governed as part of the software supply chain. The article’s finding that supply chain security remains a major concern is important because provenance is now a control problem, not just a sourcing problem. If teams cannot distinguish authored code from generated code, they lose visibility into who or what introduced a weakness and when. That weakens traceability, review quality, and exception handling across the build path.
Practical implication: Tag generated code and apply the same provenance and verification discipline used for third-party dependencies.
Why guardrail-first architecture matters for commit and merge
A guardrail-first model pushes security controls into the developer workflow rather than relying on periodic review after the fact. In this context, that means pre-commit checks, pull-request scanning, policy-as-code, and merge gates that can block high-severity issues before they propagate. The key architectural point is that AI accelerates code volume faster than manual review capacity can scale. Controls therefore have to act at issuance time, not just after deployment, because the window between generation and merge is where silent flaws become durable technical debt.
Practical implication: Move enforcement to the commit and pull-request stages, where the first trustworthy decision can be made.
Threat narrative
Attacker objective: The practical objective is to get insecure code accepted as legitimate software so that flaws persist in production and are harder to detect or unwind.
- Entry occurs when AI-assisted development introduces plausible but untrusted code into the workflow through prompts, suggestions, or generated snippets.
- Credential or logic abuse follows when insecure patterns such as weak authorization, hardcoded secrets, or missing validation are accepted without rigorous review.
- Impact emerges when the flawed code is merged and shipped, creating hidden security debt that can lead to compromise, data exposure, or downstream supply chain risk.
Breaches seen in the wild
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
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
Silent-flaw governance is now an AppSec control problem, not an AI adoption problem. The article’s strongest signal is not that teams are using AI, but that insecure code can now arrive packaged as plausible output. That shifts the burden from developer intent to verification discipline, because review quality degrades when output looks coherent. Practitioners should treat AI-generated code as a controlled input class, not a neutral productivity booster.
AI-assisted development expands the software supply chain, not just the developer toolchain. Once generated code enters pull requests, it becomes part of the same trust chain as dependencies, build artefacts, and signed releases. That means provenance, tagging, and merge gating matter as much for generated snippets as they do for third-party libraries. The operational conclusion is straightforward: if origin is unclear, the code should not be trusted by default.
AppSec programmes need issuance-time controls because review-time controls are too late. Human review and periodic scanning still matter, but they cannot reliably absorb the volume and speed of AI-assisted development. This is where guardrail-first design becomes decisive, with automated checks positioned before merge and deployment. Practitioners should measure whether security decisions happen early enough to stop silent defects from becoming inherited debt.
The real governance gap is provenance visibility across AI-generated and human-written code. Veracode’s polls show concern about undetected vulnerabilities, but the operational issue behind that concern is traceability. If teams cannot tag generated code at commit time, they cannot build reliable exception handling, targeted review, or audit evidence. The concept to watch is code provenance drift: the point at which organisations can no longer tell which changes were authored, assisted, or generated.
Identity and access governance becomes relevant when AI tools are allowed to shape software change without explicit accountability. AI-assisted coding is not an IAM problem in the narrow sense, but it does create a governance boundary around who can introduce code, under what policy, and with what verification. That makes policy enforcement, change traceability, and secure development standards part of the same control story. Practitioners should align engineering governance with security review so AI output never bypasses control ownership.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Code provenance drift: once generated code flows through normal delivery paths without explicit tagging, teams lose the ability to distinguish authored changes from AI-assisted ones. That does not just weaken review quality; it also undermines exception handling, audit evidence, and targeted remediation. Practitioners should design controls that preserve provenance at the point of commit.
The most useful control shift is from review after generation to verification before acceptance. That means security policy must operate inside the developer workflow, not outside it, because AI increases throughput faster than manual inspection capacity can scale.
For programmes already investing in software supply chain controls, the immediate priority is to extend those controls to generated code and AI-assisted changes. Provenance, scanning, and merge gating should be treated as one control system rather than separate initiatives.
For practitioners
- Inventory and tag AI-generated code Create a complete inventory of AI-assisted coding tools and require commit-time tagging for generated code so provenance is visible before review starts.
- Enforce merge gates on high-risk findings Block pull requests that introduce new critical or high-severity issues and require automated SAST, SCA, and secrets scanning on every merge request.
- Treat generated code as untrusted input Write policy that requires targeted review for AI-generated snippets, especially around authorization logic, input validation, and hardcoded secrets.
- Build policy-as-code for developer workflows Codify acceptable AI use, review criteria, and exception handling so security enforcement is consistent across teams and audit evidence is preserved.
Key takeaways
- AI-generated code can be syntactically correct and still hide serious flaws that human review misses.
- Veracode’s polling shows the concern is not theoretical, with 54% of respondents pointing to undetected vulnerabilities.
- The most effective response is to verify generated code before merge, preserve provenance, and block high-severity issues at the pipeline gate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | This article is about insecure code entering the pipeline and escaping review. |
| CIS-15 — Service Provider Management | The supply chain concern extends to third-party and generated inputs entering the build chain. | |
| Recommendation — Embed application security checks into the software lifecycle and block high-severity defects before release. Track and govern third-party and generated code sources as part of supplier risk management. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity Verification | AI-generated code needs integrity checks before it is trusted in the delivery chain. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article highlights weak authorization logic as a common silent flaw in generated code. | |
| Recommendation — Apply integrity verification to AI-assisted code before it is merged or deployed. Review authorization paths in generated code before allowing it into production. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article specifically cites hardcoded secrets and hidden flaws that can enable credential abuse and data exposure. |
| Recommendation — Map hidden code flaws to credential access and exfiltration paths during threat modelling. | ||
Key terms
- AI-generated code: Software produced wholly or partly by an AI model or agent rather than a human developer. The security concern is not authorship alone, but whether the resulting logic, access control, and dependency choices have been independently verified before release.
- Code provenance: Code provenance is the verifiable history of where code came from and who or what created it. In security practice, it combines authorship, timestamps, signatures, and build lineage so teams can prove a change was trusted before it reached production.
- Guardrail architecture: A control design that places preventive checks at the point of creation and enforcement checks at the point of integration or deployment. It is used when speed makes end-of-pipeline review too late to be effective, especially in AI-assisted software delivery.
- Silent Vulnerability: A silent vulnerability is a flaw that is not obvious to reviewers because the code appears correct, compiles cleanly, or behaves as expected in basic testing. These defects are dangerous because they can survive standard checks and accumulate as hidden security debt.
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 is a practical fit for security practitioners building stronger identity and control discipline across modern delivery pipelines.
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