Broken access control has topped the last two editions of OWASP Top 10, with OWASP finding some form of it in every application in its dataset. AI coding assistants are making this worse because correct access rules depend on business logic that rarely makes it into the prompt and is hard to test.

For enterprises, these vulnerabilities can have severe consequences. Aikido’s 2026 State of AI in Security & Development report found that 1 in 5 respondents experienced a serious incident linked to AI-generated code, while almost half reported at least one minor issue.

Securing AI-generated code in an enterprise software development lifecycle (SDLC) starts from familiar principles, but applies them to code written faster than teams can realistically review it, often from developers who accepted it rather than wrote it.

Key Insights

  • Review is now the bottleneck. AI generates code faster than humans can read, pushing teams to approve changes before they’ve been fully reviewed.
  • Accepting code is now a review step. Many people who accept AI output can’t judge its security but trust it because it looks clean and runs.
  • Coding agents introduce new risks. They suggest nonexistent (hallucinated) package names that attackers register as malware, commit secrets, work in places IDE scanners can’t see, and can merge code without security checks.
  • Pattern-based scanners can’t see intent. SAST misses broken access control and business logic flaws, so AI or human code review is needed.
  • A finding without an owner doesn’t get fixed. Every check needs someone accountable for acting on it.

What Are the Problems with AI-Generated Code?

Volume is AI-generated code’s greatest strength but also a major source of problems. AI can generate massive volumes of code in seconds, but security teams can’t keep up.

The vulnerabilities in AI-generated pull requests are the same ones security teams have always dealt with, but what has changed is volume and ratio.

Aside from arriving quickly, that code often arrives riddled with flaws. A 2021 study by Pearce et al. prompted GitHub Copilot with scenarios designed around weaknesses from MITRE’s CWE Top 25, such as injection and memory-safety bugs, and roughly 40% of the 1,689 programs it produced contained the targeted weakness.

And then there’s the fact that AI has essentially democratized coding. The barrier to entry is significantly lower than it was even a few years ago, so people who don’t necessarily understand secure coding principles are shipping complex code into production.

Not only is AI-assisted code more likely to be vulnerable, but the humans who generate it are less likely to spot flaws because they “trust” the code is secure. This is the security illusion of AI-generated code.

Ironically, the problem gets worse as AI assistants attempt to refine their code. A 2025 study of 400 code samples across four prompting strategies found a 37.6% increase in critical vulnerabilities after just five iterations.

The temptation could be to hire more reviewers. But when a model wrote most of the changes in a pull request queue, the overconfidence bias shows up at the approval step, across every team at once, no matter the headcount. Adding reviewers does little if each one trusts the output in the same way.

Top Four Risks to Address When Securing AI-Generated Code

Agents Hallucinate Package Names That Point to Malware

The gap between models has narrowed since it was first measured, but it hasn’t gone away. A 2026 test of five frontier models found they still invent nonexistent packages in roughly 5% of cases, and all five invented the same 127 names, a ready-made target list for attackers.

While a non-existent package isn’t inherently dangerous, attackers can weaponize them using a technique known as slopsquatting. By pre-registering these hallucinated names on registries like npm or PyPI, threat actors wait for an unsuspecting engineer or autonomous agent to execute the AI’s install command, pulling malware directly into the enterprise build pipeline.

For enterprises, that means it’s important to validate every package against trusted registries before it installs, so a fake or hallucinated package doesn’t get installed on a dev machine or a production server. CVE-based scanners won’t flag a malicious package, because malware rarely gets a CVE, so the check needs to happen at install time against a malware feed.

The same check scans nested dependencies for malicious behaviour such as obfuscated code, data exfiltration, install scripts, and crypto miners. Companies should prevent package versions published in the last 48 hours from being installed, since compromised packages and malware are often removed within a day.

Agents Commit Secrets or Tokens by Mistake

According to GitGuardian’s State of Secrets Sprawl 2025 report, public repositories using AI coding assistants suffered a 6.4% secret leakage rate, compared to 4.6% across public repositories overall.

Stopping automated exposure in its tracks relies on deploying a pre-commit hook, a local script that automatically scans all staged changes, blocking any commit that contains hardcoded credentials, such as passwords or cryptographic tokens. Crucially, it applies the same scrutiny to developer-written and agent-generated code.

By intervening before the commit occurs, the hook catches the exposure locally on the developer’s machine, before the secret enters the Git history or CI logs. Hooks are local and easy to bypass, though, and agents often run where no hook is installed, so a server-side backstop such as push protection or a pull request secret scan should catch what gets past them. Any secret that has touched a prompt or a file should still be rotated: GitGuardian found that 70% of valid secrets detected in public repositories in 2022 were still active.

