Security Overview

• Every workspace is addressed by its own hostname, resolved on the server before any data access occurs.
• The environment is part of tenant identity, so a development workspace and a production workspace are distinct organisations holding distinct data — matching on name alone cannot cross that boundary.
• Every data query is scoped to a single organisation.
• An unknown, misspelled or deactivated tenant resolves to nothing at all. There is deliberately no fallback to a default organisation, because that fallback is how cross-tenant exposure happens.

• Authentication is email and password. Passwords are stored as salted hashes and never in plain text.
• Sessions are established and validated server-side.
• Authorisation is a role-and-permission matrix enforced on the server for every route — not by hiding user-interface elements.
• Approval authority, rate-card visibility, export rights and administrative configuration are separately grantable, so no single role has to be over-privileged to get its job done.
• Read-only roles exist for reviewers and auditors.
• Integration access uses named API keys that an administrator can label and revoke, with calls attributed in the audit trail.

Creates, edits, stage moves, approvals, rejections, exports and AI actions are written to a per-record audit trail capturing the actor, the timestamp and the prior value. Approval comments are retained with the decision. The trail is designed to be handed to an auditor as evidence, which is why it is append-only in practice rather than editable.

• Managed Postgres in the Asia-Pacific (Tokyo) region, with serverless compute pinned to the same region.
• All traffic to the platform is over TLS.
• Data at rest is encrypted by the managed database and object-storage providers.
• Automated backups with point-in-time recovery, operated by the database provider.
• Secrets and provider credentials are held in environment configuration or in a configuration table, never in source control.
• Uploaded files are stored in a dedicated object-storage bucket, referenced by short URLs rather than embedded payloads.

• TypeScript in strict mode, with a type check gating every deployment.
• Input validated and sanitised at the API boundary; permission checks server-side on every route.
• Schema changes are additive and idempotent by policy, so a migration cannot destroy data it was not asked to.
• Deployments are immutable and versioned, with the ability to roll forward quickly.
• Configuration that must change without a release lives in configuration, so urgent changes do not require a code deployment.

We keep the infrastructure surface deliberately small. The current sub-processor list, with the role and region of each, is published at /sub-processors.

Send security reports to security@manzilone.com. See the Acceptable Use Policy for our responsible-disclosure position. We will acknowledge a credible report, keep you informed while we remediate, and notify affected customers of a security incident without undue delay and in line with our contractual and legal obligations.