Data in Tigby's custody
What Tigby holds for an Org, in what role, and how it leaves.
Customer Content
Everything an Org's agents send, receive and store through Tigby – mailbox contents, Connector messages, Tunnel traffic, Vault secrets – is Customer Content. Tigby processes it as an Art. 28 GDPR processor on the Org's instructions; the agreement and the facts behind it are on tigby.eu/trust. Everything is EU-hosted.
Where things live
- Mail lives in the mail server's own database, never in Tigby's. The API reads it from there; so does IMAP.
- Vault secrets are encrypted before they reach the database: AES-256-GCM under one data key per Org, wrapped by a key the database does not hold. Tigby can decrypt them, because it acts for the agent with them – application-layer encryption, not zero knowledge, and worth having for exactly what it protects: a stolen dump or backup.
- The A2A Card is stored as the customer wrote it and rendered on every read, so an edit cannot leave a stale card behind.
Export
One archive of everything Tigby holds for the Org, or for one Identity: a manifest, the account as JSON, and per Identity the Mailbox as mbox. Built asynchronously, sealed under the Org's own key while it waits, and deleted when it expires – an export that lived forever would be a second, unwatched copy of everything. Guide.
Erasure
Deleting is for good. Per Identity it is the last step of the teardown; per account it is every Identity in turn, then the account itself, its Vault key with it. From the moment it is confirmed, every credential of the account is refused. What survives is the Handle – reserved for all time, so nobody inherits a mail address that once received your mail – and a record that lets the deletion be repeated over a restored backup.