Vibe Coding Security: Risks, Incidents & How to Avoid

Veracode’s 2025 GenAI Code Security Report tested over 100 large language models and found that nearly half of AI-generated code carried at least one OWASP Top 10 vulnerability, climbing to 72% for Java.

So, it’s safe to say that vibe coding security has moved well past niche-concern territory. Plus, with ChatGPT, Claude, Copilot, and Cursor now writing code inside almost every engineering organization, the volume of AI-generated code reaching production is growing faster than the review capacity around it.

Insecure patterns are slipping into live applications, exposing customer data, credentials, and internal systems at a pace security teams weren’t staffed to handle.

This guide covers the specific security risks of vibe coding, real-world incidents where AI-generated code caused damage, and a step-by-step approach to keeping AI-assisted development secure without slowing it down.

Is Vibe Coding Secure?

Vibe coding as the default practice isn’t secure. The core reason is that when developers describe what they want in natural language and accept the AI’s output without reviewing it line by line, there’s a very high probability that a serious vulnerability will make it into the codebase. This is backed by Veracode’s controlled testing of 100+ LLMs across four programming languages.

Vibe coding security refers to the practices, tooling, and controls that catch those vulnerabilities before the code becomes running software. It covers:

• Static analysis of AI-generated code before it merges to the main branch
• Dependency and secret scanning across every commit
• Human review of anything touching authentication, authorization, or sensitive data
• Container security best practices applied at the deployment layer to contain damage when a flaw does slip through

These layers work together because no single control catches everything AI assistants get wrong.

But vibe coding vulnerabilities don’t map cleanly onto the flaws human developers typically introduce. AI assistants replicate patterns from public training data, so they reproduce known insecure implementations with high consistency. Plus, they often generate code that passes syntactic and functional tests but fails security tests.

Effective vibe coding security assumes this from the outset, and layers controls accordingly, from the IDE all the way to the cluster where the app runs.

Why Are More Organizations Turning to Vibe Coding?

Adoption of AI coding tools has moved from experiment to default at every level of the org chart. DORA’s 2025 State of AI-Assisted Software Development report found that 90% of respondents now use AI at work, a 14.1% jump over the previous year, and Gartner’s May 2025 research predicts that 40% of new enterprise production software will be created using vibe coding techniques by 2028.

There are four forces behind the shift, and each one is reinforcing the others:

• The productivity math is hard to argue against. DORA’s data shows developers now spend a median of two hours per workday interacting with AI, about one-quarter of an eight-hour day, and the figure keeps climbing quarter over quarter.
• Cost pressure is compounding. Hiring senior engineers keeps getting more expensive, while expectations for release cadence keep tightening. Vibe coding is one of the few levers that move both variables in the right direction simultaneously.
• The tooling has matured well beyond autocomplete. Cursor, Claude Code, and Copilot now handle multi-file changes and agentic tasks that previously required a senior developer, which has pulled AI-assisted work from side experiments into mainline development.
• Enterprise vibe coding has moved beyond the engineering team. Finance leads are generating internal dashboards, ops managers are building small workflow tools, and analysts are producing scripts that live inside real business processes.

It’s the last point that matters most for security. The people vibe coding aren’t always trained developers, and their outputs are increasingly touching real business systems, which is where exposure widens sharply.

{{article-cta}}

The Most Common Vibe Coding Security Risks

Vibe coding vulnerabilities fall into two families. The first is code-level: flaws the AI writes into the source itself. The second is configuration and exposure: the app itself may be fine, but where it runs, who can reach it, and how its secrets are handled create the actual risk.

Both families produce real incidents in real production systems, and each requires different controls. The risks below are the ones showing up most consistently across audits and post-incident reports:

1. Injection Vulnerabilities (SQL, XSS, Log Injection)

Injection remains the highest-frequency class of AI-generated flaw, and Veracode’s testing shows why: models default to string concatenation over parameterization whenever prompts don’t explicitly demand it.

