Vibe Coding Guardrails · How to Let AI Write Code Without Getting Burned
Quick answer: Vibe coding guardrails are fixed rules you set before AI writes any code: never hardcode API keys, enable Row-Level Security on every table, validate all input server-side, and keep secrets in environment variables. Enforce them with project-level instructions, security prompts after each feature, and an automated scan before every deploy.
By Paula C · Kraftwire Software
· 8 min readWhat Are Vibe Coding Guardrails?
Vibe coding guardrails are fixed rules you give your AI builder before it writes any code, plus the checks you run after it does. Instead of hoping Lovable, Bolt.new, Cursor, or v0 produce secure output on their own, you make the non-negotiables explicit: secrets never appear in frontend code, every database table gets Row-Level Security, every input is validated on the server.
Guardrails matter because AI builders optimize for "works in the demo," not "survives contact with an attacker." The most common vulnerabilities in AI-generated apps · exposed API keys, missing RLS policies, authorization that only exists in the React frontend · are boring, repetitive, and almost entirely preventable with rules the AI can follow. Is Vibe Coding Safe? covers the risk landscape in detail; this guide is the practical answer to it.
Effective guardrails come in three layers:
- Project-level rules the AI reads before every request
- Security prompts you paste while building
- A post-session cheat sheet plus an automated scan before deploy
None of the three requires you to read code. All three are below, copy-paste ready.
Which Guardrails Should You Set Before Prompting?
Every serious AI builder has a place for standing instructions: project knowledge in Lovable, rules files in Cursor and Windsurf, a CLAUDE.md file for Claude Code, custom instructions in ChatGPT. Whatever the mechanism, the AI reads these rules on every request, which makes them the highest-leverage five minutes of your build.
Paste this into your project's instructions:
Three of these rules do most of the work:
Never hardcode keys. AI builders take the fastest path to a working integration, and the fastest path is calling the API straight from the browser with the key inline. That key is now public. Why Exposed API Keys in Frontend Code Are Dangerous explains what attackers do with them, and why a key in a "private" file still ends up in your JavaScript bundle.
Always RLS. If your app uses Supabase (the default backend for Lovable and common everywhere else), your project URL and anon key are public by design. Row-Level Security is the only thing standing between that public key and your data. RLS Policies Explained walks through writing policies from scratch.
Always validate server-side. Generated forms usually get client-side validation and nothing else. An attacker never uses your form · they call your API directly with whatever payload they want.
What Security Prompts Should You Give Your AI Builder?
Standing rules prevent most problems; targeted prompts catch the rest. AI models drift over long sessions · rules that held for the first ten features can get skipped on the eleventh. These vibe coding security prompts force a re-check. Paste them verbatim:
Two things make these prompts work. First, they ask the AI to show evidence (list the policies, list the matches) rather than answer "is it secure?" · a question models tend to answer optimistically. Second, they are scoped to what just changed, so the model actually reviews it instead of summarizing.
The same approach applies to coding agents. The Claude Code Security Checklist covers prompts and review habits for agent-written code, and Is ChatGPT-Generated Code Safe? covers what to check when you paste code out of a chat window.
What Should You Check After Every AI Coding Session?
This is the vibe coding security cheat sheet. Run it at the end of every session that touched data, auth, or an integration · it takes about five minutes:
- Secrets · search the codebase for
sk-, key, token, password; nothing secret in frontend files or VITE_/NEXT_PUBLIC_ variables
- RLS · every new or modified table shows
rowsecurity = true; policies scope to auth.uid(), no catch-all USING (true)
- Direct API test · open DevTools, copy a request, replay it with another user's ID; you should get an error, not data
- Validation · every new endpoint rejects oversized, malformed, or missing input server-side
- Auth placement · admin and role checks run on the server, not in React components
- Headers · Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Strict-Transport-Security present on responses
- Errors · no stack traces or SQL in anything a user can see
- Dependencies ·
npm audit shows no new critical vulnerabilities
- Git history · no secrets committed, even in deleted files
The full pre-launch version of this list, with step-by-step instructions for each item, lives at the vibe coding security checklist. The session cheat sheet above is deliberately shorter: the point is to run it every single time, not to be exhaustive once.
Which Tools Enforce Guardrails Automatically?
Manual checks fail the same way prompts do: you skip them when you are tired or excited to ship. Automation does not get tired. The main tool categories, roughly in the order worth adopting:
- Secret scanners · open-source tools like gitleaks and TruffleHog focus on finding keys and tokens in your code and git history; run them before every commit
- Dependency auditing ·
npm audit is built into npm and flags known vulnerabilities in your packages
- Platform built-ins · Lovable, Replit, and other builders have added their own security reviews; useful, but they check what the platform sees, not the deployed app
- Single-purpose checkers · free tools that verify one control at a time, like a security headers checker
- Deployed-app scanners · tools that test the live app the way an attacker sees it, catching exposure that only appears after the build step
SimplyScan sits in the last category and was built specifically for vibe-coded apps: it runs 51+ automated checks across 14 categories · exposed keys, missing or weak Supabase RLS, broken auth, XSS, security headers, AI-specific risks · in about 30 seconds, free and with no signup. For a comparison of what each class of scanner catches and misses, see Best Vulnerability Scanners for Vibe-Coded Apps, and browse the 60 free tools for single-purpose checks.
How Do You Know If Your Vibe-Coded App Is Secure?
You never know with absolute certainty · but you can know that the failure modes behind most real-world vibe coding incidents are closed. A practical security assessment for an AI-built app has three parts:
- Guardrails in place · project rules set, security prompts used during the build
- Cheat sheet passed · the post-session list above comes back clean, including the direct API test with another user's ID
- Clean external scan · an automated scan of the deployed app finds no critical or high-severity issues
Then keep it that way. Security is a state, not an event: every new feature is new attack surface, so re-run the cheat sheet after significant sessions and re-scan before every deploy. Run a free security check to see where your app stands right now · results arrive in about 30 seconds, and the free scan includes 2 rescans so you can confirm your fixes actually landed.
Related Guides
Frequently asked questions
Is vibe coded software secure?
It can be, but not by default. AI builders reliably produce working features while skipping controls like Row-Level Security, server-side validation, and secret handling, because insecure code often looks identical to secure code in a demo. Vibe-coded software that ships behind guardrails, passes a post-session checklist, and comes back clean from an automated scan is in materially better shape than most hand-built hobby projects.
What are vibe coding security best practices?
Set standing rules before prompting: no hardcoded secrets, RLS on every table, server-side validation and authorization. While building, paste targeted security prompts after features that touch data, auth, or integrations. After each session, run a short cheat sheet covering secrets, RLS, direct API tests, and headers. Before every deploy, scan the live app with an automated scanner and fix critical findings first.
What are the best vibe coding security tools?
Use one tool per layer rather than one tool for everything. Secret scanners like gitleaks catch keys in code and git history, npm audit flags vulnerable dependencies, and single-purpose checkers verify individual controls like security headers. For the deployed app, use a scanner built for AI-generated apps: SimplyScan runs 51+ checks across 14 categories, including exposed keys and Supabase RLS, in about 30 seconds for free.
How often should you run a vibe coding security check?
After every AI coding session that touched data storage, authentication, or a third-party integration, run the five-minute cheat sheet. Before every production deploy, run a full automated scan of the live app. Rescan after fixing findings to confirm the fixes landed, since AI builders sometimes reintroduce old patterns when regenerating code. A calendar-based schedule alone misses the real trigger, which is change.
Can you make AI builders follow security rules with prompts alone?
Mostly, but not reliably enough to skip verification. Project-level rules raise the baseline substantially, and models follow them well early in a session. Over long sessions instructions drift, and regenerated code can silently drop a policy or reintroduce a hardcoded key. That is why guardrails come in three layers: standing rules, mid-build security prompts that demand evidence, and an automated scan of the deployed result.
What does a vibe coding security assessment include?
Three parts. First, verify guardrails exist: project rules, secrets in environment variables, RLS policies on every table. Second, manual spot checks: replay API requests with another user's ID, submit malformed input, inspect responses for leaked details. Third, an automated scan of the deployed app covering exposed keys, auth, XSS, headers, and platform-specific risks. Critical findings get fixed and re-verified before launch.