What Rumi is allowed to do with your data

When you connect Rumi to your Google account, the permission you approve is read-only. That is not a setting we promise to respect — it is the credential itself. A request to send, delete, label, or change anything fails at Google's end, before it reaches us.

Read-only is about direction, so here is the breadth too: the connection covers the Google services you tick on the consent screen. Mail and calendar are what Rumi's tools actually reach today, and if those two are all you want to grant, untick the rest — a narrower grant is a supported choice, not a downgrade.

The calendar half of that grant is read as well as covered: when Rumi tells you what is on tomorrow, Rumi is reading the calendar you connected. The same restriction applies to it as to your mail — the permission you approved carries no write, so an event is something Rumi can tell you about and not something Rumi can move.

Rumi reaches your mailbox through a small set of named read tools rather than open access, and every call one of them makes is written to a log.

What Rumi writes for a customer — a follow-up, a reply — comes to you as a draft in your chat, and you send it yourself from your own email app.

That is not a house rule Rumi has been asked to follow. The mail connection you approved is read-only, so a request to send through it fails at Google's end. If the rule were only in Rumi's instructions, a bad day or a clever email could talk Rumi out of it. It is not in Rumi's instructions.

The small team that operates the service can. We are saying that plainly because the alternative — that nobody but you could ever see it — would not be true of software running on machines we administer, and you would find that out eventually.

What you get instead is narrower and real: we do not read your messages, that commitment is part of your agreement with us, and the access logs would show it if we did.

Support access works the same way. If you ask us for help with something, we look at what is needed to fix it, and we tell you what we looked at.

Rumi runs on servers we operate. Your conversation history and the notes Rumi keeps about your business are stored there, and in the backups of those machines.

Your mail stays in your mailbox — Rumi reads it when you ask Rumi something rather than copying your inbox somewhere else. Be aware of the honest exception: the parts Rumi reads in order to answer you end up in conversation history on those machines, and therefore in those backups.

Rumi's understanding comes from AI models we use under contract. The messages Rumi needs in order to answer you are sent to them for processing.

We do not name providers on this page, because the answer can change and a page that goes stale is a page that misleads. If you are weighing Rumi up for a business where this matters, ask us and we will tell you exactly who is in the path today.

Access is whitelisted. Rumi answers the accounts and numbers you have added and ignores everyone else — which is also why there is no public number on this site for you to text and try Rumi.

We keep your data for as long as you are using Rumi, and we delete it when you ask. Write to us and we will do it and tell you when it is done.

Backups roll off on their own schedule rather than instantly, so a deletion takes a little while to reach every copy. If that timeline matters for you, ask and we will tell you what it is.

Everything above that reads as "we will not" is a commitment. The version where it reads as "we cannot" is a customer-managed deployment: Rumi running inside your own cloud account, on credentials you hold, with no standing access for us.

We can build and support that. We cannot retrofit it onto the shared setup, and it is not what you would be on today — so it belongs on this page as a roadmap item and not as a feature.