Secure Vibe Coding: Security Best Practices for AI-Built Apps, AI Automation and AI Data Analysis

Short answer

1What vibe coding is, and why it changes security

Vibe coding is building software by describing what you want in natural language and letting a generative AI write the code, with the human guiding the result through conversation rather than writing instructions line by line. Researchers describe it as a shift from deterministic instruction to probabilistic inference, and point to its risks: “black-box” codebases nobody fully understands, and gaps in who is responsible for what.^[1]

Tools such as Claude Code, Cursor, Lovable, Replit and Bolt let non-developers ship real apps, and AI agents in n8n or connected through MCP can act on email, files and databases. The security problem is simple: the code and the actions are produced faster than anyone reviews them. At the same time, attackers are focusing on exactly the weaknesses fast-built software tends to have. Verizon's 2026 DBIR found that 31% of breaches now start with exploited software vulnerabilities, ahead of stolen passwords.^[2]

2What the research says about AI-written code

• About 40% vulnerable. In an IEEE Security & Privacy 2022 study, researchers generated 1,689 programs with GitHub Copilot in security-relevant scenarios and found approximately 40% of them vulnerable.^[3]
• Less secure, but more confident. A Stanford user study (ACM CCS 2023) found that participants with an AI assistant wrote significantly less secure code than those without one, and were more likely to believe their code was secure. Participants who trusted the AI less and refined their prompts produced fewer vulnerabilities.^[4]
• 45% of tasks failed security tests. Veracode's 2025 report tested code from over 100 language models and found security flaws in 45% of tests. Larger, newer models did not produce more secure code.^[5]
• Invented packages. A USENIX Security 2025 study of 576,000 code samples from 16 models found hallucinated (non-existent) package names in at least 5.2% of suggestions from commercial models and 21.7% from open-source models: 205,474 unique fake names that attackers can register with malicious code (“slopsquatting”).^[6]
• More leaked secrets. GitGuardian found nearly 23.8 million new secrets exposed on public GitHub in 2024, and a 6.4% secret-leak rate in repositories using Copilot, about 40% higher than the average.^[7]

3The new risks, in one table

OWASP maintains dedicated risk lists for LLM applications (2025)^[10] and for agentic AI (2026 edition, released December 2025).^[11] Here is how they translate for a business using AI tools:

4Best practices for vibe coding websites and apps

1. Put security in the prompt, then verify anyway

State your requirements explicitly: “use parameterised queries, check that the logged-in user owns every record, validate all inputs, never put secrets in client code.” The CCS study found that users who engaged critically with their prompts got fewer vulnerabilities,^[4] but prompting is not enough on its own, since even large models fail security tests often.^[5] Then ask for a dedicated security review of the change. Claude Code, for example, has a /security-review command and a security-guidance plugin for this.^[20]

2. Review like it's a junior developer's pull request

You stay responsible for the code. Claude Code's documentation says it plainly: you're responsible for reviewing proposed code and commands before approving them.^[20] Check the OWASP Top 10:2025 hot spots first: access control, misconfiguration, supply chain, injection and authentication.^[12] If you can't read the code yourself, have someone who can review anything that handles logins, payments or personal data.

3. Check every dependency the AI adds

Before installing a package, confirm it exists, is the one you meant, is maintained and is widely used. Hallucinated names are a documented attack path.^[6] Lock dependency versions and scan them automatically, in line with NIST's secure development profile for generative AI.^[21]

4. Keep secrets out of prompts, code and repos

Use environment variables or a secrets manager, never hard-coded keys, and turn on secret scanning in your repository. AI-assisted repositories leak secrets more often than average.^[7] With Supabase-style backends, the publishable key is public by design; the secret service_role key bypasses all row-level security and must never reach the browser.^[22]

5. Lock down the database: enable row-level security

The Lovable case shows the classic vibe-coding failure: the app works, but the database answers anyone.^[8] Supabase's guidance is to enable RLS on every table in an exposed schema and write policies so each user can only reach their own rows.^[22] Test it: log in as user A and try to read user B's data.

6. Separate development from production, and keep backups

Never give an AI coding agent write access to production data. The Replit incident happened because an agent could run destructive commands on a live database, and the fix Replit shipped was dev/prod separation.^[9] Use a copy of the database for development, keep production credentials out of the AI's environment, and keep tested backups and version control (Git) so every change can be undone.

7. Choose the right permission mode and sandbox

Coding agents let you decide what they may do without asking. In Claude Code, manual mode starts read-only and asks before editing files or running commands, while auto mode uses a classifier to block actions it judges unsafe.^[20][23] Sandboxing adds filesystem and network isolation at the operating-system level.^[24] For untrusted repositories or web-facing tasks, Anthropic recommends running in a virtual machine or dev container.^[20]

5Best practices for AI agents and automation (n8n, MCP)

1. Assume prompt injection will happen

