Secrets Management and Security Scanning

Relevant source files

• Lovable/Agent Tools.json

Purpose and Scope

This document covers Lovable's security infrastructure, specifically the secrets management system for encrypted API key storage and the automated security scanning capabilities for Supabase backend analysis. These tools ensure sensitive credentials are handled securely and database configurations are validated for common security vulnerabilities.

For general file operations and tool ecosystem, see 4.3.1. For Supabase-specific integration patterns, see 4.3.6. For broader security architectures across AI assistants, see 8.6.

---

System Architecture Overview

Lovable implements two distinct security subsystems:

Subsystem	Tools	Primary Purpose
Secrets Management	secrets--add_secret secrets--update_secret	Encrypted storage of API keys and tokens as environment variables
Security Scanning	security--run_security_scan security--get_security_scan_results security--get_table_schema	Automated detection of exposed data, missing RLS policies, and misconfigurations in Supabase backends

Both subsystems operate independently but share a common goal: preventing credential exposure and data leaks in production applications.

Sources: Lovable/Agent Tools.json230-433

---

Secrets Management Architecture

Tool Overview

Diagram: Secrets Management Tool Flow

Sources: Lovable/Agent Tools.json230-254

Add Secret Tool

The secrets--add_secret tool is the only authorized method for collecting secrets from users:

Property	Value
Tool Name	secrets--add_secret
Description	Add new secret (API key/token) with encryption
Required Parameters	secret_name (string)
Example	STRIPE_API_KEY
Security Mandate	"IMPORTANT: This is the only way to collect secrets from users, do not add it in any other way."

Critical Implementation Requirement:

The tool description Lovable/Agent Tools.json231 explicitly states: "Never ask the user to provide the secret value directly instead call this tool to obtain a secret." This design prevents secrets from appearing in:

• Chat logs
• System prompts
• Code comments
• Version control history

When invoked, the tool prompts the user through a secure input mechanism (details abstracted from AI agent), encrypts the value, and stores it for backend access.

Sources: Lovable/Agent Tools.json230-241

Update Secret Tool

The secrets--update_secret tool handles credential rotation:

Diagram: Secret Update Workflow

The update mechanism ensures zero-downtime credential rotation by:

1. Accepting the secret_name parameter (e.g., "STRIPE_API_KEY")
2. Prompting user for new value through secure channel
3. Replacing encrypted storage atomically
4. Updating environment variable exposure

Sources: Lovable/Agent Tools.json243-254

Environment Variable Integration

All secrets added via secrets--add_secret are automatically exposed as environment variables in backend code. This enables standard access patterns:

No explicit import or configuration required—the platform handles injection transparently.

Sources: Lovable/Agent Tools.json231

---

Security Scanning Architecture

Three-Tool Analysis System

Diagram: Security Scanning Tool Relationships

Sources: Lovable/Agent Tools.json407-433

Run Security Scan Tool

The security--run_security_scan tool initiates comprehensive backend analysis:

Property	Value
Tool Name	security--run_security_scan
Description	"Perform comprehensive security analysis of the Supabase backend to detect exposed data, missing RLS policies, and security misconfigurations"
Parameters	None required
Execution Model	Asynchronous

The tool analyzes three critical security dimensions:

1. Exposed Data Detection: Identifies tables or columns accessible without authentication
2. Missing RLS Policies: Flags tables lacking Row-Level Security enforcement
3. Security Misconfigurations: Detects overly permissive policies or authentication bypass patterns

Sources: Lovable/Agent Tools.json407-413

Get Security Scan Results Tool

The security--get_security_scan_results tool retrieves analysis output:

Property	Value
Tool Name	security--get_security_scan_results
Required Parameters	force (boolean)
Force Flag Purpose	"Get results even if a scan is running"

Usage Pattern:

Diagram: Asynchronous Scan Retrieval Flow

The force parameter enables two retrieval modes:

• force=false: Wait for scan completion, return final report
• force=true: Return immediate results even if scan incomplete (useful for streaming progress)

Sources: Lovable/Agent Tools.json415-425

Get Table Schema Tool

The security--get_table_schema tool provides database structure context:

Property	Value
Tool Name	security--get_table_schema
Description	"Get the database table schema information and security analysis prompt for the project's Supabase database"
Parameters	None required
Output	Table definitions + Security analysis guidance

This tool serves dual purposes:

1. Schema Inspection: Provides column types, constraints, relationships
2. Security Context: Returns prompts/templates for analyzing discovered vulnerabilities

