> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lovable.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Privacy & security settings

> Manage workspace-wide controls for member access, project publishing, external sharing, connected tools, security scans, and data protection.

The **Privacy & security** tab is where **workspace admins and owners** manage workspace-wide controls for access, publishing, sharing, connected tools, security automation, and data protection. Open it from **Settings → Security & compliance → Privacy & security**.

After changing settings on this page, click **Save** to apply most updates.

Settings are grouped into the same sections shown in the UI.

## Access & membership

Controls how people join the workspace, what access new projects use by default, and whether projects can be moved to another workspace.

### Default project access

**Available on:** All plans; Restricted is available on Business and Enterprise\
**Default:** Workspace

Sets the visibility of every new project at the moment it is created.

<Note>
  Changing the setting does not change the visibility of existing projects.
</Note>

| Option                                   | Who can see the project                                                                                                                                                                               |
| :--------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Workspace** (default)                  | All members of this workspace can view, remix, or edit the project based on their role.                                                                                                               |
| **Restricted** (Business and Enterprise) | Only the owner and explicitly invited collaborators can access the project.<br />Keep in mind that workspace owners have full access to **all** projects in the workspace and can view and edit them. |

See [Control project access](/features/project-visibility) for more information.

### Restrict workspace invitations

**Available on:** Enterprise\
**Default:** Disabled

When disabled, editors, admins, and owners can invite viewers and external collaborators by email.

When enabled, only **admins and owners** can invite members by email to this workspace. Editors lose the ability to invite.

<Note>
  This restricts **manual invitations** only. JIT and SCIM provisioning continue to add users based on identity-provider configuration. If your workspace uses verified-domain JIT, users with matching email domains will still be automatically provisioned on sign-in.
</Note>

