Canonity Logo Canonity
  • Features
  • Technology
  • Blog
  • Careers
  • it Italiano en English fr Français de Deutsch es Español
  • Login

How at-rest encryption works on Canonity

26/05/2026

The algorithm

AES-256-GCM (Advanced Encryption Standard, 256-bit block, Galois/Counter Mode) is one of the strongest authenticated symmetric algorithms available: in addition to encryption, it guarantees through a 128-bit authentication tag that the file has not been tampered with or moved.

Key length

256 bits (32 bytes) for the master key and for every derived key.

Chat / execution / result data

Each file is encrypted with a dedicated key, produced via HKDF-SHA256 (RFC 5869) from:

  • a 256-bit master key stored on the backend,
  • your user identifier (UUID v4),
  • the relative path of the file inside the storage space.

Practical consequence: two different files, even belonging to the same user, are encrypted with two different keys. If for any malfunction the system attempted to read a file that does not belong to whoever is making the request and to the tool/chat they are currently viewing/using, decryption would fail because the correct key could not be derived: the consequence is that no content would ever be exposed.

Authenticated Associated Data (AAD)

Every file includes the user identifier and the path in its GCM tag, cryptographically binding the content to its context. Moving a file from one folder to another would automatically render the file unreadable.

Master key custody

The master key resides exclusively on the backend infrastructure, separated from the application servers that serve the website. It is requested server-to-server only when needed, with authentication via a shared key, and it never transits through the user's browser nor is it ever exposed to JavaScript.

Key versioning

The encrypted file format includes a key version identifier (key_id), which will allow us to rotate the master key without requiring an immediate re-encryption of the entire history.

Physical deletion

Every deletion operation translates into a physical removal of the file from the filesystem (POSIX unlink). We do not keep trash bins, application snapshots, or shadow copies. Deletion is permanent and irreversible: neither the user nor Canonity can recover a file after it has been deleted. We recommend downloading locally any content you wish to preserve before deleting it.

Canonity

We put AI to work. For everyone.

Product

  • Features
  • Technology
  • Pricing
  • Roadmap
  • Data security

Resources

  • Blog
  • Documentation
  • Tutorials
  • Compare LLMs

Company

  • About us
  • Careers
  • Contact
  • Privacy
  • Terms of Service
  • Cookies

Canonity © 2025-2026 Canonity SRL. All rights reserved. Patent pending

Privacy Policy | Terms of Service | Cookie Policy | Settings

Encryption of your results

All personal content you create on Canonity — chats, workflow executions, uploaded files, usage statistics — is encrypted at rest on our servers with AES-256-GCM, the cryptographic standard used by governments, banks and end-to-end messaging services.

For every single file we generate a unique key, derived from your personal profile and the file location. The HKDF-SHA256 algorithm encrypts different files — even if they are all yours — with two different keys, and no other user can decrypt them.

Permanent deletion

When you delete an execution, a chat or an uploaded file, the corresponding data is physically removed from our servers. There is no trash bin, no grace period, no hidden copies. Once deleted, the files are lost forever — neither you nor Canonity can recover them.

Always save locally any content you wish to preserve before deleting it.

Learn more →
We use cookies

This site uses necessary technical cookies and, with your consent, analytics cookies to improve your experience.

Privacy Policy | Cookie Policy

Cookie settings

required

Essential for the site to function. They cannot be disabled.

Help us understand how you use the site to improve your experience.