Security Risks of Deploying Vibe-Coded Apps to Production, and Who Fixes Each One

The main security concerns with deploying vibe-coded apps to production are code-level flaws the builder never reviewed (injection, broken authorization, insecure defaults), risky dependencies, hardcoded secrets, over-permissive infrastructure, and no record of who changed what. Fix the code-level risks with human review and automated scanning before release, and close the infrastructure risks by deploying to a platform with private networking, managed secrets, least-privilege workload identity, and an audit trail by default.

Disclosure: Control Plane publishes this guide.

TL;DR

• Code flaws (injection, XSS, insecure defaults). AI tools often reproduce insecure patterns from training data. Fix with human code review and static analysis in CI.
• Broken authorization and missing tenant checks. Generated code often skips per-record access checks. Fix with server-side authorization logic reviewed by a human and tested with two accounts.
• Hallucinated or vulnerable dependencies. AI may suggest packages that do not exist, which attackers can register, or versions with known CVEs. Fix with a human check on every new dependency, a committed lockfile, and software composition analysis in CI.
• Hardcoded secrets and exposed credentials. API keys and database URLs end up in source code and frontend bundles. Fix by rotating every exposed key, moving calls that need a key to the server, and injecting server-side secrets at runtime through the platform.
• Over-permissive infrastructure. Databases reachable from the internet, no outbound restrictions, long-lived admin keys. Fix with platform-level private networking, allowlist firewalls, and short-lived workload identity scoped by a reviewed IAM role.
• Data isolation. Sensitive data shares a database user, credentials, and network path with the rest of the app. Fix with separate workloads, database users, and credentials for sensitive data.
• Visibility and audit. Shadow deployments and missing logs make incident response slow and uncertain. Fix with a tamper-proof audit trail of platform changes, plus application logs that record sign-ins, permission changes, and data exports.
• AI features inside the app. Prompt injection, data leakage through prompts, exposed provider keys, and unbounded spend. Reduce the risk with server-side API calls, least-privilege tool access, human approval for high-risk actions, per-user limits, and output sanitization. No current technique fully prevents prompt injection.
• Where Control Plane fits. Control Plane closes the infrastructure layer: private networking by default, external and internal firewalls, runtime secrets with policy-based access, Control Plane’s Universal Cloud Identity for short-lived cloud credentials, workload isolation, mTLS between services, and a tamper-proof audit trail. It does not scan your source code or fix your authorization logic.

What are the security concerns with deploying vibe-coded applications to production?

Vibe-coded applications can ship faster than anyone reviews them. An AI coding tool generates thousands of lines that often run on the first try. Code that runs can still be insecure.

AI code generators optimize for functional correctness. They fill gaps with defaults pulled from training data, and those defaults are often insecure. Permissive CORS headers, missing CSRF protection, client-side-only authentication checks, and hardcoded API keys appear in generated output because those patterns are common in the open-source code the models learned from.

The builder may never read every line. When code appears to work, the incentive to audit it drops. Problems a pull request review would catch, such as a missing ownership check or an unvalidated redirect, pass through unnoticed. Dependencies suggested by the model may not exist, which opens the door to slopsquatting: an attacker publishes a malicious package under the hallucinated name and waits for someone to install it.

The gap between “it runs” and “it has been reviewed” is wider with vibe coding, because generation takes minutes and review has not sped up to match. Each risk lives in the code, the pipeline, or the platform, and each layer needs its own fix.

Vibe-coded app security risks and who fixes them

The table maps each risk to where it shows up in generated code, an example check you can run, and the layer responsible for the fix. A platform cannot fix injection or broken authorization, and code review cannot enforce network policy.

How do I check a vibe-coded app for these risks before production?

These are the checks you would run on hand-written code, ordered so the cheapest high-impact steps come first. Fewer people have read vibe-coded code, so each check carries more weight.