Research on indirect prompt injection showed that LLM-integrated applications “blur the line between data and instructions”: text the AI retrieves (a web page, an email, a document) can steer what it does, including calling APIs and leaking data.^[14] OWASP ranks prompt injection as the number one LLM risk and recommends least-privilege access, human approval for privileged operations, and clearly separating untrusted content from instructions.^[13]

2. Apply “least agency”

OWASP's Excessive Agency risk has three causes: too much functionality, too many permissions and too much autonomy.^[15] So give the agent only the tools the task needs (a summariser doesn't need “send email”), connect those tools with narrowly scoped, read-only credentials where possible, and keep a person in the loop for consequential actions.^[15]

3. Put a human approval on risky tool calls

n8n can pause an AI Agent before it runs selected tools and ask a person to approve or deny the call through Slack, email, the n8n chat or other channels.^[25] Use it for deleting, sending to customers, paying, publishing, or anything touching regulated data.

4. Never execute AI output blindly

Treat model output like untrusted user input: validate it, encode it for its destination, and use parameterised queries, never pass it straight to a shell, eval(), SQL or an HTML page.^[16] In n8n, that means checking AI-generated values with an IF or validation step before a Code, database or HTTP node uses them.

5. Patch your automation platform fast

AI automation platforms hold the keys to everything else. In n8n, CVE-2025-68613 (CVSS 9.9) allowed authenticated users to execute code through workflow expressions,^[26] and CVE-2026-21858 (CVSS 10.0) let unauthenticated attackers read server files through certain form workflows.^[27] Update within days of a security release, enable two-factor authentication and SSRF protection, disable the public API if unused, and redact execution data, as n8n's security guide recommends.^[28] Protect every webhook with authentication or an IP allowlist.^[29]

6. Treat MCP connectors like installed software

The MCP specification states that tools represent arbitrary code execution, that hosts must obtain explicit user consent before invoking a tool, and that tool descriptions from untrusted servers should themselves be treated as untrusted.^[30] Its security best practices forbid token passthrough, recommend minimal OAuth scopes requested progressively, and require consent and sandboxing for local MCP servers, which run with the same privileges as the client.^[31] Anthropic reviews connectors before listing them in its directory but does not security-audit MCP servers, so use servers you wrote yourself or from providers you trust.^[20]

6Best practices for AI data analysis

Uploading a spreadsheet to ChatGPT, Claude or Gemini, or letting an agent query your database, is one of the most common AI uses in business, and the most common way data leaks.

1. Share the minimum, anonymise the rest

OWASP's Sensitive Information Disclosure risk covers personal data, financial details, health records and confidential business information flowing into or out of AI systems. Its mitigations include sanitising data, least-privilege access and educating users about what not to share.^[17] In practice: remove names, emails, phone numbers and IDs, or replace them with codes, before analysis; aggregate where you can; and never upload credentials or full customer databases.

2. Use business plans and check the training setting

Data-use terms differ between consumer and business plans. Anthropic, for example, states that by default it does not use data from its commercial products (Team, Enterprise and API) for model training, while consumer users control a training preference in their privacy settings.^[32][20] Read the terms of each AI tool you use for company data, and set the training option deliberately.

3. Remember that privacy law still applies

The European Data Protection Board's Opinion 28/2024 confirms that data-protection rules apply to personal data processed in the context of AI models, including questions of lawful basis and when a model can be considered anonymous.^[33] The EU AI Act (2024) adds obligations for organisations that use AI systems, including ensuring sufficient AI literacy among the staff who use them.^[34]

4. Give analysis agents read-only access

An agent that answers questions about your sales data needs SELECT, not DELETE. Connect it with a read-only database user, or a read-only copy, limited to the tables it needs.^[15] Spreadsheets and documents you analyse can themselves contain injected instructions, so the same prompt-injection precautions apply.^[14]

5. Verify the numbers before you act

NIST's Generative AI Profile lists confabulation (confidently stated but false content) among the risks specific to generative AI.^[19] OWASP warns about over-reliance on AI output for decisions.^[18] Ask the AI to show the code or formula it used, re-run key figures yourself on a sample, and have a person sign off on any number that reaches a client, an invoice or a decision.

7Frameworks to build on

• NIST AI Risk Management Framework (2023), built around four functions (Govern, Map, Measure, Manage), and its Generative AI Profile (2024) for risks specific to generative AI.^[35][19]
• NIST SP 800-218A (2024), which extends secure software development practices to generative AI.^[21]
• Guidelines for Secure AI System Development (2023) from the UK NCSC, US CISA and partners, organised in four stages: secure design, development, deployment, and operation & maintenance.^[36]
• OWASP Top 10 for LLM Applications 2025 and Top 10 for Agentic Applications 2026 as practical risk checklists.^[10][11]

For a small business, a one-page policy is enough to start: which AI tools are approved, what data may go into them, who reviews AI-written code, and which agent actions always need a human approval.

8The checklist

To understand the automation building blocks referred to here, read How automation workflows really work. For the technical health of the site itself, see our SEO & GEO audit prompt.