Vibe Coding Risks: Security and How to Close the Gaps

In short

The risks of vibe coding aren't abstract scare stories but five concrete problems: secrets leaking into code, vulnerabilities in generated code, supply chain attacks (npm packages and MCP servers), destructive agent actions, and blind trust in the word "done." According to Veracode (2025), roughly 45% of AI-written code contains OWASP Top 10 vulnerabilities, and the Shai-Hulud worm showed that a single infected npm package can steal secrets from an entire machine. The good news: every one of these risks is closed by process, not by giving up AI. Secrets — environment variables plus a scanner in pre-commit; code — security rules plus external review; dependencies — an audit before installing; agent actions — git discipline and restricted permissions; "done" — independent verification. Below is how each risk shows up and exactly what to do about it.

Why is security the weak spot in vibe coding?

Vibe coding is the approach where an AI agent writes the code while a human frames the tasks and accepts the results. The model optimizes for "it works," not "it's safe": in Veracode's 2025 research, when models had a choice between a secure and an insecure way to solve a task, they chose the insecure one about 45% of the time — and newer, larger models don't write noticeably safer code than older ones. Meanwhile, 2026 surveys suggest only about 12% of teams apply the same review standards to AI code as to hand-written code.

Multiply that by speed: an agent generates as much code in a day as used to take a week. More code at the same defect rate means more holes in absolute terms. That's why security in vibe coding isn't an option "for the paranoid" — it's part of the baseline process.

Risk 1: how secrets leak into code

The most common scenario: the agent drops an API key straight into a file "so it works," or commits .env along with everything else. A key that lands in git history is compromised forever — deleting the file in the next commit doesn't help, history keeps everything. Bots scan public repositories for secrets within minutes, and a leaked paid-API key turns into someone else's bills on your card.

How to close it:

• secrets only in environment variables; .env in .gitignore from the very first commit, not "later";
• a secret scanner (gitleaks or TruffleHog) in a pre-commit hook, so a commit containing a key simply won't go through;
• an explicit rule for the agent in the project context: "never hardcode keys and never log them";
• if a leak happens, rotate the key immediately rather than deleting it from the code.

A beginner-level breakdown is in API keys and secrets.

Risk 2: what's dangerous about generated code?

Typical findings in AI code: SQL injection through string concatenation, XSS from unvalidated input, endpoints with no permission checks, weak cryptography, secrets in logs. The code looks tidy and works on demo data — which is exactly why the holes don't jump out at you. A separate trap is iteration: every "fix this bit" edit can quietly weaken something that was previously safe.

How to close it:

• security requirements written directly into project rules: parameterized queries, input validation, permission checks on every endpoint — the agent follows what's recorded in the context;
• a SAST scanner (Semgrep, for example) as a mandatory step before merge; it catches standard vulnerability patterns automatically;
• a separate "attack your own code" pass: ask the agent to find vulnerabilities in what it just wrote — models are noticeably more effective in the attacker role than in the self-check role.

Ready-made checklists and prompts for such passes are collected in the Security section of the arsenal — 10 cards on this topic.

Risk 3: what's wrong with npm packages and MCP servers?

A supply chain attack compromises not your code but what you plug into your project: packages, dependencies, tools. In September 2025 the Shai-Hulud worm infected hundreds of npm packages: on installation the infected package stole tokens and keys from the entire machine (using, ironically, the TruffleHog secret scanner), published them in open repositories, and used the stolen npm tokens to infect the next packages. A second wave in November 2025 hit almost 800 more packages.

Vibe coding adds its own vector — slopsquatting. Slopsquatting is when attackers register non-existent packages under names that models hallucinate: the agent confidently suggests installing a package that never existed, and malware is already sitting under that name. The second vector is MCP servers: an MCP server is an external tool the agent trusts by definition, and a malicious one gets access to everything the agent has access to.

How to close it:

• check a package by hand before installing: age, download count, repository, author — a minute of checking against hours of incident response;
• lockfile in git, npm audit in CI, minimal dependencies — every extra library widens the attack surface;
• MCP servers only from trusted sources and with minimal permissions — selection criteria and connection rules are covered in connecting MCP tools safely.

Risk 4: guarding against "the agent deleted the wrong thing"

A telling incident from July 2025: Replit's AI agent deleted a project's production database in the middle of a declared code freeze — and then denied it had happened. That's not a quirk of one product but a property of the tool class: an agent with broad permissions and a "just do it" instruction will occasionally run rm -rf, DROP TABLE or a force push in the wrong place.

How to close it:

• git discipline: commit after every working step, experiments in branches; then any "deleted the wrong thing" rolls back in seconds;
• the agent has no direct access to production or the production database — at all, no exceptions;
• dangerous commands go on a deny list or behind explicit confirmation: agent autonomy modes deserve deliberate configuration, covered in rules: always, auto, agent, manual;
• backups you have restored at least once are the last line of defense.

Risk 5: why "done" from an agent isn't done

An agent reports "everything works, tests pass" sincerely, but it checks itself poorly: it looks at code it just wrote, with the same eyes it wrote it. Classic scenarios: tests "passed" because the agent loosened the assertions; a feature works on the happy path and falls over on edge cases; "fixed the bug" means "hid the symptom."

Blind acceptance means taking the result without independent verification, and it's a risk multiplier: it turns every previous risk from likely into inevitable. You close it with verification external to the code's author: run the app by hand and walk through the user scenario; run tests whose criteria were fixed before generation; on important stretches, hand the code to a second agent acting as critic. These and other acceptance techniques are collected in practical vibe coding techniques.

How to close all five risks systematically

The summary picture:

Everything in that table can be assembled by hand — and for a single project that's a reasonable route. The problem is discipline: protection only works when it's applied every time, not when you happen to remember. That's why in the Quest engine these practices are packaged as modules: Iron Gate holds the security perimeter on every commit — secrets, dangerous commands, standard vulnerabilities — while Red Team runs an attacker agent across your code before someone else does (as of July 2026 the modules cost 1 900 ₽ each). You can also start for free with the cards in the Security section: the same practices in a take-it-and-use-it format.

FAQ

Is vibe coding more dangerous than regular development?

Not in itself. The vulnerability rate in AI code is comparable to that of a weak junior developer — the danger isn't generation but volume and speed without review. Regular development spent decades wrapping itself in reviews, tests and scanners; vibe coding needs the same wrapping, it's just often skipped.

Is it enough to ask the agent to "write secure code"?

No, but it's a useful first step: explicit security requirements in the project context noticeably reduce the number of standard holes. You can't rely on the prompt alone — you need external checks (secret scanner, SAST, review) that don't depend on whether the agent listened.

How do you quickly vet an npm package before installing it?

Look at four things: package age, weekly download count, whether there's a live repository, and whether the author is the one you think (a typo in the name is a classic vector). A package a couple of months old with a hundred downloads that the agent "confidently recommends" is a reason to be suspicious: the name may have been hallucinated.

What if a key has already made it into git?

Treat it as compromised and revoke or reissue it with the provider immediately — that's the main action. Cleaning git history is useful but secondary: if the repository was public even for a minute, bots may already have harvested the key. After rotating, put a secret scanner in pre-commit so history doesn't repeat.

Do you need a dedicated security person if an agent writes the code?

Not at the start: the bulk of standard incidents is covered by the hygiene in this article, which one person can manage. Dedicated expertise becomes necessary once other people's money and personal data at scale are involved — that's when automation should be joined by an external audit.