Security at Lonzo

Lonzo handles some of your most sensitive data — your email, calendar, contacts, and tasks. We designed the system so that protecting that data is a property of the architecture, not just a policy we promise to follow. This page explains, in plain terms, how we do it. It also serves as the technical and organizational measures reference for our Data Processing Addendum (DPA).

What makes Lonzo different

Two things set our design apart from a typical email or calendar assistant:

1. Every account's data is encrypted under its own keys. We use per-actor envelope encryption backed by a hardware security module. One person's data is never encrypted under keys that another person's execution context can reach. One store is an exception to this, and we describe it below rather than let the sentence be read more broadly than it is true: the search index holds short excerpts of your content unencrypted.
2. Cross-account data access is structurally impossible to express. The language our features are written in (Fabric-Starlark) cannot express a read across account boundaries. Isolation is enforced by the execution model itself, not only by access-control configuration.

We are precise about one thing up front: Lonzo is not zero-knowledge and not end-to-end encrypted. To power the assistant, we decrypt your data for specific, bounded, audited purposes — including sending relevant content to our inference provider. We do not claim your data is never seen in plaintext by our systems. What we do claim is that decryption happens only for defined purposes, is logged on our servers, and cannot happen in bulk. Two exceptions to that are stated on this page rather than left for you to discover: one store — the search index that makes your data searchable — holds short excerpts of your content that are not encrypted under your account's key at all, and the Lonzo app's own decryptions on your device are not written to the audit ledger. Both are described below, with what protects that data instead. The rest of this page explains exactly how.

Encryption at rest — per-actor envelope encryption

Each human account (an "actor") has its own data key — an AES-256-GCM key ("ADK") that encrypts that actor's data at rest. Each ADK is in turn wrapped ("enveloped") by a key-encryption key ("KEK") held in AWS Key Management Service, backed by hardware security modules, whose plaintext never exists in our application processes. The KEK is a single managed key bound to each account cryptographically: the account's identity is part of the encryption context that KMS requires to match before it will unwrap that account's data key, so one account's data key cannot be unwrapped in another account's context. We describe this precisely because the distinction matters for deletion: the binding is per-account, but the key itself is not a separate destroyable key per account — see "Deleting your data" below.

Encryption and decryption happen at the Kernel layer of the system. The application logic that implements features never sees plaintext keys or ciphertext — it works only with data the Kernel has already decrypted for a specific, permitted purpose. Because data keys are per-actor and the key-encryption key is HSM-backed and never present in plaintext in our processes, compromising one actor's data does not expose any other actor's data.

The one exception: the search index

To answer a question like "when did I last hear from Dana", the assistant searches your data by meaning, not just by keyword. That requires a search index kept alongside the encrypted store. Each indexed item contributes one row holding three things: a short text excerpt of the item (capped in code — a summary of a few hundred characters at most, not the item itself), the vector embedding computed from that excerpt, and a small map of projected fields used for filtering. Those rows are not encrypted under your account's data key.

This is a deliberate limitation, not a setting we left off. A value encrypted under a per-account key cannot be searched by similarity or filtered by a database query without first decrypting it, so an index that is both encrypted and searchable requires a different mechanism than the one described above (client-side indexing, searchable encryption, or processing inside a hardware enclave). We have not built one. Rather than describe our encryption in words that quietly exclude this store, we state what it does and does not cover:

• Your account is still isolated from every other account. Every index query is restricted to the requesting account's own rows by that account's authenticated identity, and only our own internal services can run a query on an account's behalf — which is what happens when the assistant answers your request. One customer cannot reach another customer's index rows.
• The full item is never in the index. What is stored is the excerpt, the embedding and the projected fields — not a second copy of the message, event, contact, or document. The item itself stays encrypted under your data key in the primary store.
• Field projection is bounded on purpose. Before a row is written, fields whose names indicate a secret — tokens, passwords, credentials, keys — are dropped, and projected text is truncated. Two things about that rule are worth stating plainly rather than leaving you to assume the stronger version. It matches names, against a list of spellings we maintain, so a secret placed in a field whose name gives no sign of it is not caught by this rule; what bounds that case instead is the length cap on every projected value and, for the kinds carrying our assistant's own reasoning about your data, a per-type declaration of exactly which fields may leave the encrypted store. And the drop happens at the write, on every field regardless of which code path produced it — until 2026-08-18 it ran on only one of the three paths, and the list of spellings covered key material by two of its names rather than by all of them. Both are now checked automatically: an automated check fails our build if a field named for any of the four categories above survives the projection, on any path, or if the list stops covering a category this page names.
• What encryption does not protect here. Someone with direct access to the index database could read those excerpts, across accounts, without any decryption — which also means without an entry in the decryption ledger described below. In this one store, what stands between an over-privileged internal principal and your content is our access controls, least-privilege practice, and monitoring, not per-account encryption.
• The index is excluded from the database exports we take for backup, so these excerpts are not carried into the exported copies described under "Business continuity and backups". They are not absent from every copy, and we would rather say so than let the sentence above be read that way: the disk volumes of the machine running the database are snapshotted daily, and a volume snapshot holds whatever was on the disk, index rows included. Those snapshots are encrypted at the volume level — which protects the media, and is not the per-account encryption described above — and they are retained for less time than the backup window stated below, so a residual copy of an index row ages out on the same timeline as the rest of your data, or sooner.
• Suspending an account does not make its index rows unreadable. For encrypted data we can withhold the key; an unencrypted row has no key to withhold. Deleting an account removes its index rows along with the rest of its live data, on the timeline under "Deleting your data".

Encryption in transit

All data in transit is protected with TLS, and the version depends on which connection it is — a distinction worth stating rather than rounding up:

• Everything our own software terminates is TLS 1.3, structurally. The app's live connection to us, and every connection between our internal services, runs over QUIC, in which TLS 1.3 is the only version the protocol permits — there is no 1.2 fallback to negotiate, and our transport is built without the code to speak one.
• The public HTTPS edge — the web pages and API endpoints your browser fetches over ordinary HTTPS — prefers TLS 1.3 and still accepts TLS 1.2. TLS 1.2 with modern ciphers is not a weak configuration, and dropping it would lock out older devices; but a connection that negotiates it is not a TLS 1.3 connection, and this page said "all data in transit is protected with TLS 1.3" until 2026-08-17, which was more than the configuration delivered. Nothing below TLS 1.2 is accepted.

Communication between our internal services uses mutual TLS (mTLS), so services authenticate each other in both directions.

Structural cross-actor isolation

Beyond encryption, the execution model enforces isolation directly. Features run as programs in Fabric-Starlark, a restricted language in which a read across actor boundaries cannot be expressed. Combined with per-actor keys, this means that even at the storage layer one actor's data is encrypted under a key another actor's execution context can never obtain. Isolation is therefore a property of how the system is built, not merely a configuration setting that could be misapplied.

The search index described above is an exception to the mechanism, not to the isolation: its rows are not encrypted under a per-account key, so what keeps one account out of another's index rows is that every query is restricted to the requesting account's authenticated identity. The boundary holds; it is enforced by the query path rather than by cryptography.

Cross-actor isolation is an architectural property of the system's design — it follows from the per-actor data keys and their per-account cryptographic binding described above rather than from a policy control. It has not been separately audited or certified by a third party, and we do not present it as a certified control.

Purpose-bound decryption and an immutable audit ledger

Your data is decrypted only for bounded, specified purposes — for example, to display your inbox, to run an assistant request, or to send relevant content to our inference provider. Every decryption on our servers is recorded in an immutable, per-event audit log, and each entry identifies which part of the system performed it. There is no bulk-decrypt path: the system has no mechanism to mass-decrypt an actor's data or to read across actors. We monitor the decryption log for anomalous patterns.

This is a stronger position than "we audit-log access." Because decryption is purpose-bound and there is no bulk path, an operator or engineer cannot quietly mass-decrypt your data even with infrastructure access — the architecture does not offer that capability. We say "decrypt" rather than "read" deliberately: the search-index excerpts described above need no decryption, so for that one store the limit is the access controls and monitoring below rather than the architecture.

The second stated exception: decryption on your own device