Agent-Written Code Bypasses IDE and Pull Request Checks

When developers write code, it passes two checkpoints before it ships: IDE plugins flag issues as they type, and pull requests give teammates and CI scanners a chance to review. Agents can skip both.

An agent working in a terminal or in the background never sees IDE warnings, so a SAST finding or exposed secret goes unnoticed until a later scan, possibly after the flaw reaches production. The same agent can generate code, commit it, and open a pull request in a single run, and if the pipeline allows auto-merge or a reviewer approves without reading closely, the code reaches the main branch unchecked. Vibe-coding platforms often skip pull requests altogether, so code can go from prompt to production without any review. Banning them rarely works, since employees find workarounds.

Aikido’s internal testing shows the cost. Across leading vibe-coding environments, business logic flaws accounted for every severe finding. Each platform shipped with broken access control, the only category with critical-severity findings, along with improper authentication and exposed sensitive data.

Closing the gap takes a check at each point. During generation, connect SAST and secret scanning directly to the agent environment, for example through an MCP server, so they run while the agent writes code. Pattern-based scanners are fast enough to keep pace with agent output and catch issues such as injection patterns and hardcoded credentials, and a scan-fix-rescan loop on generated and modified code lets the agent fix them before commit. Before merge, gate every pull request with a mandatory scan of the branch diff, regardless of who or what wrote the code, covering SCA, IaC, secrets, SAST, malware, and license risks.

AI-Generated Code Ships Broken Access Control

Code review can flag missing authorization checks, but it can’t prove access rules hold once the application runs. OWASP recommends adding functional access control tests to unit and integration suites, and teams should extend that testing to the running application, with cross-user and cross-tenant checks that confirm one user or tenant can’t reach another’s data. Manual testing struggles to keep up: in Aikido’s 2026 State of AI in Pentesting report, over half of respondents said logic flaws, broken access control, and multi-step vulnerabilities are always or often missed in manual testing, rising to 92% among teams shipping daily or faster.

How to Check These Top Four Risks

Because autonomous agents move so fast, they frequently rewrite or overwrite code before delayed scan results can even arrive, rendering scheduled scans alone inadequate. The pull request is the final point where security findings actually match the exact code about to merge. To catch what legacy tools miss, teams must layer context-aware AI and agentic code reviews directly on top of this PR gate, forcing the defensive tools to read application context far beyond the raw code diff.

Risk How to check
Agents hallucinate package names that point to malware Check every package at install time against a feed that tracks malicious packages, and hold back versions published in the previous 48 hours. Apply the same checks to nested dependencies, where most malicious code arrives.
Agents commit secrets or tokens by mistake Run a pre-commit hook that scans all staged changes and blocks any commit with hardcoded credentials. Apply it equally to developer-written and agent-generated code, so secrets never enter Git history.
Agent-written code bypasses IDE and pull request checks Connect SAST and secret scanning to the agent environment, such as through an MCP server, and run a scan-fix-rescan loop so agents fix issues before commit. Gate every pull request with a mandatory scan of the branch diff covering SCA, IaC, secrets, SAST, malware, and license risks, with AI code review on top to catch access control and business logic flaws.
AI-generated code ships broken access control Add functional access control tests to unit and integration suites, then test the running application before deployment with cross-user and cross-tenant checks, using automated pentesting where manual testing can’t keep pace.

The Importance of Ownership in an Enterprise SDLC

To implement checks properly, enterprises must assign an owner to each one. Otherwise, they either stall in a backlog or disappear entirely.

Today, too few organizations have this level of accountability locked down. Aikido’s 2026 State of AI in Pentesting report found that only a third of security teams hold both the authority to stop a release and responsibility for the outcome.

In a traditional Git flow, checks can run at four points:

  • in the IDE and coding agent as the developer or agent writes code
  • at pre-commit
  • at pull request review, and
  • against the running application before deployment.

At each stage, the person or team acting on the results must take responsibility for them. Security tools must explicitly record who overrode a block, why they did it, and where a check raised the finding. This granular logging gives compliance auditors a consistent, reliable record of what each pipeline verified.

When results lack a designated owner, they manifest as release delays when disputes stall merges, or as damaging audit findings when nobody can show who approved an override or why.

Familiar Flaws, Faster Delivery

The vulnerabilities in AI-generated code are the ones security teams already know, led by broken access control, which tops the OWASP Top 10. What AI changes is how quickly that code reaches production and how few people look at it on the way. Enterprises that hold agent code to the same gates as human code and assign an owner to each of those gates will close most of the gaps described here. The rest depends on reviewers who understand the business logic that scanners or models can’t see.