Skip to content

Vulnerability Disclosure Policy

Effective 2026-08-17 · Version 1.4

Lonzo handles some of the most sensitive data people own — their email, calendar, contacts, and tasks. We treat the security of that data as a first-order responsibility, and we welcome the security-research community's help in keeping it safe. This policy explains how to report a vulnerability to us and what you can expect in return.

How to report

Send your report to security@lonzo.ai. Please include enough detail for us to reproduce and assess the issue: the affected component or URL, the steps to reproduce, the impact you believe it has, and any proof-of-concept material. If you would like, tell us how you would like to be credited.

We will acknowledge your report within 5 business days and work with you through remediation. Please give us a reasonable opportunity to investigate and fix the issue before you disclose it publicly.

Machine-readable contact. The same address is published as an RFC 9116 security contact file at /.well-known/security.txt, served from both of the hosts named under In scope below, and it points back at this page as its policy. If your tooling found this page from that file, you are in the right place; if it found the file and not this page, read the rules below before you begin, because they are what the safe harbor is conditioned on.

Safe harbor — good-faith research

If you make a good-faith effort to comply with this policy during your research, we will consider that research to be authorized, and:

  • We will not pursue or support legal action against you in connection with that research, including under computer-misuse or anti-circumvention laws or under our Terms of Use.
  • We will not consider your good-faith activity to be a breach of our Terms of Use for the purpose of that research.

This safe harbor applies only to good-faith research that stays within the scope and rules below. It does not, and cannot, waive the rights of any third party. If legal action is initiated by a third party against you for activity conducted under this policy, we will make it known that your actions were authorized under this policy.

This is part of the agreement, not a page beside it. A safe harbor that lives only on a policy page is worth less than it looks, because the contract you actually accepted can contradict it: our Terms of Use say the Terms and the policies they incorporate are the entire agreement, and until 2026-08-17 they did not incorporate this one — while Section 4.2 of the Terms and Section 2 of the Acceptable Use & Anti-Spam Policy prohibited, with no exception wide enough, the very work invited below. So the promise above sat outside the document a dispute would be read against. It no longer does: this policy is incorporated into the Terms of Use, Section 4.4 of the Terms authorizes research conducted within the scope and rules on this page, and Section 2.7 of the Acceptable Use & Anti-Spam Policy carves that research out of the prohibitions on probing, on reverse engineering (which the Android application below cannot be examined without), on circumventing access controls, and on testing the assistant's own behavior against crafted input.

What it still does not cover, stated plainly. Three prohibitions are not carved out and are the same three the rules below already ask of you: do not reach another person's data or account, do not transmit harmful code, do not degrade the Service. And we may still rate-limit, suspend, or block a test account — or an address it works from — to protect the Service and the people using it. That is a protective measure, not a withdrawal of the authorization: if it happens while you are testing in scope, tell us and we will say so.

Rules of engagement

While researching, please:

  • Do not access, modify, delete, or exfiltrate data that is not yours. Use only test accounts you control. If you encounter another person's data during testing, stop immediately, do not view or retain it beyond what is necessary to document the finding, and tell us.
  • Do not degrade or disrupt the service. No denial-of-service, no automated high-volume scanning that impairs availability, and no spam or social-engineering of our staff or users.
  • Do not use social engineering, phishing, or physical attacks against our staff, users, or facilities.
  • Keep findings confidential until we have had a reasonable opportunity to remediate and have coordinated disclosure with you.

In scope

We run on two registered domains, and both are in scope. This is worth stating plainly, because the interesting attack surface is not all on the one you typed into a browser:

  • lonzo.ai and its subdomains — the customer-facing origin: the Lonzo browser application, the public pages, the sign-in and account flows, and the HTTP endpoints they call.
  • tlnkfabric.net and its subdomains — the infrastructure origin: the mutually-authenticated service transport, the real-time session transport the browser and mobile applications connect over, and the production hosts these resolve to. The name is an internal one that predates the Lonzo brand; it is the same system, operated by the same company, and research against it is covered by the same safe harbor.
  • The Lonzo Android application, including its local storage, its inter-process surface, and its use of the transport above.
  • The assistant's own behavior under crafted input — prompt injection and similar attacks that make the assistant act outside the instructions its owner gave it. This is in scope deliberately and it is the most serious class of finding this product can have: the assistant sends mail as you and changes your calendar, so an input that redirects it is an action taken in your name. Test it against your own account and content, never against anyone else's.
  • Vulnerabilities that could affect the confidentiality, integrity, or availability of customer data on either host.

If you find something on a host you are unsure about, report it and ask — we would much rather answer that question than have you stop at the edge of the safe harbor.

Out of scope

  • Findings in third-party services we rely on (for example Google, Google Play, or AWS) — report those to the relevant provider. Our current sub-processors are listed at lonzo.ai/legal/subprocessors.
  • Reports from automated scanners without a demonstrated, exploitable impact.
  • Denial-of-service, volumetric, or resource-exhaustion attacks.
  • Social engineering, phishing, and physical-security issues.
  • Missing security headers, cookie flags, or configuration best-practices with no demonstrated exploit.
  • Vulnerabilities requiring a rooted/jailbroken device, a compromised account, or a privileged position that is itself out of scope.

Coordinated disclosure

We ask that you give us a reasonable time to remediate before disclosing publicly — 90 days from your initial report. We are happy to coordinate timing and public credit with you, and we will keep you informed of our progress.

No bug-bounty program

This is not a paid program. We do not offer monetary rewards or a bug bounty for vulnerability reports. Instead, we run a recognition-only program: we deeply appreciate responsible reports and, with your permission, we will credit you on our Security Researcher Acknowledgements page once an issue is resolved. Credit is opt-in — tell us in your report if you would like to be listed and how you would like to be named.

That page is published, and it is empty. Until 2026-08-17 this section promised the list without linking it, because it did not exist: the whole consideration this program offers in place of money was a phrase in a sentence. The page is now live, states the four conditions under which an entry appears, and says plainly that no one is listed yet. We would rather you see an empty page and decide whether that is worth your evening than take our word for a list you cannot open. It is also named in the Acknowledgments field of the security.txt file above, so tooling can reach it too.


All legal documents · Help · Lonzo home