Sources: Lovable/Agent Tools.json427-433

---

Security Scanning Workflow

Complete Analysis Sequence

Diagram: End-to-End Security Analysis Workflow

Sources: Lovable/Agent Tools.json407-433

---

Integration with Supabase Backend

All security scanning tools are tightly coupled to Supabase:

Tool	Supabase Dependency
security--run_security_scan	"...of the Supabase backend..."
security--get_table_schema	"...project's Supabase database"

This specialization reflects Lovable's architecture: projects use Supabase as the primary backend with:

• PostgreSQL database
• Row-Level Security (RLS) policies
• Authentication via Supabase Auth
• Real-time subscriptions

The security scanner specifically validates:

1. RLS Policy Coverage: Every table must have policies defined
2. Anonymous Access: No tables should be publicly readable/writable unless explicitly intended
3. Authentication Enforcement: Policies should reference auth.uid() correctly
4. Column-Level Security: Sensitive columns (e.g., email, phone) should have restricted access

Sources: Lovable/Agent Tools.json408-428

---

Comparison with Other Systems

Secrets Management Across Platforms

Platform	Secret Tool	Encryption	Environment Variable Exposure
Lovable	secrets--add_secret	Yes (automatic)	Backend code via env vars
v0	GetOrRequestIntegration	Yes (platform-managed)	Automatic injection in server code
Windsurf	Not documented	N/A	Manual .env file management
Antigravity	Not documented	N/A	Manual configuration

Lovable's approach is the most restrictive: it forbids direct secret input and mandates tool-based collection, preventing accidental credential leakage in chat history.

Security Scanning Comparison

Platform	Security Scanning	Backend Focus	RLS Validation
Lovable	security--run_security_scan	Supabase-specific	Yes (comprehensive)
v0	Not documented	N/A	Manual RLS setup required
Same.dev	Not documented	N/A	N/A
Comet	9-layer security (client-side)	Browser/API calls	N/A (no backend)

Lovable is the only system with automated backend security analysis capabilities, reflecting its focus on full-stack application development with integrated databases.

Sources: Lovable/Agent Tools.json230-433

---

Best Practices and Usage Guidelines

Secrets Management

1. Never Ask for Direct Input: Always invoke secrets--add_secret tool rather than requesting the user type the secret in chat
2. Use Descriptive Names: Secret names should match the expected environment variable format (e.g., STRIPE_SECRET_KEY, not stripe_key)
3. Rotate Regularly: Use secrets--update_secret for credential rotation without recreating integrations
4. Backend-Only Exposure: Secrets are only available in backend/server code, never exposed to client-side JavaScript

Security Scanning

1. Run Early: Execute security--run_security_scan immediately after creating Supabase tables
2. Interpret Results: Use security--get_table_schema to understand database structure when analyzing vulnerabilities
3. Iterative Fixes: After addressing issues, re-run scan to validate corrections
4. Force Flag Usage: Use force=true only when needing immediate feedback during development; prefer force=false for complete reports

Integration-Driven Workflow

Diagram: Integration-Driven Secret and Security Flow

When adding integrations (Stripe, external APIs), the workflow naturally progresses from secret collection to security validation, ensuring credentials are both securely stored and properly restricted in the database layer.

Sources: Lovable/Agent Tools.json230-413

---

Technical Implementation Notes

Encryption and Storage

While implementation details are abstracted from the AI agent, the system guarantees:

• At-Rest Encryption: All secrets encrypted before storage
• Transport Security: Secure channels for user input
• Access Control: Only backend processes can decrypt and access secrets
• Audit Logging: Secret creation/updates logged for security review

Scan Engine Capabilities

The security--run_security_scan engine performs static analysis of:

• PostgreSQL table definitions
• RLS policy SQL statements
• Supabase authentication configuration
• Public schema permissions

It does not perform:

• Penetration testing
• Runtime vulnerability exploitation
• Application-level logic analysis
• Client-side security validation

The focus is exclusively on Supabase backend configuration, complementing (not replacing) broader application security practices.

Sources: Lovable/Agent Tools.json408

---

Related Documentation

• 4.3.1 - Tool Ecosystem and Naming Conventions: Overview of all lov-* and specialized tools
• 4.3.6 - Analytics and External Integrations: Stripe and Supabase documentation search tools
• 4.1.6 - v0's Integration Ecosystem: Comparison with v0's GetOrRequestIntegration approach
• 8.6 - Security Models and Safety Constraints: Cross-platform security architecture analysis