The keys to
a mailbox.
That is what you are giving Hank. Here is precisely how it is held, in enough detail that you can judge it — including what we have not built yet.
Your mailbox credentials
An IMAP password or a Google refresh token is encrypted before it is stored, with AES-256-GCM. The key is held in Google Secret Manager, never in the codebase and never in the database beside the data it protects.
Credentials are never placed in a model prompt. They are decrypted only inside the server code that opens a connection to your mail provider, and they are never exposed to the assistant, to the browser, or to a log.
Everything else is encrypted at rest by Google Cloud as a matter of course, and in transit over TLS.
Separation between customers
Every read and every write is scoped to your account identifier on the server. A request that reaches for another account's record is refused, not filtered — the check is an ownership test, not a search condition.
Access control, and how we know it holds
Authentication and permission are resolved in a single call, so a route cannot check one without the other. Anything not on an explicit list of always-open reads is denied by default: a new capability is protected before anybody thinks to protect it.
This is verified by the build, not by memory. A check runs on every deployment and fails it outright if any route escapes the gate, if a route authenticates and then ignores the answer, or if an exemption no longer matches anything real. Code that would open a hole does not ship.
What the assistant is not allowed to invent
A detail Hank saves to a client record — an address, an identity number, a bank account — must appear in something you actually provided: your own words, the message being acted on, or the bytes of an attached document. Anything else is discarded before it is written, and Hank tells you which fields it could not fill.
This is enforced in code rather than requested in an instruction. A wrong identity number is a failed verification; a wrong account number is a payment to a stranger.
Nothing leaves without you
Hank drafts into an Outbox that you review. No email is sent, no calendar invite issued and no reply dispatched without your explicit approval. Mail that does go out leaves from your own account, through your own provider — not through a sending service of ours.
Deletion, and what it actually does
Deleting your account removes every stored object, every record, your contacts, your documents, your workspaces and your stored credentials. Your Google access is revoked at Google, so Hank cannot reach your mail again even if our database were restored from a backup tomorrow. Deleting a token is not the same as revoking it, and we do both.
Filed attachments are permanent until you remove them. Everything else Hank captured is purged after 30 days by a storage lifecycle rule whether you ask or not.
What we have not built
Straight answers, because you will ask and because a vague one is worse than a limitation.
- No SOC 2, ISO 27001 or comparable audit. We are young and we have not been audited. When that changes we will say so here with the report date.
- No customer-managed encryption keys. Keys are managed by us in Google Secret Manager.
- No single sign-on or enterprise directory integration yet.
- No penetration test report to share yet.
- Model processing is not pinned to one region. See §5 of the privacy policy. If your professional obligations require a named jurisdiction, speak to us first.
Reporting something
If you find a vulnerability, write to security@digitalhank.com. We will acknowledge within two business days, we will not threaten you, and we will credit you if you would like us to.
If customer data is ever accessed without authorisation, we will tell the people affected and the relevant regulator as soon as we reasonably can. See §7 of the privacy policy.