TL;DR: AI tools are now embedded in development workflows, and Veracode says nearly half of AI-generated code suggestions can introduce known vulnerabilities while 84% of developers are already using or planning to use AI in development. Secure adoption now depends on shifting verification into the SDLC, not trusting model output.
At a glance
What this is: Veracode argues that AI code generation is already shaping development, but it can also inject known vulnerabilities and dependency risk into software pipelines.
Why it matters: IAM, AppSec, and platform teams need to treat AI-assisted development as a control problem, because insecure code and unvetted dependencies create governance gaps before release.
By the numbers:
- 84% of respondents are using or planning to use AI tools in their development process, according to the 2025 Stack Overflow Developer Survey cited by Veracode.
Context
AI code generation is a software delivery control issue, not just a productivity issue. When developers accept machine-generated snippets, the real question becomes whether those snippets are verified before commit, dependency resolution, and release.
The identity angle is indirect but real: AI coding tools can introduce hard-coded credentials, unsafe libraries, and insecure patterns into pipelines that depend on strong access, provenance, and review controls. That makes the SDLC a governance boundary, not only a build workflow.
Key questions
Q: How should teams govern AI code generation when security rules change by repository?
A: Use repository-specific guardrails that encode local stack, framework, and threat context before code is generated. Generic policy text is too blunt for secure coding decisions that vary by language or application pattern. Governance works better when the assistant receives the right constraint in the same workflow where the code is written.
Q: Why do AI coding tools increase secrets risk?
A: AI coding tools increase secrets risk because they can accelerate the reuse of insecure patterns across repositories, test fixtures, and automation scripts. The issue is not the model inventing credentials, but the way generated code can spread bad defaults faster than human review can catch them.
Q: What do organisations get wrong about scanning AI-generated code?
A: The common mistake is treating more scanning as a complete answer. In reality, high-volume findings create noise unless teams can prioritise exploitability, exposure, and business impact. Organisations also miss the governance layer, where AI tools and agents need ownership, permission boundaries, and auditable actions.
Q: What happens when AI generated code is accepted without security validation?
A: When AI generated code is accepted without security validation, insecure logic can enter the codebase as if it were trusted developer output. That increases the chance of hidden backdoors, exploitable defects, and compliance failures in regulated environments. Over time, the organisation inherits both technical debt and breach exposure because the unsafe code may be reused across projects and deployments.
Technical breakdown
Why AI-generated code creates new attack surface in the SDLC
AI assistants can produce code that looks correct while still carrying insecure logic, weak validation, hard-coded secrets, or vulnerable dependencies. The problem is not that the model is malicious. It is that the model lacks application context, threat context, and organisational policy context. In practice, that means secure coding risks are imported at the point of generation, before traditional review or scanning may catch them. The SDLC now has to assume the first draft may already contain exploitable flaws, especially in fast-moving teams that accept suggestions at speed.
Practical implication: Treat AI output as untrusted code until it passes automated verification and human review.
How SAST, SCA, and DAST fit around AI code generation
Static analysis, composition analysis, and dynamic testing each cover a different failure mode. SAST finds flaws in source or generated code before commit. SCA identifies vulnerable open-source libraries and transitive dependencies that AI may recommend without context. DAST tests the running application for runtime and business-logic issues that static methods miss. Together, they create layered control coverage across generation, dependency selection, and execution. The important design point is sequencing: the sooner a flaw is caught, the less security debt accumulates downstream.
Practical implication: Place verification at generation, dependency intake, and runtime rather than waiting for late-stage testing.
Why responsible AI remediation needs curated security data
Using AI to fix AI-generated flaws only works when the remediation model is constrained by trusted security data. Generic models can repeat insecure patterns because they learn from broad public code, including bad examples. A curated remediation system reduces that risk by grounding fixes in verified security outcomes rather than probabilistic language output. That matters because remediation quality affects mean time to remediate and the eventual density of unresolved flaws. In other words, remediation is part of the control plane, not a convenience layer.
Practical implication: Use curated remediation guidance for fixes and do not let generic AI generate security patches unchecked.
Threat narrative
Attacker objective: Exploit insecure AI-assisted code paths to gain application compromise, credential exposure, or downstream supply-chain access.
- Entry occurs when AI-generated or AI-suggested code is accepted into the development workflow without adequate verification.
- Credential, injection, or dependency flaws are then introduced through hard-coded secrets, unsafe input handling, or unvetted packages.
- Those flaws can persist into testing and production, where they expand attack surface and create exploitable application or supply-chain weakness.
Breaches seen in the wild
- Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
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 code generation is now a governance problem, not a novelty problem. Once AI suggestions enter the development pipeline, security teams need controls that verify code at the point of creation rather than assuming downstream review will absorb the risk. That shifts the conversation from developer enablement to control integrity. Practitioners should treat AI-assisted coding as part of the software security governance model.
Security debt is the right concept for this failure mode. AI-generated flaws do not just create isolated defects, they accumulate as unresolved exposure across code, dependencies, and runtime behaviour. The value of automated verification is therefore not speed alone, but preventing low-friction flaw creation from outpacing remediation capacity. Practitioners should measure how much debt enters the pipeline at generation time.
The secure SDLC must absorb AI without trusting model output. The strongest control pattern is to place independent verification between suggestion and commit, then again between dependency intake and runtime. That approach aligns with disciplined software assurance rather than optimistic use of generative tools. Practitioners should design for verification before acceptance, not remediation after release.
AI-generated code makes supply chain governance part of application security. When assistants recommend outdated or vulnerable libraries, the issue is no longer confined to secure coding. It becomes a dependency trust problem that reaches into software composition, package intake, and provenance controls. Practitioners should re-evaluate whether their SDLC can distinguish useful assistance from unsafe software inheritance.
Named concept: security debt at code-generation time. This is the accumulation of risk when AI output is accepted before being verified, so vulnerabilities enter the pipeline as a normal by-product of speed. The concept matters because it explains why late-stage scanning alone cannot keep pace with high-volume AI-assisted development. Practitioners should push controls left until generation-time risk is interrupted.
From our research library:
- Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Security Guide
What this signals
Security debt at code-generation time: the real governance problem is not whether AI can write code, but whether teams can stop flawed suggestions from entering the pipeline as accepted work. That pushes assurance closer to the IDE, pre-commit gate, and dependency intake point, where the cost of failure is still manageable.
For practitioners, the practical signal is that SDLC control design must now cover generated code, generated dependencies, and generated fixes as separate risk surfaces. A mature programme will verify each one differently instead of assuming a single scanner or review step can absorb them all.
For practitioners
- Embed verification directly in the IDE Run SAST on AI-generated snippets before commit so developers see hard-coded credentials, injection flaws, and insecure cryptography immediately.
- Gate open-source intake with SCA Inspect transitive dependencies suggested by AI and block packages with known vulnerabilities or unapproved provenance before they enter the build.
- Use DAST in CI/CD for runtime validation Test AI-generated applications while running to catch business logic errors, configuration weaknesses, and issues static tools miss.
- Adopt curated remediation guidance Prefer security fix suggestions grounded in verified exploit and patch data rather than generic model output that may reproduce insecure patterns.
Key takeaways
- AI-assisted development introduces a repeatable path for vulnerabilities to enter the SDLC before teams can review them.
- The strongest control pattern is to verify code at generation time, composition time, and runtime rather than relying on late-stage testing alone.
- Security teams should treat AI coding as a pipeline governance issue, because unmanaged suggestions turn development speed into accumulated security debt.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP SAMM, OWASP ASVS, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP SAMM | Implementation Governance — Implementation Governance | The article is about embedding security into the SDLC and measuring assurance maturity. |
| Recommendation — Use SAMM to govern where AI-assisted coding is allowed and how security checkpoints are enforced across the SDLC. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | AI-generated code can introduce insecure patterns that ASVS helps verify before release. |
| Recommendation — Apply ASVS secure coding requirements to review AI-generated logic before it reaches production. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article centres on securing software development and dependency intake. |
| Recommendation — Use CIS application security controls to govern code review, dependency intake, and runtime validation. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity Checks | Verification at generation, intake, and runtime is an integrity problem in the software pipeline. |
| Recommendation — Add integrity checks around generated code, dependency selection, and build artifacts. | ||
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.
- 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.
- Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
- Dynamic Application Security Testing: Dynamic Application Security Testing evaluates a running application from the outside to identify weaknesses that only appear under real execution conditions. It is useful for validating authentication, session handling, and API behaviour, especially where configuration and integrations change how the system actually responds to attack.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management for practitioners building controls into modern delivery pipelines. It gives identity, security, and platform teams a common operating model for governing machine-led workflows.
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