AI code security now hinges on reachability, not severity

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Orca Security's blog post: AI code security's real differentiator is reachability, because AI-generated code can be insecure by default while only a subset of findings are actually exploitable.

Why it matters: IAM, AppSec, and platform teams need to prioritise reachable exposure over noisy severity scores because AI-assisted development changes both the volume and the shape of code risk.

By the numbers:

• Hallucinated packages appeared in at least 5.2% of commercial-model outputs and 21.7% of open-source-model outputs in a USENIX Security 2025 study cited by Orca Security.

Context

AI code security is the discipline of protecting source code, dependencies, secrets, and delivery pipelines when developers rely on code-generating assistants. The governance gap is that the output can look correct, compile cleanly, and still introduce unsafe patterns, invented dependencies, or exposed credentials that traditional review often misses.

The article’s core claim is that security teams should stop treating every AI-generated finding as equally urgent. Reachability, runtime exposure, and code-to-cloud context now matter more than raw severity because the practical question is whether a flaw can actually be exploited in the environment where the code runs.

Key questions

Q: How should security teams prioritise AI-generated code findings when scanning surfaces far more issues than developers can fix?

A: Security teams should prioritise findings by business exposure, not just technical severity. Start with code that is in production, reachable from internet-facing services, and owned by a team that can fix it quickly. Then separate real risk from backlog noise by asking whether the vulnerable path is actually exploitable in the deployed environment. Context, not volume, should drive remediation order.

Q: Why do package hallucinations and dependency confusion increase supply chain risk?

A: They exploit trust in automation. A developer or AI assistant can be steered toward a package name that looks legitimate, while the build process resolves a malicious public dependency instead of an intended internal one. The risk increases when governance cannot verify package origin quickly enough or when CI/CD access is overly broad.

Q: What are the signs that AI code security tooling is too noisy?

A: The main signs are large alert volumes, weak differentiation between exploitable and unreachable code, and remediation effort spent on findings that never reach production. If teams keep ignoring scan results, the tool is not improving trust. Effective tooling should reduce noise by showing which paths are active, exposed, and worth fixing first.

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 AI-generated code creates insecure-by-default patterns

Code-generating models optimise for plausibility, not secure implementation. That means they often reproduce weak patterns from public code, such as string-concatenated queries, missing input validation, and handlers that never enforce an authorisation check. These flaws are hard for linting to catch because they are logically unsafe rather than syntactically broken. In practice, this pushes more burden onto static analysis and security review that can reason about data flow and policy enforcement, not just style or syntax.

Practical implication: reviewers need to inspect generated code for logic flaws at the point of merge, not after deployment.

Hallucinated dependencies and slopsquatting risk

A model can invent a package name that sounds real but has never existed. If a developer copies that import into the codebase, an attacker can register the fake name on a public registry and deliver malicious code through what looks like a normal dependency install. This is why dependency validation has become a security control, not a cleanliness exercise. The issue is not just version drift. It is the model creating a supply-chain opening by fabricating a package ecosystem the developer assumes is trustworthy.

Practical implication: dependency checks must confirm package existence and publisher authenticity before a generated import is allowed into build flows.

Reachability and code-to-cloud context change prioritisation

Severity alone is a poor proxy for exploitability when code volume is high. A vulnerable function buried in dead code or an unused library is not the same as the same flaw on a request path that reaches production data. Reachability analysis asks whether the vulnerable line is actually called, and code-to-cloud context asks what running workload, permissions, and data it touches. That is the shift the article highlights: security decisions are increasingly about exposure path, not score alone.

Practical implication: triage should prioritise reachable code on exposed workloads before chasing high-severity issues that are never invoked.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• Code Formatting Tools Credential Leaks: Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.

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

Reachability is becoming the new control boundary for AI code security. AI-generated code expands the volume of findings, but only a subset of those findings are actually exploitable in the running environment. That changes the governance model from inventorying every defect to proving whether a defect can reach live data or live execution. The implication is that AppSec teams must treat exploit path as the unit of priority, not the alert itself.

Hallucinated dependencies are a supply-chain control failure, not just a developer mistake. When a model invents a package name, the organisation inherits a software trust problem at the registry boundary. That problem belongs in dependency governance, package verification, and release gating because the dangerous event is not the hallucination itself. The dangerous event is a fabricated dependency entering the build path as if it were legitimate.

AI-generated code blurs the line between code security and machine identity security. The same workflows that produce insecure code also introduce API keys, tokens, and other secrets into repositories and pipelines. That means secrets management, dependency validation, and code review now have to operate as one governance chain rather than separate controls. Teams that still assess these risks in silos will miss the combined exposure path.

Code-to-cloud context is the named concept practitioners should use for this category. A scanner that can map a vulnerable line of code to the workload it reaches and the data that workload can touch is materially more useful than one that only scores the finding. That is because AI-assisted development creates too many findings for severity ranking alone to remain credible. Practitioners should measure tools by whether they reduce the distance between code finding and production exposure.

OWASP Top 10 for LLM applications matters because AI-generated code and AI-built features now fail in adjacent ways. Generated code introduces unsafe patterns and bad dependencies, while AI-backed features add prompt and output handling risks of their own. Those are different control problems, but they now sit in the same delivery pipeline. Security teams need one operating model that can govern both the code and the model layer without assuming they fail independently.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Reachability has become the practical filter for AI-assisted development because teams can no longer afford to treat every generated flaw as equally urgent. A vulnerability that never executes is a governance distraction, while a reachable flaw on an exposed workload is the one that changes risk.

Code-to-cloud context: security teams should judge AI code security tools by whether they can trace a line of code to the runtime asset and data it reaches. That is the difference between descriptive scanning and prioritisation that actually changes remediation order.

For practitioners

• Prioritise reachable findings first Rank AI-generated code issues by whether the vulnerable path is actually executed in production and whether it touches exposed workloads or sensitive data.
• Verify every generated dependency Require package existence checks, publisher validation, and dependency pinning before any model-suggested import is accepted into the build pipeline.
• Scan secrets at commit and pull request time Look for API keys, tokens, and other credentials in code, history, and PR diffs, then revoke anything that reaches a shared branch.
• Gate AI-generated code with PR review Apply human approval to authentication flows, shared libraries, and code that can change access control or expose customer data.

Key takeaways

• AI-generated code introduces a distinct risk profile because insecure patterns, invented dependencies, and exposed secrets can appear at scale even when the code looks plausible.
• The best evidence in the article is that hallucinated packages appeared in 5.2% of commercial-model outputs and 21.7% of open-source-model outputs, with more than 205,000 unique fake package names identified.
• Security teams should move from severity-led triage to reachability-led triage so they fix the findings that can actually be executed in production.

Key terms

• AI Code Security: AI code security is the practice of finding and controlling vulnerabilities introduced by generative coding tools and AI-assisted development workflows. It combines AppSec, policy enforcement, and runtime validation so machine-generated code is checked for unsafe logic, hallucinated dependencies, and secret exposure before production.
• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• 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.
• Code-to-Cloud Context: Code-to-cloud context links a source code finding to the workload, service, and data it can reach in production. It lets security teams prioritise by real blast radius instead of abstract severity. For cloud estates, it is one of the clearest ways to turn scan results into operational decisions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.