Mandraki Security Architecture Overview

Note: This article describes Mandraki’s architecture and design. Some features discussed are being rolled out progressively and may not yet be available in all plans.

Security architecture is not a feature list. It is the set of structural decisions that determine how a system behaves when things go wrong — when an attacker gains access, when a government issues a subpoena, when an employee makes a mistake, when a hard drive is stolen. This post provides a comprehensive overview of Mandraki’s security architecture, including the principles that guide our design, the cryptographic systems we employ, and the operational controls that tie everything together.

Design principles

Four principles underpin every security decision in Mandraki.

Defence in depth. No single control should be the difference between security and compromise. Encryption at rest, encryption in transit, end-to-end encryption, access controls, audit logging, and network segmentation work in concert. A failure in one layer should be contained by the others.

Least privilege. Users, services, and infrastructure components have the minimum access required for their function. The database server is not accessible from the public internet. The SFU handles media but does not have access to the application database. API endpoints require authentication and organisation-level authorisation.

Transparency. Security claims should be verifiable. We document our encryption formats, key management practices, and protocol choices in technical detail. We do not rely on obscurity.

Sovereignty by design. Every component — infrastructure, application, corporate entity — falls within EU jurisdiction. This is not a deployment configuration; it is a structural property of the system.

The three-layer encryption hierarchy

Mandraki uses envelope encryption with three layers, a pattern commonly used by cloud providers and financial institutions for its balance of security, performance, and key management flexibility.

Layer 1: Master Key. The root of the key hierarchy. In standard deployments, this is a 256-bit AES key derived from the MASTER_KEY environment variable. In BYOK deployments, this is replaced by the customer’s key material (AWS KMS ARN, Azure Key Vault reference, or manually imported key). The Master Key never encrypts data directly — it wraps Organisation Keys.

Layer 2: Organisation Keys. One per organisation. Each Org Key is a 256-bit AES key generated by Mandraki and stored in the database wrapped (encrypted) by the Master Key. To use an Org Key, it is unwrapped in memory, cached in an LRU cache with a five-minute TTL, and discarded after use. Unwrapped keys are never written to disk or stored in Redis. Org Keys wrap Data Encryption Keys.

Layer 3: Data Encryption Keys (DEKs). Multiple per organisation, one per purpose: messages, files, recordings, transcripts. Each DEK is wrapped by its organisation’s Org Key. DEKs perform the actual data encryption using AES-256-GCM. The encrypted output format is [version:1B][iv:12B][authTag:16B][ciphertext], packed into a single binary field.

This hierarchy allows efficient key rotation. Rotating an Org Key requires re-wrapping the DEKs (a key-wrapping operation) but not re-encrypting all the underlying data. Rotating a DEK means new data uses the new key while old data remains readable through the retained previous DEK (marked as ROTATED).

End-to-end encryption

The three-layer hierarchy described above is server-side encryption — it protects data at rest on Mandraki’s infrastructure. End-to-end encryption goes further by ensuring the server never sees plaintext.

Messaging (MLS). We use the Messaging Layer Security protocol (RFC 9420) for encrypted messaging. MLS provides forward secrecy and post-compromise security through its TreeKEM key agreement structure. MLS groups map to channels and DM threads. Each device uploads one-time-use key packages that allow asynchronous group operations.

Media (SFrame). Real-time media in calls is encrypted using SFrame (RFC 9605) via the WebRTC Encoded Transform API. Media frames are encrypted after encoding and before packetisation on the sender, and decrypted after reassembly and before decoding on the receiver. The SFU forwards encrypted frames without access to plaintext.

Server-side encryption and E2EE coexist. When E2EE is enabled, data is encrypted end-to-end by clients and also encrypted at rest on the server. The two layers address different threat models: server-side encryption protects against physical infrastructure compromise, while E2EE protects against server compromise.

Authentication and authorisation

Mandraki uses JWT-based authentication with short-lived access tokens (fifteen minutes) and longer-lived refresh tokens (seven days). Access tokens contain the user’s identity, active organisation context, and role.

Authorisation is enforced at multiple levels. Route-level guards validate authentication and check organisation membership. The org-access.guard verifies that the authenticated user is a member of the organisation specified in the request. Role-based guards (OWNER, ADMIN, MEMBER) restrict access to administrative operations.

For multi-organisation users, organisation context is set at login or via the org-switching endpoint. JWT tokens are scoped to a single organisation, so switching organisations issues a new token.

Multi-tenancy and data isolation

Mandraki is a multi-tenant platform where data isolation between organisations is enforced at the application layer. Every database query includes an organisation ID filter. The Prisma ORM’s query patterns ensure that cross-tenant data access is structurally prevented.

Organisation membership is tracked through the OrgMembership table, which records the user-organisation relationship along with the user’s role and primary organisation flag. Domain-verified auto-capture automatically routes new signups to the appropriate organisation based on their email domain.

Audit logging

Security is not just about prevention — it is about detection and accountability. Mandraki maintains audit logs for security-relevant operations: authentication events (login, logout, token refresh, failed attempts), organisation membership changes (joins, leaves, role changes), encryption operations (key generation, rotation, BYOK import, revocation), administrative actions (settings changes, domain verification, federation requests), and call lifecycle events (creation, join, leave, end, recording start and stop).

Audit logs are stored with timestamps, actor identity, action type, and relevant metadata. They are accessible to organisation administrators through the management interface and can be exported for integration with external SIEM systems.

Network architecture

The production infrastructure is segmented by function. The database and Redis servers reside on a private network with no public internet access. Application servers access the data tier through private IP addresses. The SFU has public-facing ports for WebRTC media traffic (UDP 40000-49999) and TURN relay (UDP/TCP 3478, TLS 5349). HTTPS traffic is terminated at the nginx reverse proxy with Let’s Encrypt certificates.

SSH access to servers uses Ed25519 key authentication with no password fallback. The data server is accessible only via jump host from the application servers.

Incident response considerations

Our architecture is designed to support rapid incident response. BYOK organisations can revoke their Master Key to immediately render all data inaccessible. Refresh tokens can be revoked to force re-authentication across all sessions. Organisation membership can be revoked to immediately terminate a user’s access. Federation relationships can be severed to isolate an organisation from external collaborators.

These controls provide the mechanisms that security teams need to respond to compromise scenarios decisively.

Continuous improvement

Security architecture is never finished. We continuously evaluate our design against emerging threats, new cryptographic standards, and evolving regulatory requirements. Our commitment is to maintain transparency about our architecture, honesty about its limitations, and diligence in its improvement.

We welcome questions and feedback from security teams evaluating Mandraki. Understanding our architecture in detail is not just permitted — it is encouraged.