Security at Marlow

This page is maintained by Marlow to answer common security and privacy questions about the Marlow application. It describes the controls that are in place today and is updated as the product changes.

Security is an ongoing process. As Marlow evolves, this page will be updated to reflect new capabilities and practices.

• In transit: every request to Marlow — the app, the API, and our custom domains — is served over HTTPS with TLS. Certificates are provisioned and renewed automatically by our hosting platform, and HTTP requests are redirected to HTTPS.
• At rest: application data lives in a managed Postgres database and managed object storage provided by our platform, which encrypts stored data at the storage layer. Backups are stored encrypted.
• Passwords: passwords are managed by our authentication provider and are never stored or viewable by Marlow.

Marlow runs on Lovable Cloud, a managed platform that provides hosting, a managed Postgres database, authentication, file storage, and backend functions. We do not operate our own servers, and no production data is stored on personal devices.

• The production database is managed, patched, and monitored by the platform provider.
• Production data is stored in the United States. See Data transfers in our Privacy Policy.
• Marlow is currently in public beta and is operated by its founder using managed cloud infrastructure. We describe what is in place today rather than a larger program than exists.

Every table that holds customer data is protected by row-level security in the database itself, not just in application code. That means a request can only ever return the rows the signed-in user is entitled to — even if a bug existed in the app layer.

• Access is evaluated at two levels: your workspace membership and role, and the per-map permissions granted on an individual map. A map can be shared with someone who is not a member of the workspace that holds it, and that share grants access to that map alone.
• Workspace roles determine who can create content in a workspace and who can administer it; map-level permissions determine whether a specific person can view, comment on, or edit that map. Both are enforced in the database, and changes to either are recorded in the workspace and map activity trails.
• Maps, nodes, comments, questions, and activity are readable only through those two paths — never by simply belonging to the same platform.
• No customer data is readable by unauthenticated visitors, except content deliberately exposed through a guest share link (see Guest share links below).
• Sign-in supports email and password plus Google and Apple sign-in. Sessions are short-lived and refreshed with rotating tokens.
• Access to production systems and customer data is limited and used only when necessary to operate, support, debug, secure, or improve the service.

Marlow lets you share content with someone who has no account — a contractor, an auditor, a colleague in another system — by generating a guest link. These links are deliberately narrow, and they are the one way content can be read without signing in.

• Each link authorizes exactly one scope — a single step, the interactive map, or the read-only Knowledge View — and exactly one capability, view or comment. Scopes never nest, so a step link can never be widened into a map link.
• Link tokens are long and unguessable, and only a hash of the token is stored. The full URL is shown once at creation; we cannot recover it later, and neither can anyone with database access.
• Guests are never user accounts and never workspace members. They do not appear in your directory, cannot browse other maps, and cannot see workspace membership.
• On a comment-enabled link, guest comments are plain text, attributed to the display name the guest types, and clearly marked as guest contributions in the activity trail.
• Map owners can disable, regenerate, or delete a link at any time, which immediately revokes access for anyone still holding the old URL.
• Guest links are excluded from search-engine indexing, and guest access is read-only apart from commenting.

• The production database is backed up automatically every day, with a rolling retention window of approximately 14 days.
• Backups are encrypted at rest and restorable by the platform provider.
• Inside the product, Marlow keeps its own map version history so you can review and restore an earlier version of a map, and it takes an automatic backup snapshot before any restore.
• Because backups exist, data you delete may persist in encrypted backups for up to about 14 days before rolling out of the retention window.

• Automated security review runs against the codebase and database configuration, including checks for missing row-level security, over-permissive policies, and unsafe database function definitions.
• Dependencies are scanned automatically for known vulnerabilities, and we upgrade affected packages when findings are reported.
• Findings are reviewed as part of our normal development work, with critical and high findings taking priority.

• Credentials and API keys are stored in an encrypted secrets manager provided by our platform, not in source code or in the browser bundle.
• Secrets are write-only: once saved, their values cannot be read back out of the interface.
• Secrets are injected only into backend runtimes at execution time and are never exposed to the client.
• Database service-role credentials are managed by the platform and are not retrievable by us or exposed to the application front end.

• Our hosting platform includes automated abuse and traffic-protection measures in front of deployed applications. We do not currently operate a separately configured, dedicated web application firewall; organizations with a specific WAF requirement should contact us.
• Backend function invocations, errors, and database activity are logged and retained for operational troubleshooting.
• Automated project monitoring surfaces runtime errors and suspicious behavior to us so we can investigate.
• Inside the product, workspace and map audit trails record who changed what and when, which gives customers their own record for investigations.

Protecting operational knowledge involves both securing data and helping organizations maintain trustworthy documentation over time.

• Workspace and map permissions: people see and change only what their workspace role and their permissions on an individual map allow, enforced in the database rather than only in the interface, with guest links limited to a single scope and capability.
• Ownership and accountability: nodes and maps carry an owner, so every documented process has a person attached to it rather than belonging to nobody.
• Activity history: workspace and map activity records who changed what and when, including permission and status changes, giving you your own audit trail.
• Version history: maps can be reviewed and restored to an earlier version, and Marlow takes an automatic snapshot before a restore so nothing is lost in the process.
• Validation and review status: maps and nodes carry status — including a review state with an optional reason — so readers can tell confirmed knowledge from something still being worked out.
• Questions and assumptions: uncertainty is captured explicitly instead of being flattened into confident-looking documentation.

We keep our vendor list intentionally small. Current subprocessors that may process customer data on our behalf:

We will update this list before a new subprocessor begins processing customer data. We do not use advertising or data-broker vendors.

Retention is summarized here and described in full in our Privacy Policy.

We investigate all reported security issues as quickly as practical, based on their severity. Critical issues receive our highest priority. If we determine that customer data has been affected, we will notify affected customers and comply with applicable legal notification requirements.

• Reports and automated alerts come to security@makeitmarlow.com and are reviewed directly by Marlow.
• We work through containment, eradication, and recovery, and keep an internal written record of what happened.
• Where a fix or configuration change is needed, it is prioritized ahead of ordinary product work.
• Where notification is required by law, we notify affected customers and the relevant supervisory authorities.

If you believe you've found a security issue in Marlow, email security@makeitmarlow.com with steps to reproduce. Please give us a reasonable window to investigate and fix the issue before publishing details, and we'll work with you on disclosure timing.

Security of the service is a partnership between three parties. Being explicit about which is which avoids the wrong assumption at the wrong moment.

Questions about anything on this page? Email security@makeitmarlow.com.