Security and Privacy in Vibe Coding: A Pre-Production Guide

An application built with Vibe Coding can look excellent while exposing personal data through an unprotected database table, an unauthenticated endpoint, or an environment file included in an AI tool’s context. The risk extends beyond code: it also depends on what information the system collects, who can access it, and what gets sent to AI providers during development.

This guide walks through the security and privacy layers that matter before you take a product built with Cursor, Lovable, Bolt, Replit, Claude Code, or a similar tool into production.

This article offers general engineering principles and is not a substitute for legal advice or a compliance review tailored to your organisation.

Privacy starts with a data map, not a consent screen

Before you run a security scanner, you need to know what information exists in the system. Build a short list for every sensitive field or document:

Question	Example answer
What is collected?	Name, phone number, IP address, conversation content
Why is it needed?	Account creation, support, or service delivery
Where is it stored?	Database, logs, mailing system
Who can see it?	The user, the support team, a system administrator
Who is it sent to?	Storage provider, AI provider, analytics tool
When is it deleted?	After account closure or a defined retention period

If there’s no answer to “why do we need this data?”, the right default is not to collect it. Data minimisation also reduces the potential damage if something goes wrong.

Israel’s Protection of Privacy (Data Security) Regulations apply to databases that meet the law’s definition, including databases containing information collected from public sources. “The data is already on the internet” therefore does not automatically remove your responsibility.

The quiet risk: what the AI tool sees during development

A coding assistant doesn’t necessarily see only the line you’re working on. Depending on the tool and its settings, it may receive open files, project structure, terminal output, or additional snippets from the repository.

OWASP’s Secure Coding with AI Cheat Sheet recommends checking what context is sent to the provider, excluding sensitive files, and never assuming that .gitignore prevents AI tools from reading them.

Before you start work:

• exclude .env, private keys, credential files, and customer data exports from the AI tool’s context;
• don’t paste tokens, passwords, or personal data into a prompt;
• review the provider’s data retention and training settings;
• use synthetic test data instead of production data;
• define which repositories may be opened in cloud tools and which require an isolated development environment.

Six security checks you have to pass

1. Secrets never reach the browser

Values embedded in frontend code are accessible to anyone who receives it. A Supabase service_role key, a webhook secret, or another privileged secret key must stay on the server or in a secrets manager. Public client keys are different: they must be backed by correctly enforced permissions.

If a sensitive key has already appeared in a commit, in a deployed file, or in an AI conversation — don’t stop at deleting it. Rotate it, reduce its permissions, and check the logs to see whether it was used.

2. Permissions are enforced server-side

Hiding an “Admin” button is not an authorisation mechanism. Enforce access rules for every protected API operation and data query. In Supabase, enable Row Level Security on tables exposed through the Data API and define policies for the allowed operations. Server credentials that bypass these policies require their own access checks.

Test each action in three states: signed out, as a regular user, and as a user with an elevated role. Also try reaching another user’s record by changing an identifier in the request.

3. Untrusted input stays untrusted

Validate type, length, and range on the server, use parameterised queries, encode output according to context, and restrict file uploads. Asking the model to “sanitise the input” is not a substitute for explicit rules and tests.

4. Logs help without becoming another sensitive store

A good log records the time, the action, a request identifier, and the outcome. It shouldn’t contain passwords, tokens, card numbers, or full personal content.

Define which fields to redact, who can view logs, and when logs are deleted. Review third-party providers’ logs too, not just the ones in your own code.

5. Dependencies and the supply chain are scanned

AI tools may suggest an unfamiliar package to solve a problem quickly. Before adding a dependency, check its source, maintenance, licence, and the permissions it requires. In CI, add dependency and secret scanning and block critical findings.

6. Critical code gets a human owner

OWASP recommends not letting the same agent both write a security component and provide the only evidence that it is sound. Authentication, authorisation, encryption, and personal-data handling require human review and independent testing.

Privacy as part of the process

Security protects information from unauthorised access. Privacy also defines what you may collect and what you may do with it. It’s therefore worth turning sensitive actions into a process you can observe and audit:

1. The user’s request is received and recorded.
2. The requester’s identity and authorisation are verified.
3. Only the data required for the action is collected.
4. An exceptional action goes through human approval.
5. The outcome and the retention period are documented.
6. Deletion or correction is carried out across every relevant system.

This is where it connects to the Process-First approach: AI can classify, summarise, or propose an action, but the authorisation, the control point, and the record of the decision stay inside a governed process.

A short pre-production checklist

• A data map exists, with a business reason for every piece of personal data collected.
• No production data, secrets, or keys are in the AI tool’s context.
• Every permission is enforced on the server and in the data layer.
• Exposed keys were rotated, not just removed from the code.
• Logs contain no unnecessary sensitive content.
• Secret, dependency, and code scanning run in the CI pipeline.
• Cross-user access scenarios were tested manually and automatically.
• There is a human owner for the code and an incident response process.
• A retention and deletion policy exists that can actually be carried out.

Summary

Security and privacy are not a finishing layer you add once the Vibe Coding is done. They are part of the architecture: what data comes in, what context the AI sees, who is allowed to perform an action, and which check blocks a mistake before deployment.

If the application is already live and you’re not sure where sensitive data is stored or who can reach it, start with the full rescue guide and take a look at the Vibe Coding Rescue service. You can also contact us for a focused review.

---

Sources and further reading:

• Secure Coding with AI Cheat Sheet — OWASP
• OWASP Top 10:2025, Next Steps — Inappropriate Trust in AI Generated Code
• Row Level Security — Supabase
• Protection of Privacy (Data Security) Regulations: FAQ (Hebrew)
• The VibeSec Reckoning — Martin Fowler / Thoughtworks