1. Scan for secrets and rotate what you find. Run Gitleaks over the full git history once, then on every commit. Rotate every credential that was ever committed or shipped in a frontend bundle.
2. Vet every new dependency and lock what you vetted. Before a package enters the manifest, confirm it is the one you intended: check the registry page, maintainer, publish date, download history, and source repository. Commit the lockfile, review every lockfile diff, and install with integrity checks (npm ci, or pip with –require-hashes). Lockfile hashes prove a package has not changed since you locked it, but they do not prove it is legitimate, so vetting before install is the defense against hallucinated packages.
3. Run software composition analysis (SCA) in CI. Trivy or OWASP Dependency-Check flag dependencies with known CVEs. SCA finds known vulnerabilities, so a newly published malicious package usually passes it; that is why step 2 comes first.
4. Run static application security testing (SAST) in CI. Tools like Semgrep catch injection, XSS, and insecure patterns before the code reaches a container image.
5. Review authentication, authorization, payments, and data-access code by hand, and test with two accounts. No scanner reliably catches broken business logic. Sign in as user A, then request user B’s records by ID through every API route, and confirm each request is refused.
6. Create least-privilege database users and review every generated migration. The app’s database user should allow only the operations the app needs. Read each schema change before it runs against production, and reject any DROP, TRUNCATE, or column rewrite nobody asked for.
7. Use a staging environment with separate credentials. Staging should never share secrets, databases, or cloud IAM roles with production.
8. Run dynamic application security testing (DAST) against staging and check headers. ZAP (formerly OWASP ZAP) tests the running app for XSS, injection, and information disclosure. Confirm that the Content-Security-Policy (including frame-ancestors), Strict-Transport-Security, and X-Content-Type-Options headers are present, that Access-Control-Allow-Origin is not a wildcard or a reflected request origin on authenticated endpoints, and that state-changing requests are protected against CSRF with anti-CSRF tokens, with SameSite cookies as an added layer.
9. Confirm that logs do not contain secrets. Search application logs for patterns matching API keys, tokens, and passwords, and redact sensitive values before they reach the log sink.
10. Turn on backups and test a restore. Restore a recent backup to a scratch database before launch and record how long it took.
11. Require MFA on every admin account. That covers your cloud provider, deployment platform, source host, domain registrar, package registry, and the app’s own admin panel.
12. Keep production credentials away from the AI coding assistant. Give the assistant its own scoped identity or a non-production environment, and keep production secrets out of its workspace.
13. Set a dependency update policy. Enable Dependabot or Renovate and patch critical CVEs within a fixed window, such as seven days.

These checks map to the OWASP Top 10 for web applications and the OWASP Top 10 for LLM Applications for any AI features your app exposes.

Which risks can the platform close by default?

A well-written application deployed with a public database, open outbound traffic, and long-lived admin keys is still exposed. The deployment platform is the right place to close these gaps because it controls the network, the secrets, the identity, and the audit trail.

A secure platform enforces seven controls.

• Private networking by default. Workloads are not reachable from the public internet unless explicitly exposed.
• An allowlist firewall for inbound and outbound traffic. Only approved addresses are open.
• Secrets injected at runtime. Credentials stay out of code, images, and environment files in source control.
• Workload identity with least privilege. Instead of long-lived cloud keys, the workload receives short-lived credentials scoped to the cloud services it needs.
• Isolation between workloads. A compromised workload cannot reach another workload’s network, secrets, or credentials unless a policy or firewall rule allows it.
• Encrypted traffic between services. Internal communication is encrypted in transit.
• A tamper-proof audit trail. Every deploy, config change, and permission grant is recorded with the identity of the actor.

Control Plane provides each of these controls. A GVC, Control Plane’s Global Virtual Cloud, is a named set of locations across one or more clouds where workloads run. Each workload has an external firewall that works as an allowlist for inbound and outbound internet traffic, and an internal firewall that controls which other workloads can reach it (none, the same GVC, the same org, or a named list of workloads). By default, a new workload accepts no inbound or outbound internet traffic and no traffic from other workloads until you allow it. Traffic between workloads is encrypted with mTLS, using a unique client certificate per workload that Control Plane rotates every hour.