The claim above is bounded to our servers because that is where the ledger is written. The Lonzo app keeps an encrypted cache of content you have already fetched, so the app starts quickly and works with the radio off, and it encrypts what you write while offline until it can be sent — in the same form our servers hold it, under your account's key. The app decrypts those in memory, on your device, when it needs them, and those decryptions produce no ledger entry.

That is a structural limit, not a setting we left off. An audit entry is written to a system-wide store that only our backbone is authorized to write to, precisely so that an entry survives whatever happens to the account it describes; the app on your phone deliberately has no such authority, and cannot be given it without also being able to write to a store shared across all accounts. An app that instead buffered entries it could never deliver would eventually have to choose between discarding them and refusing to open your own cached mail.

What the ledger is watching for also does not arise here. Its purpose is to make an insider at one of our multi-tenant servers visible — one part of the system decrypting many different accounts' data, or far more of one account's than usual. The app decrypts exactly one account's data, for that same account, on hardware you hold. Where the device itself is the risk, what protects that cache is your device's own lock screen and app sandbox, the fact that it holds only content the app has already fetched for you, signing out (which clears it, with one deliberate exception: anything you wrote while offline that has not yet reached us is kept, because on that device it is the only copy — it is sent and then dropped the next time the app has both your sign-in and a network), and one property worth stating plainly: the app never stores your account's key on the device. It obtains that key from us over an authenticated connection and holds it in memory only, for a bounded time, so the cached bytes on a phone that is switched off are not readable without signing in to us again. Our Cookie & Local Storage Notice lists what the app stores on the device and when each item is cleared.

Personnel and access controls

Internal access follows the principle of least privilege: personnel receive only the access they need to do their job, and access to production systems and to any customer data is restricted to authorized personnel with a specific operational need.

We back that with organizational controls:

• Mandatory multi-factor authentication (MFA) for all staff access to production systems and to environments that can reach user data. MFA is phishing-resistant: a WebAuthn/FIDO2 hardware security key is required for administrative and production access; a TOTP authenticator app is accepted for other staff access.
• Confidentiality agreements. Every employee and contractor with access to customer data is bound by written confidentiality obligations.
• Security training. Personnel receive security-awareness training appropriate to their role.
• Periodic access reviews. Access grants to production and to customer data are reviewed on a recurring basis and revoked promptly when no longer needed or on role change or departure.

These personnel controls complement — they do not replace — the architectural control described above. The per-actor encryption and purpose-bound decryption model is itself the primary structural defense against insider risk: there is no operator screen and no application path that decrypts customer data in bulk, and no data key unlocks more than one account. Even an administrator with broad infrastructure access cannot quietly mass-decrypt customer data, because the capability to do so does not exist in the system. The organizational controls above govern the bounded, audited access that the architecture does permit — and they are the primary control, not a secondary one, for the search-index excerpts described under "Encryption at rest", which are readable without decryption.

How to read the commitments on this page. The architectural properties described above — per-actor data keys, purpose-bound decryption, the immutable ledger, the absence of a bulk-decrypt path, the inexpressibility of a cross-actor read — are properties of the running system today, with both exceptions — the search index, and the app's decryptions on your own device — stated where they apply rather than left for a reader to discover. The organizational and periodic controls in this section, together with the annual restore test under "Business continuity and backups," are commitments we are contractually bound to, and for any control described here as recurring or periodic, the first cycle runs within 90 days of the date the commitment was first published — that is, by 2026-10-10. Until 2026-08-18 this sentence measured those 90 days from the effective date of this page itself, which was a promise that could never come due: we re-issue this page whenever a fact on it changes, often more than once a month, and each re-issue moved its own deadline. The date above is fixed, it is measured from 2026-07-12, when these commitments were first published, and re-issuing this page does not restart it. We state this distinction rather than let a reader infer a longer operating history than we have. None of these controls has been audited or certified by a third party; see "Compliance."

Logging and monitoring

Access to customer data on our systems is logged. Every decryption of actor-scoped data on our servers is written to the immutable ledger described above, and we monitor for anomalous decryption activity. Two things do not appear in that ledger, both stated where they are described: a read of the search-index excerpts under "Encryption at rest" is not a decryption at all, and a decryption the app performs on your own device is not recorded, for the reasons given under "Purpose-bound decryption." These logs also strengthen our ability to characterize the scope of any security incident on our systems.

