Security

Last updated: September 10, 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 we did 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 we never requested or by the database itself, we say so, because those are the promises worth anything.

What we ask 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 we cannot do

Gmail offers an all-access scope. We did not request it, and the difference is not cosmetic.

• We cannot permanently delete your mail. Permanent deletion needs the full mailbox scope. We hold gmail.modify, which does not include it. This is not a policy we could quietly change our mind about. Google would have to prompt you to grant a new permission first, and you would see it.
• We cannot touch your Drive, your contacts or anything else in your Google account. The three scopes above are the whole surface.
• We cannot read mail after you revoke us. Revoking in Google kills the refresh token, and with it every access token issued from it.

We do delete calendar events, 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 our model provider, because deciding what to do next is what the product is. It reaches our observability provider in de-identified form so we can debug wrong behaviour. It lives at rest in our cloud provider. That is the whole list.

Our sub-processor list names every provider, what it receives, where it runs and whether it may train on your data. None of them may. If you have a data processing agreement with us, we tell you before a new provider touches your content.

How it is protected

Your Google tokens

Access and refresh tokens are encrypted before they are written to the database, with a key held outside it. Reading the tokens table gets you ciphertext.

The database

The application has no database password. It authenticates with a short-lived IAM credential issued per connection, so there is no long-lived secret to leak, and the login role it uses cannot be used with a password at all.

Tenant isolation is enforced by the database, not by our code. Every table carrying customer data has row level security switched on, and every query runs inside a transaction scoped to one tenant. A missing WHERE clause in application code returns nothing rather than someone else’s mail. We think this is the single most valuable thing on this page, because it is the failure everyone else has to promise will not happen.

The network

The database and the services that use it sit in a private network with no public address. Traffic is TLS everywhere. Our 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 our systems we strip email addresses, phone numbers, payment card numbers and access tokens. The surrounding text stays, so we treat those records as your content in de-identified form and say so on the sub-processor list rather than pretending they are 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 we stop the Gmail and Calendar push channels, revoke our own Google access, delete your third party credentials and delete your account. 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 job, note, message and event we ingested, 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 we do not have

We are a small company and we would rather you hear this from us than find out later.

• We are not SOC 2 certified and have not been through a third party penetration test.
• We do not offer single sign-on beyond Google, or audit log export.
• Deleted rows can survive in our encrypted database backups for up to seven days, which is how long we keep them. We take no manual snapshots, so nothing outlives that window.

If one of these blocks a deal, tell us. It is more useful to know what you actually need than to guess.

Reporting a problem

Email george@lemongraph.dev with anything you find. We will confirm we received it, tell you what we found and credit you if you want the credit. We do not run a bug bounty and will not threaten you for reporting in good faith.

Questions

This page pairs with our Privacy Policy, which covers what we collect and your rights over it. For anything not answered here, email george@lemongraph.dev. Our website is https://lemongraph.dev.