The short version

• Message bodies are never stored. A message is analysed in memory and discarded when the response is sent — not logged, not retained, not used to train anything.
• Screenshots of pages behind links expire. When link inspection is enabled, screenshots live in server memory for thirty minutes, then are gone.
• No student accounts exist. Nobody signs in to ToneGuard and no ToneGuard credential exists to lose or have phished.
• ToneGuard cannot delete mail. It holds a deliberately narrow write grant — enough to prepend a warning and move the original aside, never enough to delete — and only for the mailboxes your administrator enrolled.
• Nothing is installed. There is no add-on, no add-in, no browser extension and no endpoint agent, on either platform. Everything below happens between your mail platform and our server.

What ToneGuard accesses

The scan has standing access to the mailboxes you enrol and reads every inbound message for them, on arrival, without the reader asking. That is its purpose: the warning has to exist before the reader does anything. It is off by default, per mailbox — nothing is scanned until your own administrator grants access in your console and a mailbox is explicitly enrolled.

On Google Workspace the grant is domain-wide delegation of exactly two scopes — gmail.modify and gmail.insert. The full mail scope, https://mail.google.com/, is deliberately never requested, which is why this deployment has no API that can permanently delete mail. On Microsoft 365 your administrator consents one application into your directory (Microsoft Graph Mail.Read, plus Mail.ReadWrite for the banner), and we ask you to add an Exchange Online application access policy so the grant cannot reach a mailbox you never named.

What the banner changes about a message

The warning is placed inside the message body, so the copy in the reader's inbox is not byte-for-byte what the sender transmitted. That deserves a precise account rather than an appeal to common practice:

• Added: a warning block at the top of the message, and headers recording the risk level and which checks fired.
• Never touched: anything the sender wrote. The warning is prepended — nothing is removed, reordered, or rewritten, and attachments are not modified. A signed message is not rewritten at all; those get a label instead, because a signature is a claim about exact bytes.
• Changes incidentally: the edited part is re-encoded, so the sender's original DKIM signature will not validate against our copy. That makes the copy self-evidently not the original transport artefact.
• The original is kept. It is archived — out of the inbox, retained in the mailbox indefinitely. It is not deleted and does not expire, so the two can always be put side by side.
• If you would rather nothing were modified, enrol a mailbox in label mode. The message is left completely untouched and the warning becomes a label. It is a weaker warning, and under strict records obligations it may be the right trade.

ToneGuard's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

What is retained

• From mailboxes: nothing. No bodies, no subjects, no addresses, no verdict history.
• Per institution: a tenant identifier (a directory GUID or a Workspace domain) and its service status.
• The enrolment list: the addresses of the mailboxes your administrator enrolled for the arrival-time scan. That list is the configuration, so it is the one mailbox-derived thing that persists.
• An audit log of authorization decisions — which institution was served or refused, and when, plus the outcome and risk level of each scan and which checks fired, as detector identifiers only. Never message content, never a mailbox address, never a reading history. These identifiers are what your exposure report is built from.
• From signup on this site: the details you type (institution, contact name, work email, tenant identifier, mailbox count) and payment state. Card details never touch our servers — checkout is Stripe's hosted page.

What leaves an institution's tenant

• Message content reaches ToneGuard's analysis server over TLS, is analysed, and is discarded.
• When wording analysis is enabled, the subject, sender and body text reach Anthropic's API, which the institution should treat as a subprocessor relationship. The feature can be left off, in which case no message content reaches any third party — and the reader is told that check did not run.
• When link inspection is enabled, URLs — attacker-authored, not student-authored — are opened in an isolated, single-use machine that holds no credentials and has no route to private networks.
• Nothing else: no contact lists, no directory data, no browsing history.

Service providers we rely on

Fly.io (analysis service hosting), Vercel (this website), Neon (signup database), Stripe (payments), Resend (operational email), and Anthropic (only when wording analysis is enabled, as above).

Control and revocation

The institution's administrator can stop ToneGuard unilaterally, without asking us and without waiting for us. Delete the domain-wide delegation entry in the Google Admin console, or revoke the application's consent in Entra ID, and every enrolled mailbox stops at once — the next token mint fails and nothing further is read or written. Authorization fails closed on every path. Mailboxes can also be un-enrolled one at a time, which stops the scan while leaving the grant in place.

Questions

Write to hello@toneguard.email. Security reviewers can request the full data-handling document, which cites the source file enforcing each claim above.