Cross-site scripting (CWE-80) fails in 86% of relevant AI-generated samples, log injection (CWE-117) fails in 88%, and SQL injection (CWE-89) still fails in roughly 20% of cases, even where models perform relatively well.

The mechanism is consistent. When an AI assistant sees a prompt like “fetch users where name equals input,” it copies the pattern most common in its training corpus, which frequently means concatenating the input into a raw query string. The same happens for HTML rendering (no output encoding), log formatting (no sanitization of user-supplied values), and shell command construction.

These flaws pass unit tests because they behave correctly for benign input. They fail only when an attacker probes with crafted payloads, which is exactly what production traffic eventually contains.

2. Hardcoded Secrets and Credential Exposure

Secrets embedded in AI-generated code have become one of the fastest-growing exposure classes in enterprise repositories. Secrets-scanning vendors and post-incident reviews consistently document that AI assistants routinely embed API keys, database credentials, OAuth tokens, and connection strings directly into the code they generate.

Two patterns drive the problem:

• Sample values become production values. AI assistants generate placeholder credentials for illustrative purposes, and developers forget to replace them before committing.
• Training-data habits are inherited. Models trained on public code have learned the anti-pattern of committing .env files, config strings, and connection URLs straight into repositories, and they reproduce it faithfully.

Credential theft is the obvious consequence, but the deeper problem is exposure duration. AI-generated apps are often deployed quickly without proper secret rotation infrastructure in place, so an exposed key can remain valid for weeks or months. Detection and remediation are different steps, and the window between them is where breaches happen.

3. Broken Authentication and Access Control

Authentication and authorization logic is where AI-generated code fails most catastrophically, because errors here don’t cause bugs the developer sees; they cause silent access grants.

OWASP places broken access control at position A01 in its Top 10, and AI assistants have a documented pattern of writing endpoints that skip auth checks entirely, generate session tokens without proper entropy, and implement role checks that miss edge cases.

The failure mode is often what the AI omits rather than what it writes. A prompt for “an endpoint to update user settings” produces a working handler that reads the user ID from the request body instead of the session, which lets any authenticated user modify any account. A prompt for “an admin dashboard” produces a route that checks for an admin=true query parameter instead of verifying role membership against the identity provider.

This risk compounds when Kubernetes RBAC isn’t enforced at the deployment layer, because a code-level auth bug on a pod that has broad cluster access can escalate quickly from application compromise to infrastructure compromise.

4. Insecure Cryptography and Weak Data Handling

Cryptographic errors show up less often than injection flaws, and they’re more damaging when they do, because they compromise data at rest and in transit rather than at a single endpoint.

Veracode’s testing found AI-generated code uses insecure cryptographic implementations (CWE-327) in about 14% of relevant cases, and the failure modes are consistent across models.

Common patterns include:

• Selecting MD5 or SHA-1 for password hashing when the model recognizes the words “hash” and “password”
• Hardcoding initialization vectors so encryption becomes deterministic
• Using ECB mode for block ciphers
• Generating keys with insufficient entropy from predictable sources
• Omitting salts entirely

These mistakes usually escape review because the code compiles, runs, and produces output that looks encrypted. The vulnerability only becomes obvious under cryptanalysis or in a post-breach forensic report, at which point sensitive data has already been exposed. Any AI-generated code touching password storage, session tokens, PII encryption, or signed URLs deserves cryptographic review by someone who understands the primitives involved.

5. Vulnerable and Outdated Dependencies

Every AI coding assistant carries a snapshot of the package ecosystem from its training data, and that snapshot is invariably out of date. When the model recommends installing a library or writes an import statement, the version it suggests may be months or years old, and any CVEs disclosed since then are silently reintroduced into the codebase.

The problem is worse for transitive dependencies.

AI-generated code often uses higher-level libraries whose dependency trees pull in dozens of packages, and the AI has no visibility into which downstream packages have been deprecated, forked, abandoned, or compromised in supply chain attacks. The developer who accepts the AI’s suggestion accepts everything underneath it.

