Security
at Mozaic.
Your workspace is hosted in the European Union. Here’s how Mozaic protects access to it, what you control, and what to know about the public beta.
Report a vulnerabilityHosted close to home.
Mozaic is built and operated in the European Union. Keeping your workspace close to home is part of how we run the service.
- EU infrastructure and data
- The core service and your workspace data are hosted in EU data centres.
- European services first
- We choose EU providers and EU regions for supporting services wherever available.
Mozaic is in public beta. Read how backups and recovery work.
Secure your sign-in.
Choose who can do what.
Your account identifies you. Your organization’s permissions determine which work you can see and which actions you can take.
- Extra protection for your account
- Mozaic supports passkeys and hardware security keys, authenticator apps using TOTP, and single-use recovery codes. Sensitive account and organization actions ask you to verify again when your last check is too old.
- Access for the right people
- Organization owners and authorized managers assign roles at organization, team, or resource scope. Signing in does not give someone access to every organization. Invitations are tied to an email address, expire, and can be used once.
- Company-managed sign-in
- Organizations can configure OpenID Connect providers, including a specific Microsoft Entra tenant. Company identities belong to one organization and have no independent Mozaic password. Administrators select enrollment, mapped access, provider revalidation and MFA requirements for individual actions. Recovery codes never bypass company sign-in or revoked provider access.
- Contributors stay external
- A person using a personal Mozaic account can propose a change to a public project without becoming a member of your organization or gaining access to its private work.
Open Account → Security, add a passkey or authenticator, and save your recovery codes somewhere outside Mozaic.
Secure your account Manage organization accessDecide what becomes public.
New resources start non-public. Sharing them with the internet requires a separate, authorized publication action.
- A public project has limits
- Publishing an organization or project does not automatically publish every resource inside it. Repositories, pages, and other content keep their own visibility settings. A private organization or project blocks public access to the resources beneath it.
- Saved does not mean published
- Knowledge pages have separate working and published versions. Public readers see the version you chose to publish, while your team can continue editing the working version.
- Team conversations belong to the organization
- Chat is governed by organization access and content policies. It is not end-to-end encrypted; do not treat it as a private vault for credentials or secrets.
Review the public-access summary and check the resulting public page. Making content private again stops public access through Mozaic, but cannot recall copies someone already downloaded.
Review the sharing workflowBuilds run with limited access.
Pull-request checks can start automatically when the pipeline enables them, including for external contributions. These runs use restricted access and are tied to the exact code revision and build plan.
- Checks belong to one version
- Changing the code or build plan requires a new execution grant, which Mozaic can create when scheduling the check. Reviews and checks stay attached to the version they evaluated. Protected branches enforce their configured review approvals and check requirements before a merge.
- Builds run separately from the application
- The operated runner starts jobs in rootless containers with limits on CPU, memory, storage, runtime, and network access. Restricted jobs receive no protected secrets, host mounts, privileged execution, or permission to write trusted build caches.
- Publishing needs a separate instruction
- Producing an artifact does not publish it to a package registry. Restricted runs skip package publication by default. A pipeline author can explicitly enable publication for them, so review that setting when configuring your pipeline.
Inspect its triggers, dependencies, network destinations, and package publication settings. A successful build alone does not establish that its code is safe; review proposed changes before merging them.
Understand pull-request checks Check package publicationUnderstand the service’s limits.
Mozaic is a hosted service in public beta. These product controls are not a third-party security certification or a guarantee of availability.
- Changes leave a record
- Security-sensitive actions, including permission and publication changes, are recorded in audit history. Build attempts keep their own results; a retry creates another attempt rather than replacing the previous one.
- Recovery depends on backup configuration
- The beta permits local-only backups. In that mode, total host loss is unrecoverable. Off-server recovery requires the operator to configure remote backups and verify recovery; having a local backup is not enough.
- Beta support is still evolving
- Mozaic does not yet publish a stable support window. Features and service limits can change. Keep independent copies of work you cannot afford to lose.
Found a security problem?
Report suspected vulnerabilities in Mozaic privately. Use the contact button below to reach the operator rather than opening a public issue.
- Describe the affected page, feature, and version or revision if known.
- Include steps to reproduce the issue and explain its impact.
- Remove credentials, personal data, and other people’s secrets from the report.
Enable JavaScript to reveal the email address. If the button does not appear, reload this page or try another browser. The postal contact in our legal notice also uses a reveal button.
This is the contact listed in our legal notice. For a vulnerability in a project hosted on Mozaic, use that project’s private security-report workflow where available.