AI can write code that works. AI cannot, reliably, write code that is safe. Those are two different claims, and most teams shipping AI-generated software are only checking the first one.

The gap between them is not theoretical. A benchmark of AI coding agents tested against 200 real feature requests pulled from open-source projects found that 61 percent of the code produced by one of the strongest setups, an agent running on Claude 4 Sonnet, passed functional tests. Only 10.5 percent of that same code passed a security review. The code ran. It did what it was asked to do. Whether it was safe to ship turned out to be a completely separate question, and most of the code in that benchmark failed it.

That is the gap this piece is actually about, and testing keeps finding it: not whether AI can write code, it clearly can, but what is quietly wrong with the code once someone looks past "does it run."

AI Makes Building Applications Faster

Vibe coding, describing what an application should do in plain language and letting an AI agent write the implementation, has moved from novelty to default in a single year. Tools like Claude Code, GitHub Copilot, Cursor, and Replit now generate a meaningful share of production code at organizations that would never have described themselves as "AI-first." The appeal is straightforward: a feature that used to take a sprint can be scaffolded in an afternoon, and a small team can ship at a pace that used to require a much larger one.

None of that speed is illusory. IBM's own research on AI-assisted development teams found they shipped code four times faster than teams working without AI assistance. What that research also found is the part fewer teams are budgeting for.

But Speed Comes With a Security Problem

The same IBM research found AI-assisted teams shipped ten times as many security flaws, a gap too large to explain by speed alone. Part of the reason is structural: AI-assisted pull requests run 250 percent larger on average, and "mega PRs" of a thousand-plus line changes rose from 8 percent to nearly 14 percent of all submissions in a single year. A flaw hiding inside a sprawling, multi-file change is far easier to miss than one sitting alone in a 40-line diff, whether the reviewer is a person or an automated tool tuned to flag correctness issues rather than emerging AI-specific patterns.

The risk also does not stay contained to one codebase. Researchers at Georgia Tech's School of Cybersecurity and Privacy built a tool called Vibe Security Radar specifically to trace vulnerabilities back to the AI tool that generated them, scanning more than 43,000 public security advisories in the process. What they found was an accelerating curve: roughly 18 confirmed cases across the second half of 2025, 56 cases in the first three months of 2026 alone, 35 of those in March 2026 by itself, more than the entire prior year combined. As one researcher put it, "millions of developers using the same models means the same bugs showing up across different projects." A flaw one AI model tends to introduce is not an isolated incident. It is a pattern that shows up again in every other codebase that model touched, at a speed no single traditional vulnerability ever spread at.

AI coding tools have also opened attack categories with limited precedent in traditional development. Slopsquatting exploits the fact that language models occasionally hallucinate package names that do not exist, names an unfamiliar developer may install without noticing they were never real, until an attacker registers that exact name with malicious code inside it. A rules file backdoor hides malicious instructions inside a coding agent's configuration file using invisible Unicode characters, invisible to a human reviewing the file, fully legible to the model executing it. That mismatch, more than any single vulnerability class, is why the rest of this data looks the way it does.

What Vulnerabilities Are Actually Showing Up?

Pull together every major test of AI-generated code published in the last year and the same handful of vulnerability categories keep recurring:

  • Broken access control and authorization logic. A study from AI security firm Tenzai tested five widely used coding agents, Claude Code, OpenAI Codex, Cursor, Replit, and Devin, across 15 applications. The most serious flaws it found were not injection bugs at all, they were API authorization logic errors and business-logic vulnerabilities, the kind that require understanding what an application is supposed to do before anyone can tell it is doing something it should not.
  • Injection flaws. Veracode's 2025 GenAI Code Security Report, the most rigorous public benchmark to date at over 100 large language models and 80 coding tasks, found an 86 percent failure rate on cross-site scripting and an 88 percent failure rate on log injection. SQL injection fared better at a 20 percent failure rate, and cryptographic handling better still at 14 percent, but the overall pass rate across all categories, 55 percent, has stayed roughly flat since the report was first published.
  • Hardcoded secrets and exposed credentials. Security firm Escape scanned 5,600 applications built with popular vibe-coding platforms and found more than 2,000 highly critical, exploitable vulnerabilities, including over 400 leaked secrets, API keys, tokens, and credentials sitting in code or configuration where any visitor could find them.
  • Improperly protected personal data. The same Escape scan found 175 separate instances of exposed personally identifiable information, including bank account data, sitting in applications that were already live.
  • Misconfigured APIs and missing baseline protections. In Tenzai's testing, every one of the five coding agents introduced a server-side request forgery vulnerability, and zero implemented CSRF protection or set basic security headers.