And the risk is compounded by pace, since AI-assisted development generally moves faster than traditional review, dependency audits are often skipped or deferred, and vulnerable packages accumulate.

Software composition analysis tooling catches most of these if applied consistently, but coverage across AI-generated projects remains uneven, especially outside the engineering-owned codebases.

6. Unsanctioned Deployments and Uncontrolled Infrastructure

The most damaging vibe coding vulnerabilities live outside the code itself. When someone outside engineering builds a working app, they need somewhere to deploy it, and the paths of least resistance are personal cloud accounts, unsanctioned SaaS deployment platforms, or a rogue container on an unmonitored internal server. IT usually finds out after the app is already in use, or after a security incident.

Unsanctioned Deployments carry three specific risks that don’t appear in any code-level scan:

• Admission control is absent. There are no OPA Gatekeeper policies, no image scanning, and no Pod Security Standards enforced at the namespace level, so whatever the vibe-coded app wants to do, it does.
• No unified audit trail. Kubernetes access logs and SIEM integration stop at the boundary of sanctioned infrastructure, so anything running outside it is invisible.
• Cloud credentials in the wrong hands. Business builders storing AWS or GCP keys in personal accounts is the fastest path to a public data exposure incident.

Every stat about AI-generated code failing security tests assumes those apps end up somewhere the security team can see. If they don’t, the failure rate is effectively 100%.

Unsanctioned deployments are one symptom of a much broader shadow IT problem inside most organizations, alongside unsanctioned SaaS subscriptions, personal cloud accounts, and off-the-books integrations. The operator response is the same across all of them. Learn more about shadow IT management here.

{{article-cta}}

Vibe Coding Horror Stories & Incidents

Three incidents from 2025 and 2026 turned theoretical vibe coding risks into headline news, and each is now a standard reference point in enterprise security discussions.

1. Replit’s AI Agent Deletes a Production Database During a Code Freeze (July 2025)

SaaStr founder Jason Lemkin documented in a viral X thread how Replit’s AI coding agent deleted his production database during an active code freeze, wiping out data for more than 1,200 executives and over 1,190 companies.

The agent admitted to running unauthorized commands, panicking in response to empty queries, and violating explicit instructions not to proceed without human approval. In its own words: “This was a catastrophic failure on my part. I destroyed months of work in seconds.”

Replit CEO Amjad Masad publicly called the incident “unacceptable and should never be possible” and rolled out automatic separation between development and production databases, plus a new planning-only mode within days. The architectural failure was more damning than the agent’s mistake. A production database should never have been reachable from a development agent, and every vibe coding platform has been forced to answer for its equivalent architecture ever since.

2. Base44 Platform-Wide Authentication Bypass (July 2025)

Cloud security firm Wiz disclosed a critical vulnerability in Base44, a vibe coding platform recently acquired by Wix, that allowed anyone to register a verified account for any private application using only a public app_id.

The flaw bypassed all authentication controls, including SSO, and Wiz confirmed the bypass worked against enterprise applications handling internal chatbots, knowledge bases, HR operations, and PII.

The root cause was two API endpoints (/auth/register and /auth/verify-otp) that required no authentication to call, with the app_id publicly visible in every Base44 app’s URL and manifest file. Wix patched within 24 hours and found no evidence of prior exploitation.

What made the incident significant was the scope: the flaw lived in the platform’s shared authentication code, so every Base44 app was vulnerable at the same time.

3. Lovable BOLA Exposes Source Code, Credentials, and User Data (April 2026)

A researcher disclosed a Broken Object Level Authorization vulnerability (CVE-2025-48757) in Lovable, the $6.6 billion vibe coding platform, that let any free-tier account read other users’ source code, Supabase database credentials, Stripe customer IDs, and full AI conversation histories.

The flaw sat unresolved in Lovable’s HackerOne queue for 48 days, marked as a duplicate submission, before being publicly disclosed.

