Privacy

Material you give us. The pages, documents and corrections a business adds so the assistant can answer from them, and the passages we derive from that material in order to search it.

Conversations. What a customer asked, what the assistant answered, and where a person took over. A customer talking to a widget is not asked to make an account, and we do not try to identify them beyond what they type.

Account and workspace. The name and email of the people who sign in, the business's own details, and a record of what was done in the workspace and by whom. Where a business has connected another account — a a Gmail mailbox — we hold the authorisation for it and the address it belongs to, which the next section describes in full.

Usage. Counts — requests, questions answered, storage used — so a business can see what it is using and be billed correctly. Our operational logs are tagged with the workspace but the content of prompts and answers is removed before it reaches them.

Connecting Google is optional. Nothing below happens unless a business explicitly connects its Google account, and it can disconnect at any time.

Gmail — gmail.modify, and only that. A business can connect its own mailbox so the assistant can read what came in, find a message, tidy the inbox, and draft an answer that a person at the business then reads and sends.

With this permission we read messages in that mailbox — who a message is from and to, its subject, the date, its place in a thread, and its text — and we change the labels on them: marking a message read or unread, and moving it out of the inbox or back in. We ask for this one permission rather than a separate read-only permission because a read-only permission would be one we already hold inside the first; asking for both would mean showing a business one more consent line for nothing. The same permission lets us send the replies a person has read and approved, from that same mailbox.

Attachments are listed by name, type and size so somebody can see what came with a message. We do not download them, and the file itself never reaches us.

We cannot delete a business's mail. Permanently deleting a message needs a wider permission than the one above and this app never requests it. Nothing in the product moves a message to the bin either.

We do not request access to contacts, Calendar, Drive, or to a business's Google profile beyond the address of the mailbox it connected.

Nothing from a mailbox is stored by us. A message is fetched from Google when somebody opens it and is gone when that request ends. We keep no copy, no index and no search cache of anybody's mail. What we do keep for the connection itself is the address of the connected mailbox, which permissions were granted, when it was connected, when it was last used, and — if the last check failed — what Google said went wrong. None of that contains the content of a message.

The settings page has a button that proves the connection actually works, and it says what it will do before it is pressed: it reads the inbox, opens one message, searches, marks a message read and puts it back, archives one and puts it back, writes a draft and deletes it, and sends one email to the connected address itself. Everything but that last email is put back as it was. We record only whether each step passed and, where one failed, Google's own error message.

Google data is used only to answer the question in front of the assistant and to carry out the action a customer asked for. It is never sold, never used for advertising, never used to build a mailing list, and never used to develop, improve or train any model, ours or anyone else's.

No person at Mara reads a business's mail, and that is structural rather than a promise about conduct: our own operator console has no screen that can reach a mailbox, and the only code in the product that can is reached through a workspace's own members. The exceptions are the ones we would want stated if it were our mailbox — where a business has asked us to look at something specific and told us so, where we are compelled by law, or where we must act on a security incident — and none of them happens in the ordinary course of running the service.

A message's text reaches a model only when a person at the business presses one of two buttons — one that asks what a message says, one that drafts a reply. Nothing is sent automatically, nothing is sent in the background, and no message is sent to a model merely because somebody opened it. We send the plain text only, never the message's HTML, and never more than roughly twelve thousand characters of it. It is sent to produce that one answer and for nothing else: our agreement with our model provider does not permit a business's data to be used to train or improve any model, and we keep no copy of what was sent. The security page names the provider.

Mara's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

gmail.modify is a restricted scope, which means those requirements are read strictly, so here they are one at a time against what this product does. Mail data is used only to provide the features a business can see and pressed a button for. A message passes through the provider that runs this application while the request is being served, and is held by none of them afterwards; beyond that it is transferred to nobody except our model provider, and to them only to produce the one answer somebody asked for. Otherwise it goes out only where a business tells us to, where the law compels us, or where we must act on a security incident. It is never used for advertising, never sold, and never passed to anyone for advertising, credit scoring or lending decisions. Human access is limited to the narrow cases set out above. Mail data is not used to develop, improve or train any model: where a message's text is sent to a model it is sent as the input to one request, for one business, to produce one result for that business, and nothing is retained from it afterwards by us or kept for model development.