Secrets are stored in Control Plane and referenced by workloads at runtime. A workload can read a secret only if its identity has been granted the reveal permission on that secret through a policy. Secret values stay out of code and images. A vibe-coded app that hardcoded a database URL can read it from the platform at startup instead, after the old value is rotated.

Universal Cloud Identity, Control Plane’s workload identity for cloud services, connects a workload to AWS, GCP, or Azure services through an IAM role or service-account grant instead of long-lived keys in your code, with short-lived, least-privilege credentials at runtime. If your AI coding tool pasted an AWS access key into the source, Universal Cloud Identity replaces it; deactivate the old key in AWS IAM too, because it stays in git history. The permissions are still whatever the attached role allows, so review the role’s policy.

Each workload is isolated with cgroups, namespaces, and restricted syscalls and capabilities, and Sandboxes run in dedicated Kata Containers microVMs. Workload isolation separates services; it does not replace tenant checks inside one app, which multi-tenant isolation for SaaS and AI covers layer by layer.

Control Plane keeps a tamper-proof audit trail of every action taken through its API, whether from the console, CLI, Terraform, Pulumi, the Kubernetes operator, or Control Plane’s MCP server, recording who changed what across the org. If a vibe-coded app is deployed and later found to be misconfigured, the audit trail shows who deployed it and what changed, and you can roll back a bad change with a record of the rollback itself.

What extra risks do AI features add?

A vibe-coded app with AI features, such as a chatbot, a summarization endpoint, or an agent that takes actions for users, inherits a second set of risks beyond standard web vulnerabilities.

Prompt injection. An attacker crafts input, directly or hidden in content the model reads such as web pages, files, or emails, that overrides the system prompt, causing the LLM to reveal internal instructions, take unintended actions, or return data it should not. It is the first entry (LLM01) in the OWASP Top 10 for LLM Applications, and OWASP notes that it is unclear whether fool-proof prevention methods exist, so limit what the model can access and require approval for high-risk actions.

Data leakage through prompts and logs. User data or internal context sent to an external AI provider may be logged and retained by that provider. The OpenAI and Anthropic APIs do not train on API data by default, but unpaid tiers such as the free Gemini API quota let the provider use submitted content to improve its products. Prompts that contain personal, financial, or proprietary data can breach data protection requirements.

Exposed AI provider keys. Vibe-coded apps can end up with the AI provider’s API key hardcoded in the frontend or in a public repository. Anyone who finds the key can run up charges or use the provider’s API under your account.

Unbounded spend. Without per-user or per-request token limits, one user or attacker can trigger thousands of expensive LLM calls.

Before launch, put these controls in place for every AI feature.

• Make all LLM API calls from the server, and never expose the provider key to the client.
• Inject the provider key through the platform’s secret management.
• Give the model only the tools and data the current user is already allowed to access, and enforce that check in server code, outside the prompt.
• Require user confirmation before any model-triggered action that writes, deletes, sends, or pays.
• Set per-user and per-request token budgets and enforce them server-side.
• Treat LLM output as untrusted input, and sanitize and validate it before rendering.
• Keep secrets, internal URLs, and sensitive data out of prompts.
• Log prompts and responses for audit, and redact sensitive fields before writing to the log sink.

Where does Control Plane fit?

Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, Azure, and Oracle Cloud Infrastructure (OCI), VM workloads on locations joined through Control Plane’s Managed Kubernetes, and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds.

Control Plane handles Day 2 operations for you, including autoscaling, built-in observability, and security. For vibe-coded apps, that covers the platform rows of the risk table, and log collection and metrics are in place even when the builder never set them up. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Teams without a platform group get production-grade infrastructure without a platform team.

Control Plane’s Template Catalog adds optional security tools you deploy next to the app, including a Coraza web application firewall with the OWASP Core Rule Set and Trivy for scheduled vulnerability scanning of images in your Control Plane registry.

