1 Key Risks
The most critical security risks an operator inherits when deploying this agent in its documented default configuration. Lovable concentrates risk in its default-allow tool authority model and an architectural pattern that places the database on the public internet behind a client-embedded credential.
2 AIRQ Scores
The four headline scores quantify how exposed the agent is, how damaging a successful attack would be, and how much the agent’s own controls reduce that risk. Lovable lands in the upper-middle attack band with moderate blast radius and partial defense controls anchored primarily on execution isolation.
Lovable lands in Exposed Giants because demonstrated exploitation of its authorization layer and generated-app defaults has been confirmed in production, while per-project sandboxing prevents a single compromise from cascading across the tenant boundary — operators should adopt with hardening controls rather than accepting the default posture.
Each axis measures a distinct dimension: Attack Surface rates exposure out of ten, Blast Radius rates damage potential out of ten, and Defense Controls rates vendor-implemented safeguards out of fifteen.
| Metric | Score | Comments |
|---|---|---|
| AIRQ Score | 5.33 | Partial defense controls and moderate blast radius offset an above-midline attack surface to produce a mid-band composite. |
| Blast Radius | 6.25 / 10 | Network, credential, and deployment factors sit at the upper band while code execution and file system remain project-scoped. |
| Attack Surface | 5.34 / 10 | Two surfaces carry demonstrated agent-specific exploitation; the remaining eight rest on architectural base bands without confirmed incidents. |
| Defense Controls | 5 / 15 | Execution isolation carries the defense score; input guardrails contribute nothing and action controls default to full authority. |
3 Attack Surface
Attack surfaces are the entry points and interaction patterns through which adversarial input can reach the agent’s reasoning loop and steer its behavior. The dominant exposures are the platform's generated-app configuration defaults and the output channel that ships client credentials into every deployed frontend.
Two surfaces reach the adjusted ceiling while six remain at the moderate band, reflecting a platform whose own infrastructure has been exploited but whose agent prompt channel has not.
Each row ties a scored surface to the architectural exposure and any agent-specific evidence that raised the adjusted score above the base band.
| Surface | Score | Comments |
|---|---|---|
| User Input | 2 / 4 | Multiple input channels exist (web chat, MCP connectors, GitHub sync) with documented input validation for generated code but none for agent prompts. [10] |
| External Data | 3 / 4 | Ingests content from MCP chat connectors, GitHub repositories, and external documentation fetches with no documented content validation gate. [12] |
| Memory | 2 / 4 | Chat history persists indefinitely within each project and prior context re-enters the reasoning loop on every turn, creating a poisoning surface if an early prompt embeds a persistent payload. [14] |
| Reasoning | 2 / 4 | Multi-step reasoning is visible through the Details view and constrained to declared project scope without delegating to external models. [14] |
| Planning | 2 / 4 | Agent mode decomposes tasks autonomously within a user-supervised session; no subagent delegation, scheduling, or background execution. [14] |
| Tool Execution | 3 / 4 | Full file system, database management, and code execution within a per-project sandbox; no shell access beyond the sandbox boundary. [14] |
| Orchestration | 2 / 4 | Multi-step execution within a single session with visible progress; no background processes, cron scheduling, or daemon operation. [14] |
| Inter-Agent | 2 / 4 | The MCP server endpoint allows external AI agents to connect with OAuth authentication; no unrestricted inter-agent message passing. [16] |
| Output Processing | 4 / 4 | Generated apps embed the Supabase anon key in client JavaScript; CVE-2025-48757 confirmed unauthenticated data access and a separate open redirect bypass exploited the output URL handling. [1][3] |
| Configuration | 5 / 4 | Tool settings default to Always allow; CVE-2025-48757 and the April 2026 BOLA incident both stem from insecure platform defaults. [1][2][13] |
The Lethal Trifecta is triggered when an agent processes untrusted content, accesses private data, and communicates externally in the same session — the three conditions that turn an isolated prompt injection into full-chain exfiltration. Lovable ingests third-party content from MCP connectors, holds database credentials and payment secrets within project scope, and transmits generated code to a public CDN and external APIs without crossing any agent-level output control.
Lovable exhibits all three of these conditions in its documented default configuration:
- Untrusted input — MCP chat connectors and the public MCP server endpoint bring third-party content directly into the agent reasoning loop. [12]
- Sensitive data — The agent manages Supabase service_role keys, payment integration secrets, and full project source code containing developer credentials. [2]
- External egress — Generated apps deploy to a public CDN, Edge Functions make outbound HTTP calls, and the AI Gateway proxies to external model providers. [10]
4 Blast Radius
The blast radius is what an attacker who controls the agent can reach — which systems they touch, which credentials they read, and which actions they take without operator approval. A compromised session reaches network egress, stored credentials, and deployment infrastructure while code execution and file access remain sandbox-scoped.
Three factors sit at the upper band while the remaining three are contained by the per-project sandbox boundary.
Each row ties a blast factor to the specific capability the agent exercises by default and the evidence that scopes its reach.
| Factor | Score | Comments |
|---|---|---|
| Code execution | 2 / 4 | Code runs in a per-project sandbox (micro-VM) with no documented escape; execution stays within the project boundary. [11] |
| File system access | 2 / 4 | Full read-write access to all files in the project directory including configuration, secrets, and source code within the sandbox boundary. [14] |
| Network access | 3 / 4 | Unrestricted outbound from Edge Functions and the AI Gateway with the Supabase database directly reachable from the public internet via client-embedded credentials. [6][12] |
| Credential access | 3 / 4 | The BOLA incident confirmed chat histories contained API keys, Stripe credentials, and Supabase service_role keys; independent audit corroborates plaintext credential storage in generated code. [2][5] |
| Autonomous action | 2 / 4 | Agent mode executes autonomously within a session but requires explicit publish action for production deployment; investigative coverage documented that the autonomous window led to prolonged exposure in confirmed incidents. [7][14] |
| Deployment access | 3 / 4 | Direct deploy to Lovable Cloud and GitHub push are default capabilities; the agent can publish production apps. [14] |
5 Defense Controls
Defense controls are what the agent’s own architecture does to detect, contain, and report attacks before they reach the operator’s systems. The vendor ships meaningful execution isolation but leaves input guardrails absent, action controls at default-allow, and monitoring limited to paid tiers.
Higher scores indicate stronger vendor-implemented safeguards; Lovable's defense is concentrated in execution isolation while other components contribute minimally.
Each component is scored on whether the vendor implements it by default, not whether operators can configure it after deployment.
| Component | Score | Comments |
|---|---|---|
| Input Guardrails | 0 / 3 | No documented prompt shield, injection detection, or content filtering exists for agent prompts; scanners target generated code only. [10] |
| Execution Isolation | 2 / 3 | Per-project sandbox with isolated Supabase instances, GKE private clusters, and Cloudflare edge protection documented in the architecture guide. [9][11] |
| Action Controls | 1 / 3 | Tool settings offer per-action approval but default to Always allow; changing defaults requires explicit operator configuration. [12] |
| Output Guardrails | 1 / 3 | Secret detection warns when API keys appear in chat and pushes to encrypted storage, but independent scans show 86 percent of generated apps fail basic CSRF checks. [4][10] |
| Monitoring | 1 / 3 | Workspace Security Center monitors findings on Business/Enterprise plans; no agent-action audit trail or SIEM forwarding documented. [10] |
6 Hardening Tips
Concrete actions an operator can take to reduce the risks reported above, grouped by which defense control each tip strengthens. Operators should prioritize restricting tool defaults to ask-every-time, enabling RLS audit automation, and forwarding agent action logs to a SIEM.
Input Guardrails
Input guardrails intercept adversarial content before it reaches the reasoning loop.
- Policy Require security review of all MCP chat connector sources before granting access to the workspace — counters absent input filtering on the agent prompt channel. [18]
- Configuration Restrict MCP server connections to a vetted allowlist in workspace settings — counters untrusted content ingestion from arbitrary external tools.
- Engineering Deploy a prompt-injection detection proxy between the user interface and the AI Gateway — counters zero input guardrails on the agent reasoning loop.
Execution Isolation
Execution isolation contains what a compromised agent can do on the host.
- Policy Mandate that all production workloads use Test and Live environment separation — counters direct development-to-production data leakage.
- Configuration Enable the Data collection opt-out setting at workspace level to prevent project code from entering training pipelines — counters default data sharing documented in the privacy policy. [17]
- Engineering Implement network egress controls on Edge Functions using Supabase network restrictions — counters unrestricted outbound from server-side code.
Action Controls
Action controls govern which tools and actions the agent can invoke autonomously.
- Policy Establish an organizational policy requiring all Lovable Cloud tool settings to use Ask every time rather than Always allow — counters default-open authority.
- Configuration Configure each Lovable Cloud tool permission to Ask every time in workspace App connector settings — counters the default-allow posture for database and deployment operations.
- Engineering Build a webhook-based approval gate that intercepts publish actions and requires secondary authorization — counters single-click production deployment by moving deployment access from the upper band toward contained.
Output Guardrails
Output guardrails inspect what the agent sends to other systems and users.
- Policy Require RLS audit sign-off using an automated scanner before any project publish — counters generated apps shipping without access controls.
- Configuration Enable the Security view's advanced mode and block publish on critical findings — counters the scanner gaps that miss RLS policy correctness.
- Engineering Integrate SymbioticSec vibe-scanner or equivalent into a CI pipeline on the synced GitHub repository — counters the platform scanner's inability to verify runtime behavior.
Monitoring
Monitoring captures what the agent did and surfaces anomalies for review.
- Policy Require Business or Enterprise tier to access the Security Center and mandate regular review of cross-project findings — counters invisible security state on lower tiers.
- Configuration Forward Edge Function logs and security scan results to an external SIEM via webhook integration — counters the absence of centralized agent-action monitoring.
- Engineering Build a custom audit-log Edge Function that records every agent tool invocation with timestamps and parameters — counters the lack of structured agent action trail.
7 References
The evidence base behind every score and finding in the profile, grouped by source type so the reader can verify any claim. Numbers in brackets throughout the report (e.g. [7, 13]) refer to entries below, listed in citation order.
Selected Vulnerabilities
- CVE-2025-48757 Insufficient RLS in Lovable-generated apps allows unauthenticated read/write to arbitrary database tables (CVSS 9.3 Critical CWE-863). Disputed by vendor who attributes responsibility to customers.
- Lovable BOLA API flaw exposing thousands of projects Broken Object Level Authorization in Lovable API let any free account access other users source code and database credentials via five API calls. Reported March 2026 patched April 2026.
- Open redirect bypass via path traversal on lovable.dev HackerOne public disclosure of an open redirect bypass using path traversal in the redirect parameter. The prior fix failed to cover double-slash sequences.
Selected Research
- VibeWrench scan of 29 Lovable apps Independent security firm scanned 29 Lovable-generated applications and found an average security score of 56 out of 100 with 86 percent failing CSRF checks.
- Inigra 600K-line Lovable code audit Security firm audited 600K lines of Lovable-generated code and found plaintext passwords with TODO comments and no automated tests.
- Governable architecture analysis of Lovable Independent architectural review documenting that Lovable Supabase database is directly reachable from the public internet via a client-embedded anon key.
- TNW coverage of Lovable security crisis Investigative coverage documenting the 48-day exposure timeline and finding that 91.5 percent of vibe-coded apps contained AI hallucination-related flaws.
Vendor Documentation
- Lovable security overview documentation Vendor documentation of four automated security scanners and their limitations including manual-only code review trigger.
- Lovable platform architecture and compliance guide Vendor-published architecture detail covering GCP and Cloudflare infrastructure and per-project Supabase isolation with ISO 27001 plus SOC 2 Type II compliance.
- Lovable integrations and tool permissions Vendor documentation of app connectors and chat connectors with default Always allow permission model for all Lovable Cloud tools.
- Lovable response to the April 2026 incident Vendor post-incident disclosure confirming the BOLA timeline and backend regression in February 2026.
- Lovable agent mode documentation Vendor documentation confirming autonomous execution mode that applies changes directly with minimal supervision.
- Lovable Trust Center The vendor trust center providing access to compliance documentation including SOC 2 Type II report availability under NDA.
- Lovable MCP server documentation Vendor documentation of the MCP server at mcp.lovable.dev that allows external AI agents to control Lovable projects programmatically.
Other Sources
- Detailed BOLA exploit walkthrough Security journalism detailing the five-API-call exploit chain from a free account and chained blast radius via leaked env files.
- The Register coverage of Lovable data leak The Register documented Lovable shifting response from denial to blame-shifting to partial apology.
- Lovable privacy policy and AI data handling Privacy policy documents the AI Gateway proxy to OpenAI and Gemini and the default use of customer data for model training on Free and Pro plans.
- Lovable HackerOne VDP program The vendor operates a vulnerability disclosure program through HackerOne covering XSS CSRF SQL injection authentication bypass and RCE.