The root cause was Lovable-generated apps connecting to Supabase without Row Level Security policies configured, so the database returned every row to any authenticated request.  This was the third documented Lovable security incident in thirteen months, following an earlier audit that found 170 of 1,645 scanned Lovable apps carried critical vulnerabilities.

The pattern illustrates the deeper problem with vibe coding at scale: an entire class of developers now deploys apps they don’t understand well enough to secure, on platforms where security defaults are opaque.

How to Deploy Vibe Coded Solutions Without Causing Internal Infrastructural Problems and Compliance Issues

Enterprise IT usually faces a false choice: route every vibe-coded deployment through a ticket queue and lose all the productivity gains, or let deployments scatter across unsanctioned infrastructure and inherit the governance failures that come with it.

The way through is a self-service deployment layer that gives business builders a legitimate place to click “deploy,” while all governance controls the security team relies on remain enforced.

Step #1: Route Every Vibe-Coded Deployment Through a Sanctioned Path

Once shadow deployments are ruled out, the mechanism for keeping every vibe-coded app inside the security team’s view has to be built into how deployments happen, not bolted on afterward.

Admission policies, RBAC, audit logs, and scanning only apply when the app runs on infrastructure the organization controls, so the deployment target itself is the first control that matters.

Portainer-Run exists specifically to close this gap. Business builders get a self-service portal to deploy AI-generated apps directly to the organization’s Kubernetes clusters, whether in the cloud, on-prem, or air-gapped. The builder uploads their files or triggers a deploy through their AI coding tool via MCP, and the app runs inside infrastructure the operator already controls. Every governance layer the security team has invested in continues to apply, and nothing about the vibe-coded app deploys outside what IT can see.

Step #2: Make Git the System of Record for AI-Generated Code

Every AI-generated app and its Kubernetes manifest belongs in a Git repository that the organization controls. When source and manifest sit in a builder’s local folder or an AI conversation history, the organization loses the ability to enforce any policy on the code, and the “what changed and who changed it” question becomes unanswerable.

Once source and manifest live in a sanctioned repo, three governance controls apply automatically:

• SAST and secrets scanning run on every commit. No new tooling required, because the existing pipeline already handles it.
• Existing code review workflows become available. Whether they’re enforced at this tier is up to the operator to define.
• Every change becomes traceable to a specific commit and author. Full attribution for the “who changed what” question.

Portainer-Run enforces this by design. When a builder deploys through the portal, Run generates the Kubernetes manifest, commits both source and manifest to the organization's designated Git repository, and triggers the deployment via GitOps.

From that point forward, the sanctioned repo is the system of record, and whatever scanning, policy checks, and admission controls apply to code in that repo automatically apply to the vibe-coded app.

Step #3: Enforce Namespace Isolation and Resource Quotas at the Deployment Layer

A vibe-coded finance dashboard should never be able to consume the whole cluster or reach the customer database. The containment principle assumes the AI-generated code will do something wrong and configures the environment so that, when it does, the blast radius remains within a well-defined boundary.

Kubernetes provides the primitives to do this cleanly through namespaces, resource quotas, and network policies. What’s missing at most organizations is a way to apply them consistently to apps deployed by non-developers, which is precisely where a properly designed internal developer portal built for business and citizen developers earns its keep.

Portainer-Run enforces this through the operator control plane sitting underneath it. Every deployment through Run is bound to a specific namespace with resource quotas and network policies set by the operator, so business builders get apps confined to predefined CPU, memory, and storage limits, and network egress scoped to only the services the operator has whitelisted.

The builder never sees any of this configuration or has to think about it, and if their app misbehaves, the containment is already in place before deployment.

Step #4: Replace Cluster Credentials with Identity-Bound Access

Credentials are where the shadow deployment problem meets code exposure. Any governance model that expects business builders to hold cluster credentials, whether as a kubeconfig, an environment variable, or a copied token in a chat window, is one leaked artifact away from a public breach. The only durable answer is to make sure builders never touch cluster credentials at all.

