DOC · MW-SECURITY SHEET 1 OF 1 REV. 2026.06 69.6492°N 18.9553°E

Trust

Security.

How we protect the managed cloud, what stays in your control when you self-host, and how to report a vulnerability.

1. Our approach

Security is a shared responsibility. For the managed cloud, we aim to apply defense-in-depth and least privilege. For self-hosted installs, you control the environment and the data — we provide guidance and secure defaults.

2. Infrastructure

The managed cloud runs on established cloud infrastructure ([Cloud Provider]) in [regions], using their physical and environmental controls. We isolate environments and limit production access.

3. Encryption

Data is encrypted in transit using TLS. Stored data is encrypted at rest where supported by our infrastructure. API keys are treated as secrets and carry a greppable mpw_pk_ prefix so leaked keys are easy to detect and revoke.

4. Access control

Production access is limited to authorized personnel on a least-privilege basis, using unique credentials and multi-factor authentication for administrative access. Access is reviewed periodically.

5. Network security

We use network segmentation, firewalls and restricted management interfaces. Public endpoints are limited to what the Service requires, and the control plane can be restricted to specific hosts.

6. Monitoring & logging

We maintain audit logs and monitoring for security-relevant events to help detect and investigate issues. Operational logs are retained for a limited period (see the Privacy Policy).

7. Vulnerability management

We track dependencies and apply security updates on a risk-prioritized basis, and we welcome reports through our disclosure process below.

8. Secure development

Changes go through version control, review and testing. The codebase is typed and covered by an automated test suite, and we manage dependencies and changes through a controlled pipeline.

9. Resilience & backups

For the managed cloud we maintain backups and recovery procedures appropriate to the Service. Self-hosters control their own backups — see our deployment docs for guidance.

10. Sub-processors

We use a limited set of vetted sub-processors, listed in our DPA (Annex III), bound by contract to appropriate protections.

11. Self-hosted security

When you self-host, your data stays on your infrastructure and we receive no telemetry by default. You control network exposure, TLS termination, backups, and access. We help by shipping sensible defaults: signed httpOnly session cookies, scoped API keys with origin allowlists, rate limiting, host-gating for the control plane, and a /metrics endpoint for monitoring.

12. Compliance

We align our practices with widely recognized security principles. Formal third-party attestations or certifications (e.g. SOC 2, ISO 27001) are not yet held — we’ll state our current status here rather than imply certifications we don’t have.

13. Responsible disclosure

We welcome good-faith security research. If you believe you’ve found a vulnerability, email security@mapwright.io with details and steps to reproduce. Please:

  • give us reasonable time to investigate and remediate before disclosure;
  • avoid privacy violations, data destruction, and service disruption while testing;
  • only test against your own accounts or instances.

We will not pursue legal action for good-faith research that follows this policy, and we’ll acknowledge reports we receive.

14. Contact

Security: security@mapwright.io. Privacy: privacy@mapwright.io.