See [Invite by email](/features/people#invite-by-email) for more information.

### Invite links

**Available on:** Free, Pro, and Business\
**Default:** Enabled

When enabled, workspace admins and owners can generate a shareable link that lets anyone use it to join the workspace at a chosen role. Invite links expire 5 days after creation, and only one active link per role can exist at a time.

When disabled, no one can create invite links.

See [Invite by link](/features/people#invite-by-link) for more information.

### Workspace discovery

**Available on:** Business and Enterprise\
**Default:** Enabled

When enabled, anyone signing in to Lovable with an email address from your organization's verified domain can find this workspace from the **Find your team's workspace** flow and request access. This helps new employees find the workspace without needing a direct invitation.

When disabled, the workspace is invisible to domain-based discovery. Only users with a direct invitation can join.

Public email domains (such as `@gmail.com`) cannot discover workspaces this way regardless of the toggle.

<Note>
  Turning discovery off stops new requests but does not clear any access requests that were already submitted. Review and deny pending requests in **Settings → People**.
</Note>

See [Workspace access requests](/features/people#workspace-access-requests) and [Find your team's workspace](/features/workspace#find-your-team’s-workspace) for more information.

### Allow editors to transfer projects

**Available on:** Enterprise\
**Default:** Disabled

When disabled, only admins and owners can initiate a project transfer.

When enabled, editors who own a project can move it to another workspace, including a personal workspace outside your organization.

<Note>
  For regulated environments, leave this off. An editor transferring a project to a personal workspace removes it from your governance boundary entirely.
</Note>

### External collaborator access

**Available on:** Business and Enterprise (only visible when **Enforce SSO** is active)\
**Default:** Not allowed

Controls whether users outside your SSO domain can be added as collaborators on projects in this workspace, and at what maximum access level.

| Option                                            | What it means                                                                                                                                                                   |
| :------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Not allowed (default when Enforce SSO is enabled) | External users cannot be added to projects. If members try to invite someone outside your organization to a project, they get an error informing them that this is not allowed. |
| Viewer only                                       | External users can be added as read-only project viewers.                                                                                                                       |
| Editor or below                                   | External users can be added as project viewers or editors.                                                                                                                      |

When you turn on **Enforce SSO**, Lovable shows a confirmation dialog with a **Remove all external collaborators** checkbox, on by default.

* If you leave it checked, existing external collaborators are removed at the same time SSO is enforced.
* If you uncheck it, existing external collaborators keep their access on every project they were already invited to, capped at **editor** level. The workspace’s **External collaborator access** setting is set to **Editor or below** as part of this flow.

If you later change **External collaborator access** to **Not allowed**, Lovable shows a similar confirmation dialog with a remove option. If you choose not to remove them, existing external collaborators remain in the People list but lose access.

The next time they try to open the workspace or one of their projects, they see an **External collaboration disabled** error. If their email matches one of your verified domains, they’re redirected to sign in through SSO instead. A successful SSO sign-in provisions them as a full workspace member through just-in-time provisioning, and they’re no longer subject to the external-collaborator restriction.

See [Block or limit external collaborators](/features/people#block-or-limit-external-collaborators) for the full flow.

## Publishing

Controls who can publish projects, what audience published projects use by default, and whether security checks can block publishing.

### Default website access

**Available on:** Business and Enterprise\
**Default:** Anyone

Sets the default audience for a project the first time it is published. Changing this setting does not retroactively change access for already published projects.

| Option                                  | Who can reach the published URL      |
| :-------------------------------------- | :----------------------------------- |
| **Anyone** (default)                    | Anyone with the link                 |
| **Workspace** (Business and Enterprise) | Authenticated workspace members only |

Individual projects can override the workspace default during the publish flow.

See [Publish your project](/features/publish) for more information.

### Who can publish externally

**Available on:** Enterprise\
**Default:** Editors and above

By default, any workspace editor, admin, or owner can publish externally on all plans. Enterprise workspaces can restrict this further.

This setting sets the minimum workspace role required to publish a project to a public URL.

| Option                             | Who can publish externally                                   |
| :--------------------------------- | :----------------------------------------------------------- |
| **Editors and above** (default)    | Any workspace editor, admin, or owner can publish externally |
| **Admins and owners** (Enterprise) | Only workspace admins and owners can publish externally      |
| **Owners only** (Enterprise)       | Only workspace owners can publish externally                 |

<Note>
  Existing public projects can still be re-published by editors if they were already public before this setting was tightened. The stricter restriction applies only when a project is published publicly for the first time, or when a previously public project has been unpublished and is deployed publicly again.
</Note>

<Warning>
  **Self-locking behavior:** If this is set to **Owners only**, only the owner can change it. An admin who tries to lower the restriction will find the control disabled with an explanation that their role is not high enough. The owner must relax the policy first.
</Warning>

### Block publishing with critical findings

**Available on:** All plans\
**Default:** Disabled.

When disabled, projects can be published regardless of critical findings, although the publish dialog still surfaces them as security warnings.

When enabled, a project cannot be published if its most recent security scan returned critical-severity findings. The publish action is blocked until error-level findings are resolved.

We recommend enabling this on every workspace. See [Security overview](/features/security) for more information.

### Block publishing with PII

**Available on:** Enterprise (only visible when [Sensitive data scanning](#sensitive-data-scanning) is enabled)\
**Default:** Disabled

When disabled, personally identifiable information (PII) findings do not block publishing.

When enabled, a project cannot be published or updated if it has unresolved sensitive data findings.

### Require basic security scan before first publish

**Available on:** All plans\
**Default:** Disabled

When disabled, no scan is required before the first publish.

When enabled, every project must complete a basic security scan before it can be published for the first time. Re-publishing an already-published project is unaffected.

This pairs well with **Block publishing with critical findings**. Requiring a scan before publishing ensures a baseline review happens, and blocking publishing with critical findings ensures bad results stop the deploy.

### App login methods

**Available on:** Business and Enterprise\
**Default:** All methods allowed

Controls which sign-in methods are available for apps published by workspace members. Disabled methods are enforced across all projects in the workspace, and project owners cannot re-enable them.

Click **Configure** to open the dialog. Supported sign-in methods include:

* Email
* Phone SMS
* Google
* Apple
* SAML SSO

Use the toggle next to each method to enable or disable it. Changes take effect immediately.

<Note>
  This only affects how end-users sign in to published apps. It does not change how workspace members sign in to Lovable itself.
</Note>

## Security automation

Controls automatic security remediation for projects across the workspace.

### Auto-fix security issues

**Available on:** All plans\
**Default:** Selected project (disabled)

Lovable can automatically fix eligible security findings during regular agent work. When auto-fix is enabled, Lovable gets the latest critical Basic scan findings as part of its context whenever a member chats with it on a project. Lovable then attempts to resolve them as part of the next response. This counts as standard chat usage and consumes credits.

Auto-fix is designed for findings that are safe to remediate automatically, such as common row-level security (RLS) misconfigurations and database access patterns. It does not apply fixes for Deep scan findings.

This setting controls the default scope at which auto-fix is applied across the workspace.

| **Option**                                              | **What it means**                                                                                                                                                                                                                                                                            |
| :------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Selected project (default)                              | Auto-fix is disabled by default. You can enable or disable it for individual projects from **Project settings → Auto-fix security issues**.                                                                                                                                                  |
| Externally published projects (Business and Enterprise) | Auto-fix runs automatically only after the project is published externally. After that, it runs each time you chat with Lovable on the project. You cannot disable it for externally published projects at the project level. You can still enable it manually for other projects.           |
| All published projects                                  | Auto-fix runs automatically only after the project is published, internally or externally. After that, it runs each time you chat with Lovable on the project. You cannot disable it for published projects at the project level. You can still enable it manually for unpublished projects. |
| All projects                                            | Auto-fix runs automatically each time you chat with Lovable on any project in the workspace, whether or not it has been published. It cannot be disabled at the project level.                                                                                                               |

Anyone with project edit access can manage auto-fix for a specific project from **Project settings → Auto-fix security issues**, unless the workspace requires auto-fix for that project.

See [Security overview](/features/security) for more information.

## Sharing

Controls whether members can create public preview links and reuse work across projects in the same workspace.

### Allow public preview links sharing

**Available on:** All plans; disabling is available on Enterprise\
**Default:** Enabled

When enabled, workspace members can generate a temporary public preview link for any project. Preview links are view-only URLs that anyone can open without a Lovable account. Preview links expire after 7 days.

When disabled, the **Share preview** button is hidden for all projects in the workspace.

<Note>
  Preview links bypass the **Default website access** setting. Even when published projects are workspace-only, an enabled preview link lets an external viewer in without authenticating. If you need a hard perimeter against external viewing, disable this setting.
</Note>

See [Share preview links](/features/share-project#share-preview-links) for more information.

### Cross-project sharing

**Available on:** All plans\
**Default:** Enabled

When enabled, workspace members can reference and reuse implementations from other projects in the same workspace. Members can reference a project by typing `@` in the chat or by asking Lovable to use an existing project. All cross-project access is read-only. Referenced projects cannot be modified.

When disabled, cross-project sharing is turned off for all projects in the workspace. Members cannot reference other projects and other projects cannot reference them.

<Note>
  Cross-project sharing can also be controlled at the project level. Project editors and above can disable it for a specific project from **Project settings → Cross-project sharing**. When disabled at the project level, that project cannot reference others and cannot be referenced. If any level blocks access, the reference fails.
</Note>

See [Cross-project referencing](/features/cross-project-referencing) for more information.

## Lovable MCP server

Control third-party MCP client access to this workspace.

### Third-party MCP clients

**Available on:** Business and Enterprise\
**Default:** Enabled for Business; Disabled for Enterprise

When enabled, external MCP clients such as Claude Desktop, Cursor, and other IDEs can connect to this workspace through [mcp.lovable.dev](http://mcp.lovable.dev). This allows developers to build and manage their Lovable projects directly from their preferred tools using the MCP protocol.

On Free and Pro workspaces, this is always enabled and cannot be configured. On Business workspaces, it is enabled by default and can be turned off. On Enterprise workspaces, it is disabled by default and must be explicitly turned on by a workspace admin or owner.

See [Lovable MCP server](/integrations/lovable-mcp-server) for more information.

## MCP connectors

Controls whether members can connect external tools and data sources to Lovable through Model Context Protocol (MCP) servers.

### Remote MCP connectors

**Available on:** Business and Enterprise\
**Default:** Enabled

When enabled, workspace members can connect pre-built and custom MCP servers to their projects. MCP servers let the agent read from external databases, APIs, and other data sources during builds.

When disabled, MCP servers access is turned off across the entire workspace. No new MCP connections can be created.

See [Chat connectors (MCP servers)](/integrations/mcp-servers) for more information.

### **Local desktop MCP servers**

**Available on:** Business and Enterprise\
**Default:** Enabled

<Note>
  This setting has no effect when **Remote MCP connectors** is disabled. Both must be enabled for local desktop MCP servers to work.
</Note>

When enabled, members using the [Lovable Desktop app](/integrations/desktop-app) can connect MCP servers running on their own machine to their projects. This lets the agent reach localhost tools and private services that are not exposed to the internet.

When disabled, only remote MCP connectors are allowed. Local desktop connections are blocked.

## Data protection

Controls training data preferences, sensitive data detection, and storage exposure rules.

### Data collection opt out

**Available on:** Business and Enterprise\
**Default:** Disabled

<Note>
  Free and Pro customers can request an opt-out by contacting [Lovable Support](https://lovable.dev/support).
</Note>

When disabled, customer data may be used for model training and other business purposes as described in Lovable's [Terms of Service](https://lovable.dev/terms). Only customer data that does not identify you may be used.

When enabled, Lovable does not use this workspace's content for AI model training or internal evaluation.

See [Manage training data and privacy](/features/business/data-opt-out) for more information.

### Sensitive data scanning

**Available on:** Enterprise\
**Default:** Disabled

When enabled, Lovable scans workspace content for personally identifiable information (PII). This is the **workspace-level main switch for sensitive data protection features**, including on-demand scans (chat history, Lovable Cloud databases, and Lovable Cloud storage), chat send protection for new messages and attached files, and block publishing with PII findings.

It also adds a **Sensitive data** tab to projects where recorded PII findings can be reviewed.

### Chat send protection

**Available on:** Enterprise (only visible when **Sensitive data scanning** is enabled)\
**Default:** Log only

Determines what happens when PII is detected in new chat messages or attached files.

On-demand scans of chat history, Lovable Cloud Database, or Lovable Cloud Storage still work regardless of the chat send protection mode.

| **Mode**               | **Behavior**                                                                                                                                                                                                                                                                                                                                                                      |
| :--------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Off**                | No scanning. Messages pass through to the agent without inspection or logging.                                                                                                                                                                                                                                                                                                    |
| **Log only** (default) | The scan runs. If PII is detected, a finding is recorded and available for review in the project's **Sensitive data** tab, but the message sends without interruption. This is the default when sensitive data scanning is first enabled.                                                                                                                                         |
| **Ask before sending** | The scan runs. If PII is detected, the message is paused and the user chooses whether to edit, send a redacted version, or send the original. Detected PII is logged only if the user sends the original messages, otherwise the original message is discarded.<br />Can be overridden on project level by enabling **PII prompt auto-approval** from the **Sensitive data** tab. |
| **Block original**     | The scan runs. If PII is detected, the user cannot send the original. They can only edit the message or send a redacted version. The original message is discarded and nothing about the original PII gets logged.                                                                                                                                                                |

### Block public storage buckets

**Available on:** All plans\
**Default:** Enabled

When enabled, workspace members cannot create publicly accessible storage buckets in Lovable Cloud. All new buckets are forced to private access.

When disabled, members can create public storage buckets.