Does the US CLOUD Act reach AMVLET? +
No. The CLOUD Act (18 U.S.C. § 2713) compels US-incorporated entities to produce data on government demand — regardless of where the data is physically stored. AMVLET is not a US company and does not operate on US infrastructure. There is no US legal entity in the data path that a US government order can compel. WhatsApp (Meta), Teams (Microsoft), Zoom, and Slack are all US-incorporated. Every one of them is subject to CLOUD Act compelled disclosure for your organisation's data. AMVLET is not.
Who holds the encryption keys? Can AMVLET read our messages? +
No one at AMVLET can read your messages. Encryption keys are generated on your devices using the Matrix cryptographic stack. On self-hosted and air-gapped deployments, keys never leave your infrastructure at any point. On ON-CLOUD, keys remain on client devices — AMVLET's servers route encrypted ciphertext without holding the ability to decrypt it. There is no key escrow, no master key, and no backdoor at any tier. This is architecturally enforced, not a policy promise.
We operate in Saudi Arabia. Does AMVLET satisfy SAMA and PDPL? +
Yes — by architecture, not by contractual assurance. Saudi Arabia's PDPL (Art. 29) prohibits cross-border transfer of personal data without NDMO authorisation. SAMA's March 2025 circular formally banned WhatsApp for all financial institution customer communications, citing security concerns and PDPL non-compliance. AMVLET deploys on KSA-resident infrastructure with no US cloud dependencies in the data path. When no US company controls the data, CLOUD Act exposure and PDPL cross-border transfer violations are simultaneously eliminated — structurally, not contractually.
WhatsApp has E2EE. Why isn't that sufficient for regulated use? +
WhatsApp's E2EE protects message content in transit between two devices. It does not protect: (1) metadata — who communicates with whom, how often, your contact graph, device identifiers — which Meta holds and which is legally compellable under CLOUD Act; (2) cloud backups to iCloud or Google Drive, which are not E2EE by default and accessible via US government orders to Apple and Google; (3) the structural fact that Meta Platforms, Inc. is a US company subject to compelled disclosure at the infrastructure level. SAMA reached the same conclusion in March 2025 — E2EE claim and data sovereignty are not the same thing.
Is the protocol open? Can our security team audit the full stack? +
Yes. AMVLET is built on the Matrix open standard, maintained by the Matrix.org Foundation. The specification is publicly documented. Synapse Pro, the server component, is open-source and auditable. Client applications are fully inspectable. There is no proprietary black box in the communications layer. This matters for NIS2 Article 21 supply-chain security requirements — documented, auditable evidence of what your communications infrastructure does is something no closed-source proprietary platform can provide to the same standard.
If we end the contract, what happens to our communications data? +
It stays on your infrastructure — because it was always there. On self-hosted and air-gapped deployments, AMVLET holds no copy of your data at any point. On ON-CLOUD, full export is contractually guaranteed and tooled. Because Matrix is an open standard, your message history is readable by any compliant Matrix implementation — there is no proprietary format, no lock-in, and no dependency on AMVLET's continued operation to access your own communications. You own the data permanently, not conditionally.
Our staff use WhatsApp and Teams externally. Do they need to switch apps? +
Not immediately. AMVLET supports bridging via the mautrix stack, letting your sovereign Matrix homeserver communicate with WhatsApp, Teams, Slack, and other networks. Your users operate from a single sovereign client; external contacts stay on their existing platforms. For enterprise migrations we design a phased rollout — internal communications move to Matrix first, with bridges maintaining continuity for external contacts throughout the transition.
What does post-quantum encryption mean and why does it matter now? +
Standard encryption (RSA, elliptic-curve) is broken by sufficiently powerful quantum computers. Post-quantum algorithms are designed to resist that attack. The immediate threat is "harvest now, decrypt later" — adversaries capture encrypted traffic today and hold it until quantum capability is available to decrypt it retrospectively. For defence, intelligence, diplomatic, and high-value financial communications, data classified sensitive today may still be sensitive in ten years. AMVLET implements post-quantum end-to-end encryption (PQ E2EE) so ciphertext harvested today cannot be decrypted with future quantum hardware. This is not a future consideration — it is the threat model that national-security agencies already plan against.