Security at Lonzo

Effective 2026-08-09 · Version 1.1

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.
  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 fully logged, and cannot happen in bulk. 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", AES-256-KW) that is held in a hardware security module (HSM), with one KEK per human actor.

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 keys are per-actor and HSM-backed, compromising one actor's data does not expose any other actor's data, and no single key unlocks everyone.

Encryption in transit

All data in transit is protected with TLS 1.3. 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.

Cross-actor isolation is an architectural property of the system's design — it follows from the per-actor key hierarchy 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 single decryption is recorded in an immutable, per-event audit log. 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-read your data even with infrastructure access — the architecture does not offer that capability.

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 or query that dumps customer data in bulk, and no single key unlocks more than one account. Even an administrator with broad infrastructure access cannot quietly mass-read 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.

Logging and monitoring

Access to customer data is logged. Every decryption of actor-scoped data is written to the immutable ledger described above, and we monitor for anomalous decryption activity. These logs also strengthen our ability to characterize the scope of any security incident.

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 with a high degree of precision.
  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 are encrypted under the same per-actor key hierarchy, so crypto-shredding an account also neutralizes that account's data in backups. 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 30-day rolling cycle — the same backup-purge number stated on the data retention & deletion policy and in DPA Annex II. We run a business-continuity / disaster-recovery test at least annually to validate that we can restore from backup.

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 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); Amazon Bedrock is also a HIPAA-eligible service under BAA and is in scope for AWS SOC and ISO 27001/27017/27018 reports.

Deleting your data

When you delete your account, we crypto-shred your data: we destroy your per-actor key hierarchy (KEK and ADK), which renders all of your ciphertext — including copies in backups — permanently unrecoverable. Deletion is irrecoverable, not a soft-delete flag. Full details, timelines, and the deletion path — the public, no-sign-in page required by the app stores — are in our data retention & deletion policy at lonzo.ai/legal/data-retention-deletion.

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 for any outbound email — Vista del Lago Software LLC sends no email from its own identity) and AWS (hosting, storage, and inference). 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