Security
Last updated: September 28, 2026
Lemongraph runs agents that pursue a piece of work for you over days or weeks, learning how you work as they go. To do that they read your mail and calendar, and send mail as you. That is a lot of trust to ask for. This page is what was done about it, written so you can hand it to whoever asks you the hard questions.
Most of what follows is checkable. Where a promise is enforced by a permission that was never requested or by the database itself, this page says so, because those are the promises worth anything.
What the app asks for
Signing in with Google grants exactly three scopes. There are no others.
- gmail.modify to read your mail, send mail, apply labels and archive.
- calendar.events to create, update and cancel events on your behalf.
- calendar.calendarlist.readonly to see which calendars you have.
What the app cannot do
Gmail offers an all-access scope. Lemongraph did not request it, and the difference is not cosmetic.
- Your mail cannot be permanently deleted. Permanent deletion needs the full mailbox scope. The granted scope is gmail.modify, which does not include it. This is not a policy that could quietly change. Google would have to prompt you to grant a new permission first, and you would see it.
- Your Drive, your contacts and the rest of your Google account stay out of reach. The three scopes above are the whole surface.
- Mail cannot be read after you revoke access. Revoking in Google kills the refresh token, and with it every access token issued from it.
Calendar events do get deleted, because cancelling a meeting is the job. That is the one destructive thing an agent can do, it is visible in your calendar, and it is reversible by you.
Agents ask before acting
Actions that leave your account can require your approval before they run. The agent stops, shows you what it intends to send and to whom, and waits. You set which tools work this way. An agent that is waiting for you is not doing anything else in the background.
Where your data goes
Your mail and calendar content reaches the model provider, because deciding what to do next is what the product is. It reaches the observability provider in de-identified form, so wrong behaviour can be debugged. It lives at rest with the cloud provider. That is the whole list.
The sub-processor list names every provider, what it receives, where it runs and whether it may train on your data. None of them may. Under a data processing agreement, notice goes out before a new provider touches your content.
How it is protected
Your Google tokens
Access and refresh tokens are held in a database with no public address, reachable only from inside the private network. They are not separately encrypted at the column level. The protection is the network boundary and the disk encryption underneath it.
The database
The database has no public address and accepts connections only from inside the private network. Its password is held in Google Secret Manager and is never in an image, a repository, or an environment file in source control.
Every query that touches customer data carries the tenant it belongs to, and each one is covered by a test that writes rows for two tenants and checks that a request for the first never returns or changes the second’s. The rule is enforced in the code and proved in the test suite.
The network
The database and the services that use it sit in a private network with no public address. Traffic is TLS everywhere. The API sends strict transport security, a locked down content security policy and denies framing.
Secrets
Credentials live in encrypted parameter storage and are resolved when a container starts, so they exist in memory and not in an image, a repository or an environment file.
Traces
Before any trace record leaves, email addresses, phone numbers, payment card numbers and access tokens are stripped. The surrounding text stays, so those records count as your content in de-identified form and the sub-processor list says exactly that rather than calling them anonymous.
Revoking and deleting
To cut off access now, revoke Lemongraph from your Google account permissions page. Agents stop being able to read or send immediately.
To delete everything, open Settings and use the Danger zone. You type DELETE, and on confirmation the Gmail and Calendar push channels stop, Google access is revoked, your third party credentials are deleted and your account is deleted. That happens inside the request. You are signed out, and your email address is free to sign up again with a clean account.
Everything else is erased within a day: every ingested job, note, message and event, everything an agent remembered about you, every attachment in file storage and every trace. Deletion is not reversible and there is no restore button, which is the point.
What is missing
This is a small operation, and hearing the gaps here beats finding them out later.
- There is no SOC 2 certification and no third party penetration test.
- There is no single sign-on beyond Google, and no audit log export.
- Deleted rows can survive in encrypted database backups for up to seven days, which is how long those backups are kept. No manual snapshots are taken, so nothing outlives that window.
If one of these blocks a deal, say so. Knowing what you actually need beats guessing at it.
Reporting a problem
Email hey@lemongraph.dev with anything you find. Every report gets an acknowledgement, a note on what turned up and credit where you want it. There is no bug bounty, and a good faith report never draws a threat.
Questions
This page pairs with the Privacy Policy, which covers what gets collected and your rights over it. For anything not answered here, email hey@lemongraph.dev. The website is https://www.lemongraph.dev.