Vibe Coding Security Guide: Risks and Guardrails for AI-Built Software

Vibe coding lets people ship working software they have not read, so security flaws, hard-coded secrets and open databases reach production without anyone deciding to accept them. The practice ranges from developers accepting large AI-generated diffs in an IDE to non-developers describing an app in a hosted builder and publishing it to the internet within an hour. The failure modes are now well documented: credentials in client code, backends with no access rules, dependencies that do not exist until an attacker registers them, and coding agents holding tokens that can delete production. This guide sets out the risks, the guardrails that work for each type of builder, how to roll them out, and how to measure them. It is for application security and platform teams who must allow AI-assisted building without losing control of what ships.

Key takeaways

• Treat AI-written code as untrusted third-party code. Studies from 2021 to 2025 consistently find that a large share of generated code contains known weakness classes, so it needs the same scanning and review as any external contribution.
• The worst incidents are configuration, not syntax. Exposed databases without row-level security and secrets shipped in client JavaScript have caused larger exposures than subtle code bugs.
• Hallucinated packages are a supply chain attack surface. Models repeatedly suggest package names that do not exist, and attackers can register them; dependency allow-lists and registry proxies close the gap.
• Coding agents are non-human identities. Give them short-lived, narrowly scoped tokens, separate development from production, and never hand an agent credentials that can destroy data it cannot restore.
• Guardrails differ by builder. Developers in AI IDEs need pipeline controls they cannot skip; non-developers using app builders need platform defaults, pre-publish checks and a route to security review before real data goes in.

What vibe coding means and why the risk is different

Collins Dictionary named "vibe coding" its Word of the Year 2025, describing it as using AI prompted by natural language to write computer code, and credits the term to Andrej Karpathy, who used it in a February 2025 post. Across the spectrum the security problem is the same: the person accepting the code does not review it line by line, and often could not.

• Volume outruns review: an assistant produces hundreds of lines per prompt, and teams start approving diffs they have only skimmed.
• Configuration is generated too: database policies, cloud permissions, CORS, environment files and CI workflows come from the same prompt and are rarely checked against a baseline.
• New builders, no pipeline: people outside engineering now publish internet-facing apps from hosted builders. These apps bypass repositories, scanners and change control: shadow IT with a public URL. See the Shadow AI Discovery Guide.
• Agents act, not just suggest: coding agents run commands, install packages, call cloud APIs and push commits with whatever credentials the session holds. Their risk is an identity and authorisation problem as much as a code quality one. See the AI Coding Agents Security Guide.

The risk map: what goes wrong and what stops it

Insecure code and leaked secrets

The evidence is consistent, though each figure should be read with its method in mind.

• Academic baseline: Pearce and colleagues tested an early GitHub Copilot on 89 security-relevant scenarios, producing 1,689 programs, and found roughly 40% vulnerable. An early-model result, but it set the pattern.
• Vendor study, 2025: Veracode's 2025 GenAI Code Security Report, which tested more than 100 models on 80 tasks tied to CWE classes, reports that the models introduced a vulnerability in 45% of cases. By Veracode's figures, Java failed more than 70% of the time, cross-site scripting (CWE-80) went undefended in 86% of relevant tasks and log injection (CWE-117) in 88%. These are the vendor's figures from its own static analysis.
• Secrets at scale: GitGuardian reports 23.8 million secrets leaked on public GitHub in 2024, up 25% on the previous year. A prompt such as "connect to my database" often yields a working example with the key inline, and the builder ships it.

Controls that work

• Secret scanning in three places: a pre-commit hook on developer machines, push protection on the source host so a commit containing a recognised secret is rejected, and scanning of built front-end bundles, where server keys most often leak. See the Secrets Management Guide.
• Know which keys may be public: some backend platforms issue a client key designed to sit in the browser. It is only safe when every table and function behind it enforces authorisation. Treat any service-role or admin key in client code as a confirmed leak and rotate it.
• Blocking SAST rules, not dashboards: a short list of classes (injection, cross-site scripting, path traversal, deserialisation, hard-coded credentials) fails the build; long advisory reports are ignored at vibe-coding speed.
• Prompt the right defaults: project instruction files for AI IDEs (rules files, agent instructions) should state the organisation's requirements: parameterised queries, secrets from environment or vault only, approved auth library. This helps but never replaces scanning. See the Secure Coding Guide.

Missing authorisation and exposed backends in AI app builders

Hosted app builders typically generate a front end that talks directly to a backend-as-a-service database with a public client key, so security depends entirely on database-level authorisation, which the builder may omit or set too loosely.

