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 Privacy & security (Settings → Security → Privacy & security).
After changing settings on this page, click Update to apply most changes.
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.
| 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. 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 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.
See Invite by email for more information.
Require two-factor authentication
Available on: Enterprise
Default: Disabled
When enabled, everyone accessing this workspace, including external collaborators, must have two-factor authentication (2FA) set up on their RShift Sites account.
When you enable the toggle, RShift Sites shows a confirmation dialog explaining what members will experience, and the setting takes effect after you update it.
Members who already have 2FA set up see no change. RShift Sites redirects anyone without 2FA to a Set up two-factor authentication page the next time they use the workspace. There, members either set up a method (an authenticator app, a phone number, or both) and continue where they left off, or sign out. Until they enroll, they cannot use the workspace.
Two exemptions apply:
- Active SSO sessions. If a member signed in through your workspace SSO provider, your identity provider is responsible for multi-factor authentication, and RShift Sites does not ask for a second factor again.
- Published websites. Visitors can still view published projects, including projects published only to the workspace. The exception is workspace identity reuse: an app doesn’t receive a member’s identity until that member sets up 2FA.
2FA enrollment is account-level, so a member who enrolled for one workspace satisfies the requirement everywhere. Members manage their own methods in Settings → Your account. See Two-factor authentication (2FA).
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 for more information.
Workspace discovery
Available on: Business and Enterprise
Default: Enabled
When enabled, anyone signing in to RShift Sites 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.
See Workspace access requests and Find your team’s workspace for more information.
Public member profiles
Available on: Enterprise
Default: Disabled (member profiles hidden)
Controls whether members’ public RShift Sites profiles at lovable.dev/@<username> are visible to people outside the workspace.
When disabled (the default for Enterprise workspaces), a member’s profile URL returns a 404 Not Found to anyone outside the workspace. On public project pages, the member’s publisher name, avatar, and profile link are also hidden, and the project shows an anonymous “RShift Sites user” as the publisher instead.
When enabled, member profiles are publicly visible, just like on other plans.
Hiding only applies to people outside the workspace. Workspace members can still see each other’s profiles, and everyone can see their own.
When member profiles are hidden, each member’s Profile visibility setting in Settings → Your account is locked and shows “Profile visibility is managed by one of your workspaces.” See Profile settings.
Editor project transfers
Available on: Enterprise
Default: Disabled
This setting controls whether workspace editors can transfer or remix projects they own into another workspace. Remixing within the same workspace is not affected by this setting.
Regardless of this setting:
- Workspace owners can always transfer or remix any project in the workspace, including restricted projects.
- Workspace admins can always transfer or remix workspace-visible projects.
When disabled, workspace editors cannot transfer or remix projects they own into another workspace.
When enabled, workspace editors can transfer or remix projects they own into another workspace, including a personal workspace outside your organization.
When the Transfer or Remix option is disabled, hover over it to see why. The tooltip explains what is limiting the action.
Require workspace editor role
Available on: Enterprise
Default: Disabled
When enabled, only workspace members with the editor role or higher can edit projects. Workspace viewers and external collaborators can still view projects but cannot edit them, even if they own a project or were given editor access to it directly, through a folder, or through a workspace group.
When disabled, a viewer who is given editor access to a specific project can edit that project.
External project collaborators
Available on: Business and Enterprise
Default: Allow all
Controls whether people outside your workspace can be added as collaborators on projects in this workspace, and the highest access level they can have. This setting is available whether or not you enforce SSO.
| Option | What it means |
|---|---|
| Allow all (default) | External users can be added at any project role, including admin. |
| Allow editors and viewers | External users can be added as project viewers or editors. |
| Allow viewers | External users can be added as read-only project viewers. |
| None allowed | 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. |
When you turn on Enforce SSO, RShift Sites 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 project collaborators setting is set to Allow editors and viewers as part of this flow.
If you later change External project collaborators to None allowed, RShift Sites 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 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 for more information.
External invites
Available on: Business and Enterprise
Default: Enabled
Controls whether members can invite people outside the workspace to view internally published projects by email, using the Custom audience in the publish dialog. See Invite people outside your workspace.
When disabled, the email invite option disappears from the publish dialog’s audience picker and no new external invites can be sent. People who were already invited keep their access.
When enabled, the Who can receive external invites setting appears below it to choose who can be invited: anyone, or only addresses on your company’s verified domains.
Who can receive external invites
Available on: Business and Enterprise (only visible when External invites is enabled)
Default: Anyone
Restricts external invites to email addresses on your company’s verified domains. External means outside the workspace: members can share internally published projects with colleagues elsewhere in your company, but with no one else.
| Option | Who can be invited |
|---|---|
| Anyone (default) | Any email address outside the workspace |
| Verified-domain emails only | Addresses on your company’s verified domains |
Verified domains are the domains your company has proven it owns. This setting cannot allowlist another company’s domain: to invite people at other companies, keep it set to Anyone.
With Verified-domain emails only selected, other addresses can’t be added, and the publish dialog shows Only verified-domain emails can be invited. People who were already invited keep their access.
If no domain is verified yet, this option blocks every external invite. Verify a domain first under Identity (Settings → Access → Identity → Verified domains).
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 |
Block publishing with critical issues
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 for more information.
Block publishing with PII
Available on: Enterprise (only visible when 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.
See Sensitive data scanning for more information.
App login methods
Available on: Business and Enterprise
Default: All methods allowed
Controls which login methods apps built in this workspace may use. Blocked methods are locked for all projects in the workspace, and project owners cannot re-enable them.
Click Configure to open the dialog. Supported sign-in methods include:
- Phone
- Apple
- Microsoft
- SAML SSO
- RShift Sites workspace identity
Use the toggle next to each method to allow or block it. Changes take effect immediately.
Security automation
Controls automatic security remediation for projects across the workspace.
Auto-fix security issues
Available on: All plans
Default: Selected project (disabled)
RShift Sites can automatically fix eligible security findings during regular agent work. When auto-fix is enabled, RShift Sites gets the latest critical Basic scan findings as part of its context whenever a member chats with it on a project. RShift Sites then attempts to resolve them as part of the next response. This counts as standard build 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 send a message in the project chat. 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 send a message in the project chat. 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 send a message in the project chat of 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 for more information.
Abandoned projects
Available on: Enterprise
Default: Marked abandoned after 60 days; auto-delete off
Automatically identify projects with no recent activity, published and unpublished, and optionally delete them after a grace period. Configure both controls from Privacy & security (Settings → Security → Privacy & security → Abandoned projects).
What counts as activity
A project is marked abandoned when it has had no activity for the period set in Mark as abandoned after. Activity means any of:
- someone working in the editor (editing or chatting with the AI)
- a visitor using the published app (bots excluded)
- a backend function call
Simply opening or previewing a project is not activity, and publishing on its own does not reset the clock. One of the signals above must occur.
Deleting abandoned projects
When auto-delete is on (Delete abandoned projects after), an abandoned project is deleted once the grace period you choose (7, 14, or 30 days) passes. Owners and members with edit access get a warning email and an in-project banner 5 days and 1 day before the deletion date.
Before the deadline you can cancel the deletion at any time by:
- editing the project, or sending it a message, or
- clicking Keep it on the in-project banner or in the warning email.
Sharing
Controls whether members can create public preview links and reuse work across projects in the same workspace.
Preview link sharing
Available on: All plans; disabling is available on Enterprise
Default: Enabled
When enabled, members with project edit access can create view-only preview links that anyone can open without a RShift Sites account. On all plans, each link can allow or disallow guest comments.
On Free and Pro plans, preview links expire after 7 days. On Business and Enterprise plans, each link can require a password and set an expiration of 24 hours, 7 days, 30 days, or never.
When disabled, the Share preview button is hidden for all projects in the workspace.
See Share preview links for more information.
Code downloads
Available on: Enterprise
Default: Enabled
Controls whether workspace members and collaborators can download project source code from RShift Sites.
When enabled, members with edit access can download a project’s source code as a zip file.
When disabled, only workspace admins and owners can download project source code as a zip file. Other members have the download option disabled and see a message that only workspace admins and owners can download the code.
This setting only applies to zip downloads from RShift Sites. It does not affect access to connected Git repositories, or the ability to view code in the editor.
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 project chat or by asking RShift Sites 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.
See Cross-project referencing for more information.
RShift Sites 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 and Cursor can connect to this workspace through mcp.lovable.dev. This allows developers to build and manage their RShift Sites 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.
Connection details and client setup steps live in the MCP server tab (Settings → Build & deploy → MCP server), which links back to this setting through its Manage access button.
See RShift Sites MCP server for more information.
MCP connectors
Controls whether members can connect external tools and data sources to RShift Sites through Model Context Protocol (MCP) servers.
Remote MCP connectors
Available on: All plans
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) for more information.
Local desktop MCP servers
Available on: All plans
Default: Enabled (disabled on Enterprise workspaces)
When enabled, members using the RShift Sites 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.
See RShift Sites desktop app for more information.
Data protection
Controls sensitive data detection and storage exposure rules.
Sensitive data scanning
Available on: Enterprise
Default: Disabled
When enabled, RShift Sites 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, built-in databases, and 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.
See Sensitive data scanning for more information.
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, the built-in database, or 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 message, otherwise the original message is discarded. 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. |
See Sensitive data scanning for more information.
Block public storage buckets
Available on: All plans
Default: Enabled
When enabled, workspace members cannot create publicly accessible storage buckets in the built-in storage. All new buckets are forced to private access.
When disabled, members can create public storage buckets.
See Storage for more information on public and private buckets.
Default hosting region
Available on: Business and Enterprise
Default: Not set
Sets the default data region for every new project created in the workspace with the built-in backend (Cloud). Use it when your organization requires the backends to live in a specific geography.
Choose one of the following regions:
| Region | Geography |
|---|---|
| Americas | North and South America |
| Europe | Europe, Middle East, and Africa |
| Asia Pacific | Asia Pacific |
Within a region, RShift Sites automatically distributes new projects across available data centers.
When a default hosting region is set:
- It applies only to new projects created after you update the setting.
- Existing projects keep the region they were created in and are not migrated.
- Workspace members cannot override the default region when creating a new project.
To remove the default region, open the dropdown and select Not set. New projects then use the region closest to the member who creates them.
See Region selection for more information on how regions work.