TL;DR: AI coding assistants are now used or planned by 84% of developers, while research cited by Kusari shows the output often carries more security flaws, hallucinated dependencies, and missing defensive controls than human-written code. The governance problem is no longer adoption itself, but the lack of workflow controls that treat AI-generated code as untrusted input.
At a glance
What this is: This article argues that AI coding assistants are now mainstream in software development, but they are widening AppSec gaps by increasing insecure code, supply chain risk, and missed defensive controls.
Why it matters: It matters because engineering and AppSec teams need to govern AI-generated code as an untrusted input stream, not as a routine productivity boost, if they want to keep supply chain and code review controls effective.
By the numbers:
- 84% of developers now use or plan to use AI coding assistants, according to Stack Overflow's 2025 Developer Survey cited by Kusari.
- 51% of professional developers rely on AI coding assistants daily, according to Stack Overflow's 2025 Developer Survey cited by Kusari.
- GitGuardian found that 6.4% of repositories using GitHub Copilot leak at least one secret, compared with a 4.6% baseline in repositories without AI assistance, according to Kusari.
Context
AI coding assistants are software tools that generate, refactor, or explain code inside the developer workflow, usually with a large language model under the hood. The governance problem is that these tools are being adopted faster than the security controls that should validate their output, which means organisations are importing risk at the point where code enters the software supply chain.
This is not just an application security issue in the narrow sense. AI-generated code can carry insecure patterns, omitted checks, and hallucinated dependencies into repositories, so the control boundary shifts from reviewing finished code to governing the generation process itself. Where teams already depend on pull requests, SAST, and SCA, the challenge is making those controls effective against machine-produced code at scale.
For identity and access teams, the intersection is real even when the article is not about IAM directly. AI-authored code can introduce authorization flaws, secret exposure, and dependency trust issues that expand the blast radius of weak engineering governance into application and supply chain identity controls.
Key questions
Q: What is the failure mode when AI coding agents generate code without security guardrails?
A: The failure mode is insecure code becoming the default implementation path before anyone applies review or remediation. When an agent optimises only for task completion, it can introduce weak auth flows, unsafe input handling, and risky dependencies at generation time. The control gap is not human negligence alone, but the absence of security constraints inside the agent workflow itself.
Q: Why do AI coding agents increase supply-chain risk?
A: AI coding agents can choose tooling, install packages, and edit lock files in ways that may bypass the controls humans expect in a managed environment. That widens the blind spot around untracked software and makes package provenance harder to enforce. The practical response is to restrict agent permissions, inventory their workspaces, and review their install behaviour like any other privileged automation.
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.
A: Teams should treat AI-assisted development as a throughput shift, not just a productivity gain. The SDLC needs more automation in testing, CI/CD, release orchestration, and policy enforcement so higher code volume does not create bottlenecks. Governance should be embedded early, with standardized workflows and risk controls that keep quality and security aligned as delivery speed rises.
Technical breakdown
Why AI-generated code creates a different AppSec failure mode
AI coding assistants do not merely accelerate development. They change the composition of risk by producing code that is functionally plausible but security-incomplete. The model optimizes for probable code patterns, not secure design, so it can reproduce unsafe constructs from training data, omit validation logic, or generate authorization paths that look correct in review but fail under attack. That makes the review problem different from ordinary developer error: the output is scale-amplified, repetitive, and often trusted because it appears coherent.
Practical implication: Treat AI-generated code as untrusted input and require automated security validation before merge.
Slopsquatting turns hallucinated dependencies into supply chain attack surface
Package hallucination is a distinct supply chain risk. When an AI assistant invents a library name, the developer may search for it, install a lookalike package, or accept it in generated build instructions. Attackers can exploit that behavior by registering malicious packages under hallucinated names, a pattern often called slopsquatting. The important mechanism is not just bad dependency advice. It is the coupling of plausible machine output with human trust and package registry availability, which creates a repeatable path from recommendation to compromise.
Practical implication: Add dependency verification that flags nonexistent, newly registered, and typosquatted packages in the PR workflow.
Why missing defensive controls are a workflow problem, not just a code problem
AI-generated code often omits security controls such as input validation, sanitization, or authorization checks when the prompt does not specify them. That omission matters because human reviewers tend to focus on whether the code works, not whether it is complete from an AppSec perspective. Once teams begin trusting generated code, review quality drops and insecure defaults survive into production. The core issue is therefore not only model behaviour but workflow design, because the normal human review layer is no longer sufficient on its own.
Practical implication: Push SAST and SCA into the pull request so omissions are detected where code is produced.
Threat narrative
Attacker objective: The attacker aims to turn trusted AI-assisted development workflows into a path for code compromise, secret exposure, or malicious dependency insertion.
- Entry occurs when developers accept AI-generated code or dependency suggestions inside normal IDE and pull request workflows.
- Credential or supply chain abuse follows when the model introduces hallucinated packages, insecure patterns, or missing controls that developers trust and merge.
- Impact occurs when insecure code, leaked secrets, or malicious dependencies reach production and expand the application attack surface.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
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 coding assistants have shifted the AppSec problem from isolated coding mistakes to systemic workflow risk. The central issue is not whether developers can produce code faster, but whether the surrounding controls can still verify what that code contains. Once AI output becomes a default input to the SDLC, review discipline has to move from manual inspection to enforced security gates.
Slopsquatting is the clearest named concept emerging from this risk pattern. Hallucinated package names become a supply chain foothold only when developers trust machine-generated suggestions enough to resolve them through public registries. That makes the problem a governance failure as much as a technical one, because package provenance and dependency allowlisting now sit in the critical path of code acceptance.
Secret leakage in AI-assisted development is an NHI-adjacent control issue, not just an AppSec nuisance. Repositories that accept AI-generated snippets can inherit tokens, credentials, and workflow weaknesses that should have been blocked before merge. The overlap with NHI governance is direct when generated code handles service credentials, automation tokens, or build-time secrets, so identity control has to extend into development workflows.
Pull request security is becoming the real control plane for AI-assisted software delivery. Traditional milestone-based review cannot keep pace with the volume and speed of generated code. The practical conclusion is that organisations need governance that validates code at issuance time, not after the codebase has already absorbed the risk.
The development productivity story is now inseparable from supply chain resilience. AI coding tools compress delivery time while increasing the likelihood of hidden defects, hallucinated dependencies, and trust failures. Teams that treat these tools as simple productivity enhancers will continue to under-resource the controls required to keep the SDLC safe.
From our research library:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: LLM Provider API Key Security and LLMjacking Guide
What this signals
AI coding assistants are becoming a control problem, not just a productivity feature. Once teams let generated code move straight from prompt to pull request, the security review burden shifts to the workflow itself. That means the most effective programme response is to validate code at merge time, not to depend on developers noticing every omitted check or unsafe pattern.
Slopsquatting gives AppSec teams a concrete supply chain concept to track. When assistants hallucinate package names, attackers can register those names and wait for developers to trust the recommendation. Security teams should therefore treat package provenance, transitive dependency visibility, and repository hygiene as part of one combined control objective.
The NHI angle appears when AI-assisted code begins to touch secrets, tokens, and automation identities. Generated code that handles service credentials or build-time secrets can widen machine identity exposure if the surrounding workflow does not enforce least privilege and secret hygiene. That makes development governance a direct contributor to NHI risk, not a separate concern.
For practitioners
- Treat AI-generated code as untrusted input Require developers and reviewers to assume AI-authored snippets may contain insecure logic, missing validation, or unsafe dependency references before they are merged.
- Enforce PR-gated SAST and SCA Run static analysis and transitive dependency checks inside the pull request so insecure patterns and inherited package risk are caught before code reaches mainline.
- Verify all suggested packages against registries Block nonexistent, newly registered, and typosquatted package names that appear in AI output, and require provenance checks for any package the model proposes.
- Add explicit security prompts to code generation Require developers to instruct assistants to include input validation, sanitization, authentication, and authorization logic whenever code handles user or service input.
- Track secret leakage in AI-assisted repositories Monitor repositories using AI coding assistants for tokens, API keys, and workflow secrets so the organisation can measure whether automation is increasing exposure.
Key takeaways
- AI coding assistants are now embedded in mainstream development, but they also widen the gap between delivery speed and application security coverage.
- The most distinctive risks are insecure inherited patterns, hallucinated dependencies that enable slopsquatting, and omitted defensive controls that human reviewers may miss.
- Security teams need to move validation into the pull request workflow and treat AI-generated code as untrusted until automated checks clear it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | AI-assisted code in this article increases secret exposure in repositories and workflows. |
| NHI-07 — Long-Lived Secrets | Generated code can propagate credentials and secrets into places they should not persist. | |
| NHI-05 — Overprivileged NHI | AI-written automation can widen privilege if service identities and tokens are over-scoped. | |
| Recommendation — Scan AI-assisted repos for leaked secrets and revoke exposed credentials before merge. Replace persistent secrets in AI-assisted workflows with short-lived credentials where possible. Review service and automation identities for excess privilege before AI-generated code ships. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article highlights insecure patterns and missing controls that create exploitable app misconfigurations. |
| Recommendation — Enforce configuration checks that block insecure defaults in generated application code. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | Secret leakage and malicious dependency paths map directly to credential theft and data loss techniques. |
| Recommendation — Map AI-assisted secret exposure to TA0006 and TA0010 to prioritise detection and containment. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is fundamentally about securing application code and the SDLC against introduced flaws. |
| Recommendation — Embed secure code review and automated validation into application security workflows. | ||
Key terms
- AI coding assistant: An AI coding assistant is software that helps write, refactor, debug, or navigate code using model-driven suggestions and sometimes command execution. In practice, it can become part of the operational control plane if it has access to files, terminals, and external tools that can change a system.
- Slopsquatting: Slopsquatting is a supply-chain attack that exploits hallucinated package names suggested by AI systems. An attacker registers the invented name in a public registry and waits for a developer or build pipeline to install it. The risk sits at the intersection of model error, dependency trust, and software delivery speed.
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Pull Request Security Gate: An automated control that blocks code from merging until it passes checks such as SAST, SCA, policy validation, and dependency approval. For AI-generated code, this gate matters because it shifts security review earlier, before flawed or unvetted code reaches the main branch.
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. The course is designed for practitioners who need to connect identity governance with modern automation and machine identity risk.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org