Vibe coding changed the unit of software development. The unit is no longer a function a developer writes, or even a pull request a developer reviews. It is an instruction given to an agent, a patch synthesized across a repository, and a human approval that often means "the app still works." That workflow is fast. It is also exactly where security defects become invisible.
The old security model assumed comprehension was expensive but present. A developer understood enough code to notice strange privilege boundaries, odd dependencies, missing authorization checks, or suspicious configuration. AI-native development breaks that assumption. The human now reviews the product, not the path by which the product was produced.
The defining failure mode of vibe coding is not broken code. It is working code whose security properties were never part of the objective function.
AI Security ResearchThe functionality-security gap#
The strongest empirical signal is now consistent across benchmarks: coding agents optimize for task completion before they optimize for secure behavior. Veracode's 2025 GenAI Code Security Report tested more than 100 models across 80 tasks and found that 45% of generated samples introduced known OWASP Top 10 flaws. Security performance stayed flat even as models improved at producing syntactically valid code.
Repository-level agent benchmarks make the gap sharper. SusVibes evaluates coding agents on real-world feature requests derived from historically vulnerable implementations. The reported pattern is uncomfortable: frontier agents can pass functional tests while most of those successful patches still fail security checks. In other words, the acceptance signal developers trust most is not a reliable proxy for safety.
The lesson is not "do not use agents." The lesson is that a coding agent must be treated as a high-throughput junior developer with root access to your codebase, not as an oracle. Every generated patch needs provenance, policy, and adversarial review before it becomes production software.
Where the new attack surface appears#
AI-generated code expands the software supply chain backward into places security teams rarely governed: prompt text, repository rules, IDE context, package recommendations, tool calls, generated tests, and agent memory. These artifacts are not passive documentation anymore. They shape executable output.
Poisoned instructions
Rule files, READMEs, comments, tickets, or copied snippets can steer an agent toward insecure patterns while appearing harmless to human reviewers.
Hallucinated packages
Slopsquatting turns model-generated fake package names into a registry attack: attackers publish the names agents repeatedly invent.
Intent drift
The code satisfies the requested feature while violating an unstated invariant, such as tenant isolation, authorization scope, or data minimization.
Automation bias
Humans are more likely to approve plausible generated code, especially when tests pass and the agent explains the patch confidently.
-
2025Rules File Backdoor Pillar Security showed that hidden Unicode and poisoned AI configuration can influence tools such as Cursor and GitHub Copilot to generate vulnerable code that blends into normal suggestions.Context
-
2025Package hallucination at scale Researchers generated 576,000 Python and JavaScript samples across 16 code models and found that 19.7% of recommended packages did not exist, creating repeatable targets for slopsquatting.Supply chain
-
2025-2026Repository-level insecurity SusVibes-style evaluations show that agent patches can satisfy feature tests while preserving exploitable CWE-class flaws, proving that correctness and security must be evaluated separately.Benchmark
The hard part is semantic assurance#
Most application security tooling asks whether code contains known-bad patterns. That remains necessary, but vibe coding creates failures that are less about syntax and more about intent. Did the implementation preserve the authorization model? Did it add an unexpected data path? Did it introduce a dependency the spec never required? Did it weaken a boundary to make the feature easier to ship?
This is why adversarial evaluation matters. The generator's job is to satisfy the feature. The adversary's job is to search for ways the feature can be satisfied while breaking a security invariant. Secure autocode requires both signals in the loop.
Research direction: The next meaningful benchmark is not "can the agent code?" It is "can the agent preserve security invariants while coding inside a real repository with real dependencies, ambiguous requirements, and hostile context?"
What a secure vibe-coding pipeline needs#
The defensible posture is not a ban on coding agents. It is a controlled pipeline that assumes generated code is untrusted until proven otherwise. The controls should be close to the developer experience, automated enough to preserve velocity, and strict enough that "the agent said it is fine" has no security weight.
-
Govern model-facing context as executable influence Scan rules, prompts, READMEs, issue bodies, comments, and pasted snippets for hidden Unicode, instruction injection, and policy-override language. Treat these files like build scripts, not documentation.
-
Require package existence and reputation checks Block generated dependency additions unless the package exists, has expected ownership, version history, signatures where available, and a risk score that passes policy. This directly reduces slopsquatting exposure.
-
Separate functional correctness from security approval Run SAST, SCA, secret scanning, IaC scanning, dependency review, and targeted security tests as independent gates. Functional tests should never downgrade security findings.
-
Add semantic policy checks for critical paths Authentication, authorization, payments, tenant isolation, data export, cryptography, and agent tool execution need data-flow and invariant checks that compare the patch to intended behavior.
-
Keep provenance for every generated patch Record prompts, tool calls, model identity, context files, dependency changes, generated tests, and human approvals. Incident response needs to know what influenced the code, not only who clicked merge.
The frontier: adversarial training for code agents#
The long-term answer is not simply better linting after generation. It is training and orchestrating coding agents with security as a first-class reward. A generator should learn that an implementation is incomplete if it passes tests but violates least privilege. A reviewer agent should learn to search for exploitability, not style issues. A CI system should convert those signals into merge decisions.
There is a useful analogy to generative adversarial training, but the goal is not to build a literal GAN around every pull request. The goal is to make secure synthesis adversarial by default: one system proposes, another attacks, and the pipeline rewards patches that survive both functional and hostile evaluation.
This is the research program that matters for AI software security: secure-by-construction agents, adversarial security rewards, repository-level benchmarks, semantic vulnerability discovery, and provenance-aware CI/CD. The organizations that build these controls now will be able to use coding agents aggressively. The ones that do not will accumulate software they can run but cannot trust.