What we have and have not been independently assessed against is listed, including the things we do not hold, on the security page.

Disconnecting. A business can disconnect the mailbox on its own screen in Mara's settings, and can revoke any of these permissions — mailbox — directly at myaccount.google.com/permissions. Either way we stop being able to reach that account immediately. Disconnecting the mailbox in Mara also asks Google to withdraw the permission and deletes the stored authorisation from our side, and that authorisation is removed here even if Google cannot be reached at that moment. Revoking at Google ends the mailbox connection.

What was already in the Google account stays there. Replies the assistant sent, remain in the mailbox — they belong to the business, not to us. There is nothing of a business's mail left on our side to delete, because we never held any; deleting the whole workspace also removes the connection record.

The authorisation belongs to the workspace rather than to the person who granted it, so a colleague leaving the business does not take the connection with them. Only an owner of the workspace can connect or disconnect an account; other members can use a connection an owner has made but cannot grant or remove one.

Signing in with Google. If you sign in with Google we receive your name, email address and profile picture, and use them only to create and identify your account.

In short, for every Google permission.

• Data accessed: for a connected mailbox, message headers, text, labels and attachment names. From these we derive only aggregated, non-content figures about the connection itself — when it was connected and last used, and whether its last check passed. We create no other aggregated or anonymised dataset from Google data.
• Data use: raw and derived Google data is used only to provide and improve the features a business sees and asked for — reading, filing, drafting and sending mail on the business's instruction. Never for advertising, profiling, lending or credit decisions, or model training.
• Data sharing: raw or derived Google data is shared with only two kinds of party, and only to run the feature: our hosting and database provider, which stores the connection record, and our AI model provider, which receives a message's text only when a person presses the button asking for a summary or draft, under terms that forbid using it to train or improve models. It is never sold or given to advertisers, data brokers or any other party, except where the law compels us.
• Data protection: all traffic is encrypted in transit (TLS) and stored data is encrypted at rest. Google authorisations are kept in an encrypted secret store, never in ordinary tables, never shown in the product and never written to logs. Access is limited to members of the workspace that made the connection; only owners can connect or disconnect.
• Retention and deletion: mail is not stored. The authorisation and connection record are kept until the business disconnects, revokes access at Google, or deletes its workspace, and are deleted then. Sent replies stay in the business's own Google account. To ask us to delete anything else, use the contact details at the end of this policy.

In our database and file storage in the European Union (Ireland). Answering a question also sends the relevant passages and the customer's question to our model provider, which processes them in the United States.

We do not offer data residency anywhere else today. If a regulator requires it, we cannot serve that business yet.

Material and corrections are kept until the business removes them. Customer conversations are kept for as long as the business chooses — 30 days, 90 days, six months, a year, or indefinitely — and older conversations are then removed automatically.

A Google authorisation is kept until it is disconnected, revoked at Google, or the workspace is deleted. Mail itself is not kept at all: a message exists on our side for the length of the one request that fetched it, so there is no retention period to state and nothing of a mailbox to delete later.

A business can take a complete copy of everything in its workspace at any time, without asking us, and can delete conversations or the whole workspace itself. A deletion removes the rows and the stored files; we count what remains afterwards and show that count, so the deletion is verified rather than promised.

Each workspace's material, conversations and connections are separated in the database, and a request is resolved to one workspace before any data is touched. A workspace can have an owner, an administrator and a support member, and those permissions are enforced in the database rather than in the screens.

Our own staff do not read a business's conversations as a matter of course. Where we need to look at something to fix a fault, that access is recorded.

Our hosting and database provider, our model provider, our email provider, and — where a business uses it — WhatsApp for messages that travel over WhatsApp. The current list, and what each one does, is on the security page.

Most of it does not need us: export and deletion are in the product. For anything else — a question about this policy, a request about personal data, or a complaint — write to privacy@mara.support and a person will answer.

If a business's customer wants their conversation removed, the business can delete it from its own desk, or ask us.

If this policy changes in a way that affects what we do with a business's data, we will say so in the product rather than quietly reposting the page.