Incident response

We maintain an incident-response process for security events affecting customer data:

1. Monitoring and detection. We monitor the immutable decryption ledger and system telemetry for anomalous activity, so that a potential incident surfaces quickly rather than going unnoticed.

2. Triage and assessment. On detection, we assess scope and severity — what data, which accounts, and whether any actor-scoped data was actually decrypted. The per-decryption audit log lets us characterize the blast radius of an incident on our servers with a high degree of precision. It records nothing about a decryption on a customer's own device, so it cannot bound an incident confined to one — for a lost or compromised device the response is revoking the credential that device holds, together with the device protections described above.

   You do not have to wait for us to do that, and until 2026-08-17 this page told you that you did. The fastest response is the one you control: reset your password from the sign-in page ("Forgot password"). A completed reset revokes every device credential on the account — it signs out every signed-in device, permanently revokes the certificate each one holds rather than waiting for it to expire, and closes the connections they currently hold open. The lost device is included, because the reset does not need that device to co-operate. Write to security@lonzo.ai if you cannot receive the reset email, if you would rather we did it, or if you want help working out what the device could reach — we can perform the same account-wide revocation from our side. What we cannot do from our side is revoke one device and leave your others signed in: that per-device action can only be taken by the device being signed out, which is exactly what a lost device cannot do.

3. Containment and remediation. We act to contain the incident, close the underlying cause, and, where warranted, rotate or destroy affected key material.

4. Notification. Where a confirmed personal-data breach affects customer data, we notify affected customers in line with the breach-notification commitment in our Data Processing Addendum — without undue delay and no later than 48 hours after we become aware — with the information customers need to meet their own regulatory obligations.

Business continuity and backups

We keep encrypted backups to protect against data loss and to support disaster recovery; backups hold the same per-account ciphertext as live storage. Backups and infrastructure are hosted on AWS with multi-AZ (availability-zone) redundancy within a single AWS region (multi-region redundancy is deferred). Backups are purged on a 90-day rolling cycle — the same backup-purge number stated on the data retention & deletion policy and in DPA Annex II — and that cycle is what bounds how long a residual copy of deleted data survives. That 90 days is the longest of three windows, and we publish the longest deliberately: machine-disk snapshots are kept 14 days, superseded copies of your encrypted content in the object store expire 30 days after they stop being current, and the nightly export of our database is kept 90. Until 2026-08-17 this page and the three documents beside it published the 30 — the object store's window, stated as though it covered everything — and the nightly export, which carries account rows, outlasted it by two months. An automated check now reads the window out of the backup configuration itself and fails our build if any published page states a different one. We test restore from backup at least annually, as a committed control (see the note at the end of "Personnel and access controls").

Infrastructure and hosting

Lonzo runs on Amazon Web Services in United States regions. We inherit the security and compliance posture of AWS's own infrastructure (AWS maintains a broad set of independent infrastructure certifications); our own controls, described on this page, run on top of that foundation.

How your data relates to Google

For email, calendar, contacts, and tasks, Google is the authoritative source — the durable record lives in your Google account. Lonzo holds caches only. This limits the blast radius of any issue on our side: the system of record is Google, not us. If you stop using Lonzo, your Gmail, Calendar, and Contacts in Google remain exactly as you left them.

We adhere to the Google API Services User Data Policy, including its Limited Use requirements, in how we access and use Gmail, Calendar, Contacts, and Tasks data. Our full Google API Services Limited Use Disclosure is published separately at lonzo.ai/legal/google-limited-use-disclosure and is incorporated here by reference.

Google verification / CASA status: Google OAuth verification and the Cloud Application Security Assessment (CASA) required for restricted Gmail scopes are not yet completed. We make no claim of Google Workspace Marketplace approval or of a passed CASA assessment, and we will not make one until it is obtained.

Artificial intelligence and your data

