Is it safe to give an AI assistant access to my email?

Email access is a consequential trust decision because an inbox is not one dataset. It contains identities, private conversations, contracts, financial documents, credentials sent by other people, calendar history and clues about almost every active relationship. An assistant cannot manage that work without reading enough to understand it, yet broad reading creates exposure even if the product never sends a message. The right question is therefore not whether “AI is safe.” It is whether one named service, connected with one defined scope, operating under one set of contracts and controls, is proportionate for one mailbox. This guide turns that decision into an evidence-based review. It also states the present product boundary: adopted policies describe the required destination, while several release-blocking controls still need implementation or first-hand verification before a public safety claim is justified.

What exactly does an AI email assistant get access to?

Begin with the provider consent screen and technical scope, because a feature name does not reveal the data or authority granted. Reading, sending, calendar access and offline access are distinct permissions.

The current Google connection requests Gmail read-only, Gmail send, Calendar read-only and Calendar events access, plus basic identity. Read-only Gmail access prevents mailbox modification through that scope, but it still permits reading sensitive message content. Gmail send allows the application to send as the connected user. Calendar event access permits event changes. Offline access produces a refresh token so the service can operate while the user is away.

That may be a justified bundle for an assistant expected to read work, prepare replies and coordinate meetings. It is not the narrowest possible scope for a product used only to draft text. Google recommends requesting the smallest necessary scope and, where practical, incremental authorisation. A buyer should therefore ask which feature requires each scope and whether unavailable features can remain disconnected. IMAP is different: it uses mailbox credentials or an app password and the server's folder permissions rather than Google OAuth scopes.

How should credentials and email content be protected?

Credentials must be separated from model context, encrypted and usable only through server-side provider gateways; message content needs tenant isolation and a documented lifecycle. Encryption alone does not establish safe handling.

The current code encrypts Google refresh tokens and IMAP app passwords with AES-256-GCM using a key supplied through the deployment environment. Tokens are stored as encrypted values and decrypted server-side when a connector call needs them. The model receives email content needed for reasoning, but not raw credentials. Per-user document paths and server-side authenticated routes provide an important isolation pattern. Training, processing and storage are separate questions, so a no-training term does not remove these controls.

However, the adopted security policy promises more than a source review can prove. It requires Firestore Security Rules and automated isolation tests, immutable audit coverage, least-tool exposure, monitoring and break-glass access controls. The same policy lists several of those as open actions. Those items must be completed or accurately qualified before publication. A serious buyer should ask where primary data resides, where model processing occurs, who can access production content, whether support access is logged and which subprocessors receive which categories.

Which actions should require my approval?

The assistant should distinguish reversible internal preparation from actions that affect another person, move money, destroy records or create a binding business consequence. Permission to use an API is not permission to make every available call.

The current action model creates and edits email drafts internally, then stages sending for an explicit user confirmation. Calendar changes involving other people are also proposed for confirmation; private diary entries explicitly requested by the user may be added directly after a conflict check. Permanent deletion of contacts, files, folders, lists and workspaces requires a separate confirmation.

This boundary is stronger than a general instruction to “be careful” because code and tool definitions determine which operation is available. It still needs adversarial tests across every surface. The complete email rule is explained in whether an AI assistant will send without asking. Approval cards should show recipients, Cc/Bcc, subject, material attachment names and the action's effect. A vague “Continue?” prompt transfers risk to a user without giving them a real decision.

How do revocation, retention and deletion differ?

Revocation stops future source access, retention governs copied data, and deletion removes stored content; a trustworthy service treats them as three separate controls. One disconnect button cannot silently stand for all three.

The adopted privacy policy says channel disconnection stops future access and deletes stored tokens, transient original attachments are removed after 30 days, live personal data is deleted within 30 days of an account request, and backups rotate within 90 days. It also says extracted text and derived records may remain after the transient attachment disappears, unless the applicable deletion lifecycle removes them.

The repository supports local token deletion for Google and credential-record deletion for IMAP. The Google provider-revocation path needs correction or proof: the current disconnect function attempts to obtain a token from a redacted connection object, so the local encrypted record is deleted but provider-side revocation cannot be assumed from code review. No self-service account export or full-account deletion route is visible in the current app, and the storage lifecycle configuration is not present in this repository. These are publication blockers, not footnotes. Until resolved, users should also know how to revoke the app from their provider account.

Can hidden instructions inside an email change what the assistant does?

Inbound messages and attachments must be treated as evidence, never authority, because a sender should not be able to issue commands to software operating for the recipient. This requires architectural controls plus hostile testing.

The classification prompt explicitly labels communication as data and says to ignore instructions embedded inside it. The open-email surface separately identifies the user's typed request as the instruction. Outward email and shared-calendar actions pass through confirmation gates even if a model proposes them. Those are useful layers, but text hierarchy alone is not a complete injection defence.

The current interactive agent can reason over email context while many internal tools are available. The adopted policy's promises of least-tool exposure and an explicit release-suite injection test are not yet evidenced in the repository. Before publication, a red team should place malicious instructions in message bodies, quoted replies, filenames, PDFs and calendar descriptions, then verify that they cannot retrieve unrelated records, alter permissions, create destructive actions or smuggle data into a draft. The detailed test is covered in hidden-instruction and prompt-injection safety.

What audit evidence should exist after an action?

A material action should be reconstructable from source through interpretation, authority, approval, provider result and correction. A chat transcript or a “sent” badge is not a complete audit trail.

Useful records answer: which source message or user instruction initiated the work; which account and tool acted; what exact values were proposed; what the user approved; which provider request succeeded or failed; and whether a retry duplicated anything. Email drafts currently retain recipients, subject, source identifiers, attachments, status and sent time. Observations and derived items also use per-user identifiers and source references.

The adopted information-security policy calls for an immutable audit trail across ingestion, decisions, actions, approvals, undo and access. No complete immutable audit subsystem or user-facing audit viewer is evident in the present source tree. Public copy must not collapse traceability intentions, scattered records and a tamper-resistant audit log into one claim. The proof test should reconstruct a sent email, a failed send, a shared-calendar change, a corrected record and a denied destructive action without relying on developer memory.

Who it is not for

An AI email assistant is not appropriate when the provider cannot satisfy the organisation's confidentiality, regulatory, residency, access-control or evidentiary requirements. Convenience does not override professional duties.

A firm subject to legal holds, strict client barriers, health-data rules, defence restrictions or mandated local hosting may need a controlled enterprise platform or no mailbox-connected AI at all. Shared mailboxes and delegated accounts require clearer identity and audit controls than a personal inbox. A low-volume inbox may not justify the added processor and credential surface. The same is true when no one owns vendor review, rights requests or incident response.

Start with the smallest non-production dataset. If the service cannot produce an accurate data map, contract, subprocessor list, revocation result and deletion route, do not compensate by trusting the interface. Safety is a system property established by design, configuration, operation and fit with the user's obligations.

Conclusion: is AI access to email safe enough?

AI email access can be proportionate when the work removed justifies a tightly governed connection. The decisive evidence is specific: limited scopes; encrypted credentials outside model context; tenant isolation; inbound content treated as untrusted; meaningful approval for outward actions; verified provider revocation; defined retention and deletion; current subprocessors; and an audit trail that reconstructs failure as well as success. The current Hank architecture contains useful foundations, including encrypted connector credentials, source-linked records and explicit send approval, but adopted policy also identifies unfinished controls. Those gaps must be closed and tested before this page can become a public safety assertion. Buyers should use the same standard for every vendor: connect synthetic data first, attack the boundaries deliberately and trust only what the product, contract and retained evidence jointly prove.