• The platform pattern: Supabase's documentation tells users to enable row-level security (RLS) on every table in an exposed schema, and warns that a table in an exposed schema without RLS can be read and written by any role granted access to it. A policy that grants the anonymous role access with a condition that is always true gives every visitor read access.
• A recorded vulnerability: CVE-2025-48757 describes an insufficient RLS policy in Lovable through 15 April 2025 that let remote unauthenticated attackers read or write arbitrary database tables of generated sites. The CERT.hr record lists a CVSS 3.1 base score of 9.3.
• Builder-side checks help but are not assurance: Lovable's documentation describes a quick scan on publish (database access rules, npm dependencies, MCP servers exposed without authentication) and a deeper scan covering access control, unauthenticated endpoints and leaked secrets, and states that these tools cannot guarantee complete security, recommending professional review for sensitive data.

Minimum backend baseline for builder apps

1. RLS (or the platform's equivalent) enabled on every table before any real data is loaded, with deny as the default.
2. Policies keyed to the authenticated user's identifier, never to a client-supplied field.
3. No service-role, admin or third-party API key in the front end; server-side functions hold those.
4. An automated test that calls every table and function with the anonymous key and with a second test user, and fails if either reads another user's rows.
5. Storage buckets private by default; public buckets listed and justified.

Package hallucination and slopsquatting

Models sometimes recommend dependencies that do not exist; if an attacker registers the name, the next developer or agent to follow the suggestion installs it.

• Scale: Spracklen and colleagues (USENIX Security 2025) generated 576,000 code samples from 16 models and found average hallucination rates of at least 5.2% for commercial models and 21.7% for open-source models, with 205,474 unique hallucinated package names.
• Repeatability is what makes it exploitable: as reported by The Register, 43% of hallucinated names reappeared in every one of ten repeated queries, so an attacker can predict which names to register.
• The name: "slopsquatting" is credited by The Register and CSO Online to Seth Michael Larson, security developer-in-residence at the Python Software Foundation, as a variant of typosquatting.
• Framework view: the OWASP Top 10 for LLM Applications 2025 entry LLM09:2025 Misinformation describes attackers finding commonly hallucinated package names and publishing malicious packages under them. MITRE ATLAS models the same steps as AML.T0062 Discover LLM Hallucinations and AML.T0060 Publish Hallucinated Entities, with case study AML.CS0022 ChatGPT Package Hallucination.

Controls

• Resolve through an internal registry proxy and block direct installs from public registries on build systems and agent sandboxes.
• Allow-list or quarantine: new dependency names require approval; packages published very recently, with few downloads or no source repository go to quarantine for review.
• Pin and verify: commit lockfiles, install with npm ci or pip install --require-hashes, and disable install scripts where the ecosystem allows (for example ignore-scripts in npm configuration).
• Treat "package not found" from an agent as a signal, not a prompt to try a similar name. See the Malicious Package and Dependency Confusion Guide.

Coding agents and the tokens they hold

When an assistant becomes an agent that runs commands, the question changes from "is this code safe" to "what can this identity do". OWASP LLM06:2025 Excessive Agency names the root causes as excessive functionality, excessive permissions and excessive autonomy, and each maps to a control.

Where identity fits

• Give each agent its own identity: a token issued to "agent on repository X" can be scoped, monitored and revoked; a developer's personal token shared with an agent is indistinguishable from the developer. See the API Key Management Guide.
• Prefer federation over stored keys: with workload identity federation the agent gets a token that expires in minutes, not a long-lived key it can print, log or leak.
• Sandbox the session: run agents in containers or remote development environments with no access to the host's credential stores, SSH agent or cloud configuration files (ATT&CK T1552.001 Credentials In Files is exactly what malicious tooling hunts for).
• Separate environments: an agent that can only reach a development database cannot delete production, whatever it is told.

Guardrails by builder type

One policy for everyone either blocks non-developers or underprotects developers' pipelines. Decide by who builds and where the output runs.

• Small organisations: start with controls that need no team: platform defaults (RLS on, push protection on), one approved builder, and real customer data only in apps a technical owner has reviewed.
• Large organisations: put guardrails in shared infrastructure (registry proxy, central secret scanning, agent sandboxes, policy-as-code in CI) so teams inherit them, and add builder apps to attack surface monitoring.

Rolling out guardrails

1. Discover: list AI coding tools (IDE extensions, CLIs, agents) and builder-hosted apps from DNS, proxy and expense data, with owner, data and exposure.
2. Turn on platform defaults first: push-protected secret scanning, RLS by default, private storage by default. They cost little and stop the largest exposures.
3. Add pipeline checks in report-only mode: run SAST, SCA and the dependency allow-list for two to four weeks, tune false positives and publish the baseline.
4. Switch to blocking for a pilot ring of one or two AI-heavy teams. Track failures and overrides; keep a logged break-glass override that needs a security approver.
5. Issue agent identities: replace personal tokens in agent sessions with scoped, expiring credentials, and move agents into sandboxes. Remove production credentials from development environments.
6. Extend to all teams and builder apps, requiring inventory registration and the backend baseline before real data. Roll back by returning a control to report-only mode, not disabling it, so evidence keeps flowing.
7. Review quarterly: re-run anonymous-key tests, re-check agent token scopes, update instruction files and allow-lists.

The rollout aligns with NIST SP 800-218 (SSDF v1.1): PO.3 (supporting toolchains), PO.4 (criteria for security checks), PS.1 (protect code from unauthorised access), PW.4 (reuse well-secured software and verify third-party components), PW.7 (review code), PW.8 (test executable code), PW.9 (secure defaults) and RV.1 (identify vulnerabilities). NIST SP 800-218A is a community profile for developing AI models, not for using AI to write code, so do not cite it as the standard for vibe coding. For the full lifecycle, see the Secure Software Development Lifecycle (SSDLC) Guide.

Detection and measurement

What to monitor:

• Secret scanning alerts and push-protection bypasses, with time to rotation.
• Registry proxy blocks for names that do not exist upstream or were published days ago: a cluster of identical blocked names across teams suggests a commonly hallucinated package.
• Database and API logs for anonymous-role access to tables that should be per-user, and for bulk reads from a single client.
• Agent identity activity: commands, installs, cloud API calls and token use outside the expected repository or environment.
• New internet-facing hosts on builder or custom domains missing from the inventory.

Framework mapping

Common failure patterns

• Trusting the builder's scan as a security review. Platform scanners do not know which rows each user should see; run your own anonymous and cross-user tests.
• Shipping a client key with no row-level security behind it. The Moltbook Database Exposure 2026 followed this pattern: Wiz found a Supabase key in client-side JavaScript and no RLS, giving unauthenticated read and write access to a production database holding about 1.5 million agent API tokens. Wiz described it as what happens when apps are vibe-coded without proper security controls.
• Letting an agent hold production credentials. In the Replit AI Agent Database Deletion 2025, a coding agent deleted a production database during a declared code freeze; Replit's response, as reported by The Register, included separating development and production databases, a planning-only mode and one-click restore. The PocketOS Database Deletion 2026 repeated the lesson with an over-privileged platform token.
• Over-scoped tokens in the AI tooling supply chain. The Amazon Q Developer Extension Compromise 2025 is the reverse case: an over-scoped GitHub token was the route by which a wiper prompt was shipped to an AI coding agent's users, so the tokens around AI tooling need the same scoping as the tokens the agents hold.
• Developer machines as credential stores. In the Nx s1ngularity Attack 2025, malicious package code abused locally installed AI CLIs while hunting for credentials, a reason to keep agents and their tools in sandboxes without access to host secrets.

Practitioner checklist

• Inventory AI coding tools, agents and builder-hosted apps, each with a named owner and data classification.
• Enable secret scanning with push protection on every repository and scan built front-end bundles.
• Require RLS or equivalent default-deny policies, plus automated anonymous and cross-user tests, before any builder app receives real data.
• Route all package installs through a registry proxy with allow-listing and quarantine for new or unknown names.
• Make SAST and SCA blocking for a short list of high-severity classes, with a logged break-glass override.
• Require an independent human reviewer for AI-generated changes to authentication, authorisation, CI workflows and IaC.
• Issue each coding agent its own scoped, short-lived identity; remove personal and production credentials from agent sessions.
• Run agents in sandboxes with command allow-lists and approval gates for destructive operations.
• Publish organisation rules files for AI IDEs covering secrets handling, query construction and approved libraries.

Standards and references

• NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
• OWASP: Top 10 for LLM Applications 2025
• OWASP: Top 10:2025
• OWASP: Application Security Verification Standard 5.0
• MITRE: CWE-798 Use of Hard-coded Credentials
• CISA: CISA, NSA, FBI and International Partners Release Updated Secure by Design Guidance
• Supabase: Row Level Security
• arXiv: We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · Secure Coding Guide · CWE Top 25 Guide · Malicious Package and Dependency Confusion Guide · Software Supply Chain Security Guide