Control Plane’s MCP server lets an AI coding assistant deploy and inspect workloads with the signed-in user’s permissions, and instructs the assistant to explain the impact and get approval before destructive actions. Sign the assistant in with an account whose policy grants only what it needs, or connect it with the read-only toolset when it only needs to investigate.

Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. That covers the platform; the app’s own code and controls still need their own review. For teams enforcing policy as code across multi-cloud infrastructure or enabling developer self-service with guardrails, Control Plane enforces its access policies on every API request and its firewall rules on workload traffic.

FAQ

Answers for founders and engineering leads shipping AI-built apps.

What are the security concerns with deploying vibe-coded applications to production?

The main concerns are unreviewed code flaws, insecure defaults, hallucinated or vulnerable dependencies, hardcoded secrets, over-permissive infrastructure, missing audit trails, and AI-feature risks such as prompt injection and unbounded spend. Review and scanning fix the code; a platform with secure defaults closes the infrastructure gaps.

Is vibe-coded code safe for production?

Not automatically. Vibe-coded code can be made safe for production if it passes the same checks you would apply to any application: human review of authorization and data-access logic, a two-account authorization test, SAST, SCA, secret scanning, DAST, and deployment to a platform that enforces private networking, secret management, and least-privilege identity.

What is slopsquatting?

Slopsquatting is a supply-chain attack that exploits hallucinated package names. An attacker tracks names of nonexistent packages that AI tools suggest, then publishes a malicious package under that name on a public registry. When a developer installs the hallucinated dependency, the malicious code runs in their environment. The defense is a human check on every new dependency before you install it: confirm the maintainer, publish date, download history, and source repository. Malicious-package detection in CI adds a second check, but a lockfile and SCA do not catch a package that was malicious from its first version.

How do I keep API keys out of a vibe-coded app?

Rotate each exposed key first, because deleting it from code leaves it in git history and old builds, then replace it with a reference to a secret your deployment platform manages. In Control Plane, secrets are stored centrally and read by workloads at runtime through policy-controlled identity grants. Keys the browser would need stay on the server, behind your own API.

Can a hosting platform fix insecure code?

No. A platform cannot fix injection, cross-site scripting, broken authorization, or vulnerable dependencies inside your application. Those flaws live in the code and need review, scanning, and testing. A platform can close infrastructure risks: public network exposure, missing encryption in transit, long-lived cloud credentials, lack of workload isolation, and absent audit trails. A good platform enforces those controls, with deny-by-default networking, so the builder does not build them from scratch.

How do I make a vibe-coded app pass a security review for a business customer?

Run the pre-production checklist, including SAST, SCA, secret scanning, DAST, and a human review of authentication, authorization, and payment code. Deploy to a platform with documented security controls, encrypted traffic, workload isolation, and an audit trail. Document your dependency management, secret handling, backups, and incident response plan. If the customer requires a penetration test, run one against staging and fix the findings before the production review.

Do I need a SOC 2 report to sell a vibe-coded app?

It depends on your customer. Enterprise buyers, especially in finance and healthcare, often ask for a SOC 2 Type II report as a condition of purchase. Your application code and business processes need their own controls and audit, but deploying on a platform with its own SOC 2 Type II report lets you present it as a subservice organization in your report, usually through the carve-out method, which excludes the infrastructure controls it operates from your audit scope. You still monitor the platform through its report and implement the complementary user entity controls it lists.

How does Control Plane secure vibe-coded apps?

Control Plane secures the infrastructure layer: allowlist firewalls with private networking by default, runtime secrets with policy-based access, Universal Cloud Identity, workload isolation, mTLS, and a tamper-proof audit trail. Pair it with the review and scanning steps in the checklist, which cover the code-level risks a platform cannot reach.

What is Universal Cloud Identity?

Universal Cloud Identity is Control Plane’s workload identity for cloud services. A workload gets short-lived credentials for AWS, GCP, or Azure through an IAM role or service-account grant, so an app generated with a pasted cloud key can drop the key entirely.

To close the infrastructure risks around your vibe-coded apps, talk to the Control Plane team or sign up free.

Originally published on the Control Plane blog.