Imagine describing a complex app in plain English, hitting a button, and having a fully functional piece of software appear in seconds. That is the magic of vibe coding. But there is a dark side to this speed: AI doesn't understand your company's security policies. It doesn't know the difference between a public product description and a customer's social security number. Without strict data classification rules, vibe coding can accidentally turn a prototype into a massive data leak.
The core problem is that AI tools prioritize functionality over security. They often generate "permissive" code-meaning they open as many doors as possible to make sure the app "just works." For a developer, this is convenient; for a security officer, it is a nightmare. To bridge this gap, organizations need a governance framework that tells the AI (and the humans reviewing the code) exactly how to handle different types of data.
The Four-Tier Risk Framework
You cannot treat every piece of code the same. A bug in a UI color scheme is a nuisance; a bug in a payment gateway is a catastrophe. The Vibe Coding Framework is a structured governance system that categorizes AI-generated components based on their sensitivity and risk . It breaks everything down into four levels:
- Critical: This is the "red zone." It includes anything touching Personally Identifiable Information (PII), financial records, or authentication logic. These require a security specialist's sign-off and Level 3 verification.
- High: Components that handle data processing or integrate with external APIs. These need automated security scans and a peer review before they go live.
- Medium: Standard features that don't handle sensitive data but still need basic Level 2 verification and scanning.
- Low: Internal tools or non-critical prototypes. These only need basic monitoring and Level 1 verification.
The PII Detection Trap
Detecting sensitive data in AI-generated code isn't as simple as searching for a keyword. Many teams rely on regex (regular expressions) to find patterns like credit card numbers. While this is a good start, it often fails because of how AI structures data. For example, if an AI generates a complex object to hold user data, a simple regex might miss it if the data is split across multiple variables.
A major risk occurs during the "tagging" process. Some tools use auto-tagging to identify sensitive data and then apply "exclusion logic" to ignore certain files. If a tool applies exclusions after tagging, it might accidentally leak sensitive data that should have been filtered out. The rule is simple: always exclude and filter data before the tagging process begins to ensure nothing sensitive slips through the cracks.
Hardening the "Vibe": From Dev to Production
Vibe coding tools love defaults, and those defaults are usually insecure. One of the most common failures is hardcoding secrets. An AI might generate a database connection string with the username and password written directly in the code just to get the app running. This is a critical classification failure.
| Feature | Typical AI Default (Unsafe) | Governance Requirement (Safe) |
|---|---|---|
| Credentials | Hardcoded strings in source code | Stored in Environment Variables |
| CORS Policy | Wildcard (*) allowing all domains | Strict allow-list of trusted domains |
| Database Access | Permissive admin-level access | Row-Level Security (RLS) policies |
| API Keys | Embedded in frontend JavaScript | Handled via secure backend proxy |
Take CORS (Cross-Origin Resource Sharing) as an example. AI tools frequently use the asterisk (*) wildcard, which essentially tells the internet, "Anyone can request data from this API." In a production environment, this is an open invitation for attackers. You must manually reclassify these outputs and restrict access to specific, trusted domains.
The Database Danger Zone: RLS and Supabase
Many vibe-coded apps rely on Supabase for their backend. Because it is designed for rapid development, the default security rules are often way too loose. A common pattern found in vulnerability research is the exposure of "service role keys." These keys have administrative privileges-they can bypass almost every security check in the database.
If your AI generates code that puts a service role key in the frontend, you have a critical security breach. To fix this, you must implement Row-Level Security (RLS). RLS ensures that a user can only see their own data, even if they manage to call the API directly. Without explicit RLS policies, you aren't actually classifying your data; you're just hoping no one finds the URL to your database.
Building a Governance Pipeline
Since current AI tools can't natively enforce your company's security policies, you have to build the guardrails around them. This means moving security "left" into the prompts and "right" into the verification process.
- Prompt Engineering: Don't just ask for a feature. Include classification requirements in the prompt. For example: "Create a user profile page, but ensure all database calls use parameterized queries and no secrets are hardcoded."
- Verification Checklists: Every piece of vibe-coded output should pass a checklist based on its risk tier. For a 'Critical' component, this includes a manual code review by a security lead.
- Downstream Scanning: Use external tools to scan for exposed secrets and open ports. Don't trust the AI to tell you if it left a back door open.
- Replay Testing: Test your authentication by trying to access protected data without a token or with a modified header. If the data still shows up, your classification logic is broken.
The research by Escape Technologies highlighted this need after finding thousands of vulnerabilities in apps built on platforms like Lovable and Bolt.new. The common thread? A total lack of data classification rules during the generation phase.
What exactly is "vibe coding" in a professional context?
Vibe coding is a high-level approach to software development where the user provides natural language descriptions (the "vibe") and an AI generates the implementation. In a professional setting, it requires a governance layer to ensure the generated code meets enterprise security and compliance standards.
Why can't I just trust the AI to handle data security?
AI models are trained to be helpful and functional. Often, the "easiest" way for an AI to make code work is to use overly permissive settings, like wildcard CORS policies or hardcoded API keys. They lack the organizational context to know which data is sensitive and which is public.
What is the most dangerous classification failure in vibe coding?
Exposing administrative keys, such as Supabase service role keys, in the frontend code. This gives any user with a browser full access to the database, bypassing all security rules and potentially exposing all user data.
How does Row-Level Security (RLS) help with data classification?
RLS acts as a final safety net. Even if the AI generates a flawed API endpoint, RLS happens at the database level, ensuring that the database itself refuses to serve data unless the requesting user owns that specific row of information.
How often should data classification rules be updated?
Continuously. AI tools evolve rapidly, and new vulnerabilities emerge as platforms change their default configurations. A static checklist from six months ago is likely obsolete in the world of vibe coding.