Language matters too. Veracode found Python-generated code passed security review 62 percent of the time, while Java-generated code passed only 29 percent of the time, with JavaScript and C# landing in between. And Tenzai found not a single exploitable SQL injection or XSS vulnerability across its 15 test applications, which sounds like progress until it is read alongside everything above. The categories AI models are getting better at avoiding are exactly the ones automated tools are best at flagging. The categories still showing up, broken access control, exposed secrets, misconfigured infrastructure, are the ones that require understanding what a system is supposed to do, not just what it is syntactically doing.

Why Automated Scanning Isn't Enough

A scanner is good at a specific kind of job: matching code against a known-bad pattern. It can flag a query string built through direct concatenation. It can flag a dependency with a published CVE. What it cannot do is evaluate whether a piece of logic that looks syntactically fine is quietly letting one user reach another user's data, because that judgment depends on what the application is supposed to allow, not on what the code looks like.

Tenzai's own researchers put the underlying problem plainly: AI agents "lack this common sense and depend mainly on explicit instructions" when a vulnerability depends on context rather than syntax. Whether a given outbound request is dangerous, for instance, depends entirely on what internal resource it can reach, information that lives in the deployment environment, not in the request's syntax. A scanner checking for a known-bad pattern will not flag an authorization check that is syntactically correct and logically absent, and neither will a model that was never told, explicitly, that the check needed to exist. This is also why the Veracode and Tenzai findings do not contradict each other: a model can get genuinely better at avoiding textbook SQL injection while staying just as blind to a permissions check nobody explicitly asked it to write.

What Manual Penetration Testing Reveals

This is where the difference stops being theoretical. A manual tester works through an application the way an attacker would, not the way a scanner does, and that changes what surfaces. A human tester can:

  • Manipulate a multi-step workflow out of its intended order to see what state the application allows.
  • Test privilege boundaries directly, attempting to reach another account's data or another role's actions.
  • Chain several minor weaknesses together into one exploitable path, something no single automated check is built to notice.
  • Abuse business logic, exploiting what an application technically permits rather than what it was designed for.
  • Confirm whether a flagged weakness is actually exploitable, separating real risk from theoretical risk.

The distinction comes down to the question each approach is asking. Automated tools ask: does this code look vulnerable? Penetration testing asks: can this application actually be abused? Those questions overlap less than most teams assume, and the vulnerabilities piling up in the sections above, broken access control, exposed secrets, business logic flaws, are disproportionately the ones only the second question catches.

AI-Generated Code Needs Human Validation

None of this is an argument against using AI to write code. It is an argument against treating "the code works" as evidence that it is safe to ship. Automated scanning, SAST, DAST, and dependency checks still matter, and they remain the fastest way to catch the injection flaws and known-bad patterns that show up constantly at AI-assisted volume. What they are not built to catch is the category this data keeps surfacing: broken access control, exposed credentials, and context-dependent logic flaws that only reveal themselves when someone actually tries to abuse them.

For Philippine and Southeast Asian organizations, this is not a future problem to plan around, it is already the present one. The Philippine AI Report 2025 found that adoption among local developers is "widespread but remarkably shallow," with many teams leaning on basic autocomplete rather than a security-aware workflow built around it. Organizations already sense the trade-off: in a NielsenIQ survey of IT decision-makers across eight Asian markets, 51 percent of Philippine respondents named data privacy and security as the single biggest obstacle to broader AI adoption, ahead of cost and every other concern on the list. That instinct is well-placed. What is missing, in most organizations, is a testing process actually built around what AI-generated code gets wrong.

That is where Secuna Pentest fits into an AI-assisted pipeline: manual testers who ask the question a scanner never thought to ask. As AI changes how fast code gets written, security testing has to change with it, adding the layer built for exactly the flaws speed is now producing at scale. Secuna Pentest helps organizations find out what their AI-assisted codebase actually shipped with, before an attacker does.

To learn more, reach out to our team at [email protected] or explore our services at secuna.io.

Sources: Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks, arXiv · AI-Generated Code Security Risks: What Developers Must Know, Veracode · Output From Vibe Coding Tools Prone to Critical Security Flaws, Study Finds, CSO Online · Bad Vibes: AI-Generated Code Is Vulnerable, Researchers Warn, Georgia Tech Research · The State of Security of Vibe Coded Apps, Escape · Vibe Coding Security Risks Aren't Like Ordinary Security Risks, IBM · AI-First Dev Tools Reshape Philippine Web Outsourcing, 365 Outsource · Data Security Tops AI Adoption Concerns Among PH Firms, Newsbytes.ph