What she's 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 her 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 she tells you what is on tomorrow, she 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 she can tell you about and not something she can move.

She 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.

Anything she writes on your behalf outside a chat — a follow-up to a customer, a change to a lead record — has to be approved by a person first.

That is not a house rule she has been asked to follow. The assistant's own credential is not permitted to move a record into the approved state at all; only a human account can. If the rule were only in her instructions, a bad day or a clever email could talk her out of it. It is not in her 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 she keeps about your business are stored there, and in the backups of those machines.

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

Rumi's understanding comes from AI models we use under contract. The messages she 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. She 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 her.

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.