Lonzo's assistant is powered by large-language-model inference running on AWS Bedrock (Nova, Claude, and Titan model families). To answer your requests, we decrypt and send relevant content — such as email and calendar content — to Bedrock for inference. This is what we mean when we say we are not zero-knowledge: providing the assistant requires processing your content in plaintext for that bounded purpose, under the audit and access controls above.

Prompts and responses are processed by Amazon Web Services via Amazon Bedrock. Under the AWS Service Terms, content sent to Bedrock is not used to train the underlying foundation models and is not shared with the third-party model providers; Bedrock operates on a zero-data-retention basis by default and retains no prompt or response content after a request completes. Inference is performed within AWS's United States Region set. AWS processes this data under the AWS GDPR Data Processing Addendum (which incorporates the EU Standard Contractual Clauses), and Bedrock is in scope for AWS SOC and ISO 27001/27017/27018 reports. Bedrock is also a HIPAA-eligible AWS service, but that eligibility is AWS's, not ours: we hold no Business Associate Agreement with AWS or with you, and Lonzo does not accept protected health information. Nothing on this page should be read as permitting PHI to be processed through the Service — see "Compliance" below.

Deleting your data

When you request deletion, we remove your account and its data from our live systems and revoke the Google authorization and stored tokens that went with it — within 30 days. Residual copies remain in encrypted backups until those age out on the 90-day rolling purge cycle, so deletion is complete — live systems and backups — within 90 days.

What we deliberately do not claim. Destroying a per-account key would make every residual copy unreadable the instant the key was gone. We do not currently do that as part of deletion, for the architectural reason given above: the key-encryption key is a single managed key bound to each account cryptographically, not a separate destroyable key per account. So we do not describe deletion as cryptographic shredding and we do not tell you your data becomes mathematically unrecoverable at the moment you ask. What we commit to is removal from live systems within 30 days and expiry from backups within 90. Full details, timelines, the two categories a deletion does not reach, and the three routes by which a deletion is asked for — Account → Delete account in the app, the public no-sign-in page required by the app stores, and email to privacy@lonzo.ai — are in our data retention & deletion policy at lonzo.ai/legal/data-retention-deletion. All three reach the same manual fulfilment: the in-app control records and attributes the request and does not itself delete anything, so your account keeps working until a person acts on it. The 30- and 90-day bounds above run from when you ask, not from when we get to it.

Sub-processors

We keep the third parties that touch your data to a minimum. Our core infrastructure is Google (as the authoritative source of your synced data, and the path by which every email the Service sends on your behalf is sent, from you — messages to the people you correspond with and coordination messages to participants alike) and AWS (hosting, storage, inference, and the mail we send from our own Lonzo addresses, which is account and service mail). The full, current list — with each vendor's purpose, data categories, and location — is published at lonzo.ai/legal/subprocessors.

Compliance

We designed Lonzo to align with the requirements of the GDPR, UK GDPR, the Swiss FADP, and US state privacy laws, and we make a DPA available to customers who need one.

We do not currently claim SOC 2, ISO 27001, or HIPAA certification.

• SOC 2 / ISO 27001: not yet obtained. If your organization requires a formal report, contact us at security@lonzo.ai and we will discuss what we can provide, including answering reasonable written security questionnaires and sharing our security documentation.
• HIPAA: Lonzo is not a HIPAA-covered service and should not be used to process protected health information under a HIPAA obligation. We offer no Business Associate Agreement at this time.

Reporting a vulnerability

If you believe you have found a security vulnerability in Lonzo, please report it to security@lonzo.ai. We welcome good-faith security research: if you report a vulnerability responsibly, give us a reasonable opportunity to remediate before public disclosure, and avoid accessing or modifying other people's data or degrading the service, we will not pursue or support legal action against you for that research.

Full terms — what is in scope, what is out of scope, the coordinated-disclosure window, and our safe-harbor commitment — are set out in our Vulnerability Disclosure Policy at lonzo.ai/legal/vulnerability-disclosure.

Questions

For security questions or vulnerability reports, contact us at security@lonzo.ai. For privacy or data-protection questions, or to discuss your organization's compliance requirements, contact us at privacy@lonzo.ai.

---

All legal documents · Help · Lonzo home