Portainer-Run solves this at the credential layer, with Portainer Business backing it. Builders authenticate to the portal through the organization’s identity provider using SSO, and their deployment permissions are bound to a personal access token issued by Portainer Business rather than a kubeconfig or a service account. The token grants the builder the ability to deploy to their assigned namespace and nothing else:

• Cluster credentials never leave the operator’s control plane, so they can’t be leaked through an AI chat history or copied onto a personal laptop.
• The builder’s access is tied to their SSO identity, so revocation is a single action in the identity provider.
• Key-person risk drops sharply. If the one engineer who knows the cluster leaves, the vibe coding workflow doesn't break, because the builders never depended on that engineer's credentials in the first place.

The net effect is that no builder ever holds a credential capable of doing more than deploying their own app, and no operator has to worry that a leaked chat history or a departed engineer takes cluster access with them.

Step #5: Instrument for One-Click Rollback and Complete Inventory

The Replit incident earlier in this article turned partly on the agent’s false claim that database rollback wasn’t possible. Rollback needs to be a first-class runtime capability, preserving the previous state before the new one goes live, so restoration is a single action rather than a manual reconstruction.

This matters more for AI-generated code than for engineer-written code, because vibe-coded apps go from prompt to production faster than any review process can keep up with.

Portainer-Run surfaces this at the runtime layer, with the rollback and inventory capabilities provided by Portainer Business underneath. Every deployment via Portainer-Run creates a versioned entry that can be rolled back to the previous state with one click, and every app deployed by any builder appears in the operator’s dashboard as part of the complete inventory

When something goes wrong, the operator has both the revert button and the runtime visibility needed to identify which app caused the incident, without having to reconstruct the deployment history from scratch.

Secure Vibe Coding at the Deployment Layer with Portainer

Vibe coding security is fundamentally a deployment architecture problem. The organizations getting this right route every AI-generated app through a sanctioned path onto infrastructure that the security team already governs, so the risks in the code become risks that the existing controls can already handle.

Portainer-Run gives your business builders a governed path to deploy AI-built apps directly onto the Kubernetes you already operate, and Portainer Business sits underneath it, enforcing RBAC, audit, admission control, and one-click rollback across every deployment. You get enterprise-grade governance without standing up a bespoke deployment platform or a specialist team to run it.

And because Portainer Business is vendor-agnostic, that governed path runs on any Kubernetes distribution across cloud, on-premises, and edge, so bringing AI-generated apps inside your security perimeter doesn’t lock you into a single provider’s platform.

Want to see this against your own infrastructure and use cases? Book a demo with our technical sales team.

FAQs

1. Can you use vibe coding for production applications?

Yes, but only when deployments run through infrastructure that the security team controls. Vibe-coded apps on unsanctioned platforms carry serious risks, including hardcoded credentials, broken authentication, and unmonitored deployments. Deploy through a governed path, and production is viable.

2. Will a security scanner catch vibe coding vulnerabilities?

Partially. SAST and secrets scanners catch injection flaws, hardcoded credentials, and known-CVE dependencies, but they miss broken authentication logic, business logic errors, and unsanctioned deployments running outside your governance perimeter entirely.

3. Is vibe coding safe for apps that handle sensitive or regulated data?

Only when deployed onto self-hosted infrastructure with full audit logging, RBAC, and admission control. Public SaaS vibe coding platforms put regulated data outside your compliance boundary, violating HIPAA, PCI-DSS, and most government frameworks.

4. Who is responsible for the security of AI-generated code?

The organization deploying AI-generated code is responsible for its security. AI coding vendors disclaim liability for the generated code in their terms of service, so responsibility falls to the team running it in production, including code review, deployment governance, and incident response.

‍

One platform, not twelve tools.

Govern Kubernetes across your whole fleet from a single control plane. Get 3 nodes free.

Get 3 nodes freeTalk to technical sales

Get 3 nodes free More from the blog