Lovable Publishes Security Rules for Financial Services: 13-Week Audit Logs and EU Inference

Lovable, a service for building working apps from prompts, has released a guide for chief marketing officers in the financial sector. The premise is simple: a campaign prototype can now be built in hours, but compliance and security sign-off still takes weeks. The document describes where responsibility is split between the platform and the customer, what data must not be uploaded to Lovable, and how to check an app before publishing. It is a vendor document, but it is specific enough to serve as the basis for an internal checklist.

Platform and app: two layers of protection

Lovable splits security into two layers. The platform layer covers encryption, workspace isolation, enterprise identity, audit logs, and detection, prevention, and scrubbing of personally identifiable information (PII). Security teams need it to evaluate Lovable as a vendor. The app layer consists of automated checks on what the user built: unsafe database permissions, leaked keys, vulnerable dependencies, and holes in the code.

Before building, the company suggests answering five questions: what data is involved (public, internal, personal, or confidential investment data), who the audience is, what the app does (displays information, changes records, sends messages, gives recommendations), what an error would cost, and who owns the app and can shut it down. Low-risk examples include an internal campaign planner using synthetic data or an event landing page prototype. High-risk examples include an investor portal, personalized fund marketing, a CRM integration, and tools containing unpublished ratings. The guide stresses separately that "internal" does not mean "safe" if the app holds material non-public information (MNPI).

The key restriction is section 3.8 of the data processing agreement (DPA) for Business and Enterprise. It prohibits uploading sensitive data: financial account numbers, government identifiers, biometrics, and protected health information. Access controls and EU inference do not lift this prohibition.

Connectors, data, and processing geography

Connectors are the trickiest part. There are four types, and the choice determines who can see the data:

• Chat connector: personal context during the build stage (for example, a brief from Google Drive). It does not reach the published app, but colleagues may see data in a shared project.
• App + chat connector: one shared account for building and running the app; users see data within that account's permissions.
• App user connector: each person works under their own account, so a manager, for example, sees only their own accounts.
• Custom connectors and MCP: behavior depends on which connection type is chosen.

There is a separate warning: if an app copies records into its own database, the source system's permissions do not follow them. Access to the stored copies must be defined and tested again. According to the document, permissions must be enforced on the backend or in the database, not by hiding buttons and pages.

On model training: content from Business and Enterprise customers (prompts, files, code, outputs) is excluded from training by default. On Free and Pro, data may be used unless the user opts out. EU inference is available on Enterprise and routes requests to models at European endpoints; if no suitable one exists, the request fails rather than going to another region. The caveats matter: provider boundaries differ, some features are unavailable, some agentic tools still process data in the US, and the setting does not change where app data is stored. The Lovable Cloud backend region is chosen separately.

Logs, plans, and a pre-publication checklist

Enterprise audit logs record changes to members, roles, settings, connections, and publications: who did what, when, and to which resource. They are kept for 13 weeks, roughly 90 days, after which you need to export them. Actions inside the app itself, such as an investor downloading a document or a mailing being approved, do not appear in these logs; the developer must build that tracking in.

On plans: Pro offers custom domains and design systems. Business adds SSO, role-based access, design templates, and no training on your data by default. Enterprise adds audit logs, SCIM, and scheduled security scans. Budget credits for both building and running the app: the backend, AI, and some connectors consume them too.

A practical sequence for a team looks like this. First, classify the project using the five questions and check the data against the DPA. Build on synthetic data.

For an app with five users, choose a custom audience on Business and Enterprise, or Invite only on Free and Pro. Test both edges: an outsider cannot open the dashboard, and an invited user sees only their own records. Add a confirmation step for actions with consequences.

Keep secrets only in the Secrets store, not in the frontend. Fix the vulnerabilities the scanner finds, test with different accounts, and assign an owner who can shut the app down. The platform provides the tools, but responsibility for data and permissions stays with you.