We talk to founders every week who are navigating fundraises, enterprise sales cycles, and compliance reviews. Increasingly, one conversation comes up that didn't exist a year ago: an investor or client asks how the product was built, hears "AI," and gets nervous.
Sometimes the concern is specific — they want to see a certification or understand the data access model. More often it's vague: a general unease about whether software built with AI tools can be trusted in production.
We wrote this guide because we think that concern is worth taking seriously, and because the answer, when you look at what's actually being evaluated in a security review, is more straightforward than most founders expect.
This post walks through what a technical due diligence review looks for, where AI-built applications genuinely differ from traditionally built ones, and how to use the security tooling inside Lovable to produce the evidence that closes the conversation.
What due diligence actually evaluates
A common misconception among founders is that technical due diligence is a code review. A due diligence security assessment evaluates systems, not syntax. Specifically, it looks at five areas:
1. Data access controls
Who can access what data, and how is that enforced? This is the single most scrutinized area in any early-stage security review. Can User A access User B's data? Can an unauthenticated request reach your database? Are your access policies enforced at the database level, or only in your application code?
2. Infrastructure security posture
Where is the application hosted? What certifications does the hosting provider hold? Is data encrypted in transit and at rest? Are secrets managed properly, or are API keys exposed in client-side code? Is the infrastructure multi-tenant with proper isolation, or is there blast radius risk?
3. Vulnerability management
Has the application been tested for common vulnerability classes — OWASP Top 10, injection attacks, authentication bypasses, privilege escalation? Is there evidence of ongoing security scanning, not just a one-time check? Are vulnerabilities tracked, prioritized, and remediated systematically?
4. Dependency and supply chain hygiene
What third-party libraries does the application rely on? Are any of them known to be vulnerable? Is there a process for monitoring and updating dependencies when new CVEs are disclosed?
5. Incident readiness and operational maturity
If something goes wrong, what happens? Is there logging? Is there monitoring? Is there a formal incident response process? Are environments properly separated so that a development mistake can't leak into production?
None of these categories care how the code was written. They care whether the code is secure, whether the infrastructure is sound, and whether there is evidence to prove both.
The AI question: What's actually different
When an investor says "they built it with AI — should we be worried?", there is a legitimate technical concern underneath the skepticism. It's not that AI writes inherently insecure code. It's that AI-assisted development compresses the time between "idea" and "production" so dramatically that traditional security checkpoints can be skipped entirely.
In a conventional development workflow, security review happens at multiple stages: during code review, in CI/CD pipelines, before deployment. These gates exist because the development cycle is long enough to accommodate them. When a working application can be built in hours instead of months, those gates need to be rebuilt into the tooling itself.
The reality is that AI-generated code produces the same categories of vulnerabilities as human-written code — misconfigured access controls, exposed secrets, insecure dependencies, injection vectors. The attack surface is the same. The difference is velocity: you can introduce a vulnerability faster, which means you also need to detect and fix it faster.
Lovable's approach is to embed security directly into the generation pipeline. AI-powered security agents independently review generated code for vulnerabilities before it is surfaced to the user. Output validation runs immediately after generation. Scanning is triggered automatically by code changes, pre-publish, and during background analysis. Findings are tracked across regenerations to prevent regressions. This is integrated into the same loop that produces the code.
The platform layer: What your app inherits
Before we get to what you as a founder need to do, it's worth understanding what you inherit by building on Lovable. A due diligence reviewer will ask about your infrastructure, and the answer matters.
Multi-cloud, defence-in-depth architecture
Lovable operates across Google Cloud Platform and Cloudflare with a defence-in-depth segmentation model. All production workloads run in private networks with no direct public exposure unless explicitly required. The architecture separates public subnets (limited to load balancers and NAT gateways) from private subnets where all compute workloads run. GCP isolation is enforced through private GKE clusters with no public endpoints. Cloudflare provides automatic DDoS protection at the edge for all Workers, and GCP Cloud Armor provides Layer-7 DDoS protection with adaptive protection enabled.
This multi-cloud architecture is designed to minimize systemic risk.
Full tenant isolation
Every Lovable project receives a completely separate Supabase project with its own isolated PostgreSQL database, Auth system, Storage buckets, Edge Functions, and API endpoints. This is not shared-database multi-tenancy with logical separation — it is project-level isolation with independent infrastructure per application.
For a due diligence reviewer, this is significant. It means a vulnerability in one customer's application cannot propagate to another customer's data. The blast radius is contained by design.
Encryption everywhere
All data is encrypted at rest using AES-256 and in transit using TLS 1.3. Secrets are AES-GCM encrypted at the field level before storage, managed through Google Cloud KMS with workspace-scoped key rings that provide isolation between tenants. Secrets are decrypted only for authorized integrations and are never returned in plaintext through the API. Inter-service communication uses mutual TLS (mTLS).
AI governance
Lovable uses a multi-provider AI strategy (Anthropic Claude, Google Vertex AI, OpenAI, AWS Bedrock) with routing and fallback for resilience. Critically: Lovable does not train, fine-tune, or customize foundation models using enterprise customer data. Customers retain ownership of all inputs and outputs. An opt-out mechanism is available at any time. AI usage has been assessed under the EU AI Act and classified as Low Risk.
Prompt filtering and sensitive data detection are applied to all LLM inputs. Output validation pipelines detect drift, bias, and unexpected behavior. Circuit-breaker capabilities allow rapid provider disablement in the event of a security or quality incident.
Compliance certifications
Lovable is ISO 27001:2022 certified and SOC 2 Type II aligned, with security controls aligned to the SOC 2 Trust Services Criteria. The platform is GDPR compliant with a Data Processing Agreement available. OWASP Top 10 web application risks are addressed through the automated Security Checker.
The SOC 2 report is available under NDA through your account manager, and the Trust Center is publicly accessible at trust.lovable.dev.
What you need to do: The founder's security checklist
Everything above is what the platform provides. Here's what you, as a founder, are responsible for, and the tools Lovable gives you to do it.
1. Run the Security Scanner and resolve all findings
Lovable uses four automated security scanners that cover the core vulnerability categories:
- RLS Analysis — Reviews your database access policies and row-level security rules. Runs automatically when migration or configuration files change.
- Database Security Check — Reviews your database schema and RLS configuration together to catch unsafe combinations. Runs once per session after RLS analysis.
- Code Security Review — Analyzes your application code for common vulnerability patterns including XSS, input handling issues, insecure authentication flows, and unsafe use of external services. Available on demand.
- Dependency Audit — Checks your npm dependencies against known CVE databases. Runs automatically when dependencies change.
These scanners run before publishing — if critical issues are found, you'll be prompted to review them before proceeding. Resolve all critical issues before making your app publicly available.
What to show investors: The Security Center dashboard showing clean scan results across all four scanners with no unresolved critical findings.
2. Verify your Row-Level Security policies
Misconfigured RLS is the single most common cause of data exposure in Supabase-backed applications. Lovable enables RLS by default and includes a linter that catches missing RLS enablement after database migrations. But you still need to verify that your policies are correct — that users can only access their own data, that admin roles are properly scoped, and that no table is inadvertently public.
What to show investors: Documentation showing that every table has appropriate RLS policies, that no tables are publicly accessible without authentication, and that your access control model enforces user-scoped data access at the database level. You can generate this by running a conversational security review focused on RLS.
3. Confirm your secrets are properly managed
Lovable automatically detects API keys pasted into the chat and redirects you to store them in Secrets rather than hardcoding them into client-side code. When you describe an integration, Lovable generates the implementation using server-side Edge Functions and secure secret storage — keeping credentials out of the browser entirely. Edge Functions are JWT-protected by default.
Verify that all third-party API keys are stored server-side and that no keys are exposed in your frontend bundle. This is trivially verifiable by inspecting your deployed application's JavaScript.
What to show investors: Your Secrets configuration and confirmation that sensitive credentials are managed through environment variables, not embedded in client-side code.
4. Run an AI penetration test
This is the strongest single piece of evidence you can produce. Lovable integrates with Aikido Security to provide real AI-powered penetration testing directly from the Security Center.
Unlike static analysis, which reads your code and flags potential issues, a penetration test attacks your live, running application. Hundreds of AI agents perform whitebox, greybox, and blackbox testing across OWASP Top 10 vulnerabilities, LLM Top 10, privilege escalation, cross-user data access (IDOR), business logic flaws, authentication and session management, and API security.
Every finding is validated to eliminate false positives and AI hallucinations — only confirmed, exploitable vulnerabilities are reported. Findings sync back into Lovable's Security Center with AI-generated remediation recommendations, fixable via "Try Fix All" or by referencing specific issues in chat. Once fixed, you can retest the fix directly in Aikido to confirm resolution before generating your final report.
The output is a formal penetration test report — audit-ready for SOC 2, ISO 27001, and any client security questionnaire. And if the pen test finds zero issues, you don't pay — that's Aikido's zero-findings guarantee.
What to show investors: The Aikido pen test report. This is the document that answers "is this secure?" with independent, third-party evidence. It carries weight precisely because it comes from a specialized security vendor — not from the platform you built on. This is the same class of artifact that enterprise security teams produce, now accessible to a two-person startup.
5. Run a conversational security review
You can ask Lovable's AI agent to perform a comprehensive security review of your project at any time. The agent analyzes your application and produces a detailed assessment covering application code vulnerabilities, authentication flows, database schema and RLS policies, and your overall security posture with specific recommendations.
Running a conversational review before a fundraise gives you a written record of your security posture assessment — and evidence that you actively sought it.
What to show investors: The output of a conversational security review showing that you proactively assessed your application's security posture and addressed the recommendations.
6. Monitor ongoing posture through the Security Center
For founders managing multiple projects, the Workspace Security Center provides a single dashboard that monitors security posture across your entire workspace. This gives you visibility into which projects have outstanding findings, which have clean scan results, and where your attention is needed.
What to show investors: The Security Center overview showing clean posture across all active projects. This demonstrates ongoing security hygiene, not just a one-time cleanup before a fundraise.
Assembling the due diligence package
Here is the specific set of artifacts you should prepare:
1. Aikido Pen Test Report (PDF) — Third-party penetration test results showing your application has been tested against real attack vectors and either passed clean or had all findings resolved and retested.
2. Security Center Dashboard — Clean scan results across all four automated scanners with no unresolved critical findings.
3. RLS Policy Summary — Documentation confirming that every database table has appropriate row-level security policies and that user data isolation is enforced at the database level.
4. Secrets Audit — Confirmation that all third-party API keys are stored server-side and that no credentials are exposed in client-side code.
5. Platform Compliance Documentation — Reference to Lovable's ISO 27001:2022 certification, SOC 2 Type II alignment (report available under NDA), GDPR compliance with DPA, and EU AI Act Low Risk classification. Available via trust.lovable.dev.
6. Conversational Security Review — Written security posture assessment with evidence that findings were addressed.
This package answers every question a due diligence reviewer will ask. It demonstrates static analysis (Security Scanner), dynamic analysis (Aikido pen test), infrastructure compliance (SOC 2, ISO 27001), data access controls (RLS), secrets management, AI governance, and ongoing monitoring (Security Center).
If you need additional support as a founder in your journey building on Lovable, don’t hesitate to reach out directly!
Get started with Lovable's security tools: Security Documentation | Trust Center | AI Pen Testing →
