Trust & Architecture

Security and Document Handling

Last updated: 16 October 2026

Layered protection. MSYN combines encrypted production connections, server-side workspace permissions, protected integration credentials and controlled file access. The controls below describe the application, not an independent audit or a SOC 2, ISO 27001 or other compliance certification. A provider's certification does not certify MSYN.

1. HTTPS and account security

Production API requests require HTTPS. Newly chosen passwords must contain 8-128 characters, at least one uppercase letter (A-Z), one number (0-9) and one special character; line breaks are not allowed. The same rule applies to signup, password resets, temporary-password changes and invitation setup, and is checked by the server as well as the forms. Existing passwords remain usable for sign-in, and Google signup does not require a separate MSYN password. New passwords are hashed with Argon2; existing bcrypt hashes remain supported. Signed access tokens expire within 15 minutes, and refresh tokens rotate on use with reuse detection and session revocation. Production session cookies use Secure and HTTP-only attributes with a configured SameSite policy. Google sign-in tokens are verified on the server, including issuer, audience, expiry, verified email and nonce. Explicit allowed-origin checks protect browser sign-in and session-changing requests. Backend security headers include HSTS, frame restrictions, content-type protection and a restrictive Content Security Policy.

2. File validation and quarantine

MSYN validates filenames, supported extensions, upload sizes and detected file content rather than trusting a browser-supplied file type alone. Supported archive checks restrict unsafe paths, excessive expansion and embedded macro content. Files may be held temporarily on the server for processing. In scan-gated document workflows, a missing, failed or infected scan verdict is not treated as clean, and normal preview or download requires a clean verdict. ClamAV scanning depends on deployment configuration; we do not claim that every upload is actively antivirus-scanned. File validation does not establish a document's accuracy or guarantee that it is free of every threat.

3. Workspace access, private links and audit records

Protected document actions check the active workspace, membership, role permissions and applicable assignment scope on the server. Private collection links use random tokens whose hashes are stored; expiry and revocation controls determine whether a link remains usable. A request link is not necessarily single-use: keep it confidential and revoke it when no longer needed. API rate limits restrict repeated requests, and audit events record supported actions such as previews, downloads, deletions and security failures. Audit records are not presented as immutable or tamper-proof.

4. Storage providers and document delivery

MSYN can introduce additional storage integrations over time. Current storage options are Cloudflare R2 and supported Google Drive collection storage; planned providers are not available until explicitly listed as supported. Cloudflare R2 is the default application storage provider. The backend requires HTTPS for R2 connections and rejects a configured public bucket URL in production. Cloudflare documents AES-256 encryption at rest for R2 objects. MSYN authorizes application previews and downloads before delivery; where R2 signed download links are issued, they expire within five minutes and must be treated as temporary access credentials. Private delivery responses use no-store cache directives. Encryption, retention, location, sharing and recovery arrangements are provider-specific; the R2 and Drive controls described here must not be assumed to apply to a future integration. Server-side encryption is not end-to-end encryption, and no particular storage country, backup schedule or recovery guarantee is implied.

5. Connected accounts and provider-specific controls

Google connections use OAuth 2.0 with PKCE S256, expiring state and browser/session binding. Saved integration credentials are encrypted with AES-256-GCM using 256-bit keys, random nonces and context-bound authentication. Drive storage uses the drive.file scope for app-created or explicitly authorized files, not unrestricted access to every Drive file. MSYN checks workspace ownership markers, private-owner permissions and content checksums for supported stored originals, and refuses mismatched references or changed content. Drive files are delivered through authorized application endpoints rather than public Drive links. Google's encryption and account policies also apply; MSYN does not enable Drive client-side encryption on your behalf. Disconnecting does not erase existing files or automatically revoke access in Google settings.

6. Security questions

To report a security concern or ask about controls relevant to your organization, contact security@msyntech.com or support@msyntech.com. See our Privacy Policy for temporary processing, storage, deletion and external AI disclosures. Do not send passwords, API keys or client documents in a security enquiry.