Privacy policy.

This is the part that matters most, so it gets its own section rather than a line in a table.

When you ask your AI client to do something with your mailbox, our server connects to your mail provider, does that one thing, and returns the result. Messages are not copied into a database of ours. There is no archive of your mail here, which means there is no archive of your mail here to be lost, subpoenaed, or sold in an insolvency.

Message content passes through the server in memory while a request is being served. Some of it also passes to your AI provider, because that is the whole point: you asked an assistant to read your mail, so the mail reaches the assistant. What that provider then does with it is governed by their terms and not by ours, and it is worth reading theirs.

Attachments work the same way, and it is worth saying so plainly because this is the part people assume must be different. There are 5 ways a file can end up on a message, and none of them is stored here.

• A file already in your mailbox. It is fetched from your mail provider at the moment the message is sent and streamed straight into it. It is never written to disk here, and its bytes never pass through the assistant: what the assistant holds is a short-lived reference to the file, not the file.
• A file at a web address. If you give the assistant a link, our server fetches it when the message is built and streams it in the same way. Again nothing is written down, and again the bytes do not pass through the assistant.
• A file from your own computer. The assistant can ask for a one-off upload link, which either it or you can send the file to. That file goes into your own Drafts folder as a draft, which you can open, keep or delete in your normal mail program. It is not held on our servers at any point, and the link stops working after half an hour.
• A file in your ChatGPT conversation. When ChatGPT attaches an image it has made, or a file you gave it, it hands our server a short-lived link to the file, which OpenAI holds. Our server fetches it when the message is built and streams it in, exactly as it does a web address. Nothing is written down here.
• A file the assistant wrote itself. This one is different, because it has to produce the contents in order to send them, so those contents pass through in memory in the ordinary way.

Downloading works on the same principle. When you ask for a copy of something attached to a message, you get a short-lived link that streams the file straight from your mail provider as you click it. We keep no copy, and the link expires after 15 minutes.

Reading an attachment works the way reading a message does. When you ask the assistant what is in an attached file, our server fetches it from your mail provider, turns it into text in memory (or, for a picture, passes the picture), and returns that to the assistant.

So the contents of a file you ask about reach your AI provider exactly as a message body does, and the same paragraph above about their terms applies. Nothing is written to disk here, the file itself is not kept, and a file is opened only when you ask about it, or when a routine you have set up asks for it, as the Bills and invoices routine does to read a bill's amount and due date.

Your address book, where the mailbox has one, works the same way. On a Microsoft 365 mailbox that is your Outlook contacts, reached under the same sign-in as the mail through the contacts permission on its consent screen; on a mailbox that uses a password it is either your Google contacts, connected with a Google sign-in of their own, or a CardDAV address book you have connected.

When you ask your assistant to find somebody, our server asks your contacts server, Microsoft or Google that one question, keeps the answer in memory for about 10 minutes so the next question is quick, and then forgets it.

Where you ask it to add, correct or delete a contact, or to import a contacts file, the card is written to your own contacts server, your Outlook contacts or your Google contacts, on your instruction and to nothing of ours, and held in memory for the same period.

Nothing about a contact is written to a database, a file or a log of ours, so there is no copy of your contacts here to be lost, subpoenaed, or sold in an insolvency.

What we store for a CardDAV book is its address and a credential for it, encrypted as every credential is; for Outlook contacts, nothing beyond the Microsoft token the mailbox already had; for Google contacts, the token Google issued, encrypted exactly as the calendar's is, and which Google account gave it.

Photos are never read into an answer:

• a look-up does not request one,
• on a CardDAV card you ask it to correct the photograph passes through in memory for that one request and is written back as it was, never shown to the assistant and never held, and
• on an Outlook or a Google contact it is never requested at all.

A card you ask it to delete is removed from your book and dropped from memory at once. The record of each call says that a contact tool ran and whether it worked, and shows each argument as redacted, or as a count of how many addresses, phone numbers or cards were involved, so a name never reaches the record either.

We do not use the contents of your mailbox to train anything, and we do not read it ourselves except where you have asked us to look at something specific to diagnose a fault.

If you use this service for a work mailbox, the mail will contain personal data about other people, such as the people who write to you. In that arrangement your employer or your business is the controller for that data and we act as a processor of it on your instructions, under the data processing agreement, which forms part of the terms and needs nothing signed.

A calendar is a separate connection from the mailbox and it reaches data the mail permission does not. There are 3 ways to make one: calendar access approved on a Microsoft 365 sign-in, a Google sign-in for a Google calendar, or the address of a CalDAV calendar server. It is worth setting out what each of them reaches, because part of it belongs to people who are not you.

Your own diary. Events, their times, who is invited, how each of them answered, the body of an event, its categories and its reminders. Your mailbox's timezone and working hours, because a time cannot be stated correctly without them. Your out-of-office reply, which we can read and change when you ask.

None of it is copied into a database of ours, on the same terms as your mail: it is fetched to answer the thing you asked for and it is not written down here.

Other people's availability. When you ask when a group of people are free, what comes back is their busy and free blocks and nothing else. Not the subjects of their meetings, not who else is in them, not where they are.

That is a limit of what we ask the calendar provider for rather than a filter we apply afterwards, and it is the same information anybody in your organisation already sees when they open the scheduling view in Outlook or Google Calendar.

Where somebody's availability cannot be read at all, we are told nothing about them and report exactly that. We never infer that an unreadable calendar is an empty one.

Shared calendars. The permission covers calendars other people have shared with you, at whatever level they granted. It does not widen what you are allowed to see: your calendar provider decides that, and we ask with your own account's rights and no more. If a colleague has shared their diary with you, an assistant acting for you can see what you could already see by opening it yourself.

Booking a meeting, changing one or cancelling one sends real email from your address to the people involved, exactly as Outlook or Google Calendar would. Those messages are part of your mail, and everything in the section above applies to them.

Google Calendar and Google Contacts data, and Google's Limited Use requirements

Where you connect a Google calendar or your Google contacts, the data we receive comes from Google's own APIs and Google binds us to how it may be used. Our use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. In practice that means 4 things, and they are Google's words rather than reassurances of ours:

• The data is used only to provide the user-facing features you connected the calendar or the contacts for, which here means answering your assistant's calendar and address book questions and making the changes you ask for.
• It is not transferred to anyone else, except as needed to provide those features with your consent, for security, or to comply with the law.
• No human at this company reads it, other than where you have specifically asked us to look at something, or where it is necessary to investigate a bug or abuse, or to comply with the law.
• It is never sold, never passed to advertisers or data brokers, never used to serve or target advertising, and never used for credit or lending decisions.

3 permissions are asked for the calendar:

• which calendars the account has,
• free and busy time, and
• reading and writing events.

1 further permission is asked only where you connect your Google contacts, in a consent of its own: it reads and edits your Google contacts. None of them reaches your Gmail or your Drive, and none is asked for beyond what you connected.

As with everything else here, calendar and contacts data is fetched to answer the thing you asked and is not copied into a database of ours. You can withdraw either permission from your Google account at any time, and disconnecting the calendar or the contacts in the control panel hands it back rather than leaving it in place.

Every token Google issues, for the calendar or for the contacts, is protected exactly as a mailbox credential is, because it is stored by the same code on the same terms: how it is protected sets out the encryption in transit and at rest that applies to it, who can reach it, and what is never written down at all.

Team Access lets an account holder invite a named person to their mailboxes. This section is for both sides of that.

If somebody has invited you

The person who invited you gave us your email address and, if they chose, a name for you, together with the level they set, whether the calendar is included, a daily cap and the mailboxes.

The invitation is bound to that address: it can be accepted only by an account whose verified address is the one invited, and an attempt from any other account is refused, naming the account that is signed in and showing the invited address in masked form. Once you accept, you have your own connection to each mailbox, and nothing of the owner's credentials is shared with you.

The mailbox owner can see what you do on their mailbox through the service. Every call you make is recorded in the per-call and audit records described on this page under your name, and the owner sees it in their activity record: which tool ran, on which mailbox, when, and whether it worked. Never the contents of a message.

The owner is also emailed once the first time you send to a domain their account has not written to since Team Access began, naming you, the mailbox, the domain and the subject of the message, and receives a Monday digest counting your sends, filings and reads over the week. Those are emails to the owner, and they are the whole of what the owner is told beyond the record itself.

Your access ends when the owner removes you, pauses you, or lets the tier lapse: every connection you made ends on its next call, and you are emailed when you are removed. Nothing of yours is deleted; the record that you were on the mailbox stays with the owner's account, and the calls you made stay in the two records for the periods below. Your own account, and anything shared with you by somebody else, is unaffected.

If you invite people

The people you invite are data subjects whose address and name you give us, and we hold both on your instruction until you remove the person or close the account.

What they do on your mailboxes through the service is done at your invitation, at the level and cap you set, and it is recorded under their name so you can see it; where you use the service for a business, the data processing agreement covers your responsibility for that.

Where you hold Team Access we also keep a record of the domains your account has written to, from the day the tier is bought, from any mailbox and by anybody, so we can tell you the first time an invited person writes somewhere your account has not written to since then. It holds domains only, never addresses, and it is kept while the account exists.

A policy that lists what is held without saying what defends it has done half the job. What we hold for you is not a password you can change after the fact, it is a working key to your correspondence, so these are the actual mechanisms rather than an assurance that we take security seriously.

In transit

• Every connection between your AI client and our server is encrypted with HTTPS, as is your control panel and this website.
• Microsoft 365 and Google are reached on fixed encrypted endpoints, and Microsoft sending goes over HTTPS through Graph. Those paths are not configurable and cannot be downgraded to an unencrypted one.

• A mailbox on any other IMAP host uses the server settings you give us, exactly as Outlook or Thunderbird would. Name the TLS ports, 993 for reading and 465 for sending, and the session is encrypted before your password is sent.

  It will also connect without TLS, because some older and internal servers offer nothing else, and on such a port your password and your mail cross the network in the clear. The choice is yours and it is set out in full on the security page.

At rest

• Every credential we store, for a mailbox, a calendar and an address book alike, is encrypted with AES-256-GCM before it reaches the database.
• Each credential gets its own random encryption key, and that key is itself encrypted with a master key that is not in the database and not in our source code. The master key lives in a file only the machine's administrator account can read, and the operating system hands it to the service when it starts: the unprivileged account the service runs as cannot open that file itself.
• Each encrypted credential is cryptographically bound to the mailbox it belongs to, so a row lifted out of the database will not decrypt against any other mailbox. The attack fails at the first step rather than the last.
• Your control panel password is stored as an Argon2id hash, never as the password. The token your AI client authenticates with is stored only as a hash of itself, so the string that opens your mailbox is not in our database either. Neither can be read back or shown to anyone, including to us.

Who can reach it

• Nobody here reads your mail, your diary or your address book, other than where you have asked us to look at something specific, or where investigating a fault or abuse requires it.
• The servers are administered only by the people who run this company, and the master key is kept out of reach of the service account as described above.

• Two-factor authentication is available on your control panel account and we would rather you turned it on. That one account can reach every mailbox you have connected, which makes it worth more than an ordinary login.

  Where other people are on your account under Team Access, you can require it of all of them under Settings, Security: anyone without an authenticator can then do nothing in the panel but set one up, cannot accept an invitation onto your mailboxes, and has their AI connections refused until they have one.

The part that needs no protecting

The strongest thing that can be said about your messages, your events and your contacts is that they are never written down here at all.

They pass through the server in memory while a request is being served and no copy is kept (a contact is held in memory for about 10 minutes so the next question about the same person is quick, and then forgotten), so there is no store of your mail, your diary or your address book to encrypt, to leak, or to have to tell you about afterwards.

What we do hold is deleted on the schedule set out below, and removing a mailbox or disconnecting a calendar or an address book deletes its credential rather than retiring it.

• Stripe takes payments. Card details are entered on Stripe's systems and never reach ours.

• Hosting is on 365i, which is part of BSolve IT Limited, the processor: the servers are run by us, in London. The data-centre operator behind them is a United Kingdom provider whose name we give on request, and it holds no key to any customer data.

  The service and the control panel run on a 365i Unmanaged VPS and this website on 365i hosting, all in the United Kingdom; the encrypted nightly backup and its off-site copy are held there too, and the support mailbox you write to is on 365i's mail platform.

• Cloudflare and Brevo run the uptime monitor and handle a support request sent from the control panel, and Brevo also delivers every email the service sends, from noreply@mailbox-mcp.com. The monitor reads only the service's 2 public health endpoints, which answer in status words: no customer data there.

  A support request is different: Cloudflare stores it and Brevo sends it, and between them they hold your name, account email, your message, how urgent you said it is, and, only if you tick to include it, diagnostic detail such as your plan, account age and each mailbox's connection state.

  The getting-started emails, a few short notes in your first days while an account has no mailbox or a mailbox has not been used, the note when your first call goes through, the note the first time a free mailbox has used its 5 calls, and the occasional note about something new, go through Brevo's sending service, which therefore handles

  • your name,
  • your account email,
  • the address of the mailbox the note is about,
  • which AI client made the call where the note says so, and
  • the text of the note.

  The account and security emails go through Brevo too: the address confirmation, the welcome, password resets, security notices such as a new device signing in or a changed password, Pro, payment and billing emails and receipts, Team Access invitations and notices, mailbox reconnect notices, the warning before an idle account with no mailbox is deleted, the emails about a reviewer application, and the notices sent to us about a new account or a payment.

  For those, Brevo handles the text of each email, which carries

  • your email address,
  • the names and addresses of the people and mailboxes it is about,
  • a payment's amount, date and what it was for,
  • when a new device signs in, which device and its IP address,
  • any link to confirm an address, reset a password or accept an invitation, which works once and expires, and
  • on a Team Access notice of a first email to a new domain, that domain and the message's subject.

  Never a password, an access token, or the contents of a mailbox message. A closed ticket is deleted 12 months later. The full list, with what each does and where, is on the IT and security page.

• Your mail provider, being Microsoft, Google or whoever hosts your IMAP mailbox. They already hold your mail; we connect to it.
• Your calendar provider, where you have connected a diary: Microsoft, Google, or whoever runs the CalDAV server whose address you gave. Often the same company as the line above and not always, because a diary and a mailbox can live in different places. They already hold your calendar; we connect to it.
• Your contacts provider, where the mailbox has an address book: Microsoft, for the Outlook contacts of a Microsoft 365 mailbox, Google, where you have connected your Google contacts, or whoever runs the CardDAV server whose address you gave, which is often the company that hosts the mail and not always. They already hold your contacts; we look them up there, write there only when you ask, and keep none.
• Your AI provider, being whoever supplies the assistant you connect. Content you ask it to work with reaches them.

We do not sell, rent or share personal data with anyone else. If we are ever legally compelled to hand something over, we will tell you unless we are prohibited from doing so.

Transfers outside the UK

3 of the providers we choose handle personal data outside the UK, and each transfer has a basis in UK data protection law:

• Stripe: card details and the payment record, in the United States and the European Union, under Stripe's own transfer mechanism.
• Brevo, hosted in France and Belgium: the emails the service sends, including a support request's emails. UK law approves transfers to every country in the European Economic Area, both of those among them, as the Information Commissioner's Office sets out.
• Cloudflare, in the United States: a support request sent from the control panel. Cloudflare is certified to the UK Extension to the EU-US Data Privacy Framework, which UK law approves, and its entry on the register shows it. If that ever lapsed, its data processing agreement uses the EU's standard contractual clauses with the UK's addendum.

Each provider's own agreement also lets its group companies and suppliers process data in other countries where its service needs it, under the safeguards that agreement names. Everything we hold ourselves is in the United Kingdom. Your mail, calendar, contacts and AI providers are your own choices, and where any of them is outside the UK that is your arrangement with them rather than a transfer we make.

• The contents of your mailbox, your diary and your address book: not kept at all, so there is no period to give.

  Messages, events and contacts pass through the server in memory while a request is being served and are never written down (a contact stays in memory for about 10 minutes after it was last asked for, so the next question about the same person is quick, and is then forgotten). Everything below is about your account, not about your mail.

• Account details: until you close your account, then deleted, with 2 exceptions for an account that holds nothing.

  • An account whose address was never confirmed (no confirmation link came back, and no Google or Microsoft sign-in vouched for it) is deleted 30 days after it was created, without an email, because nobody has shown us the address is theirs to write to.
  • A confirmed account that has no mailbox is deleted after 90 days without a sign-in to the control panel; we email the address 14 days before, naming the date, and signing in or adding a mailbox keeps it.

  An account with a mailbox is never deleted for being idle, whether or not you visit the control panel, because your AI client uses it without you needing to. Nothing else is affected by either: an account with no mailbox holds no credential and no message.

• Mailbox credentials: until you remove the mailbox or close the account, then deleted. Revoking at your provider ends access immediately regardless.
• Calendar credentials: until you disconnect the calendar, remove the mailbox or close the account, then deleted. Disconnecting a Google calendar also hands the permission back to Google, so it stops appearing on your Google account page rather than sitting there unused.
• Address book credentials: until you disconnect the address book, remove the mailbox or close the account, then deleted. Disconnecting Google contacts also hands the permission back to Google, as disconnecting a Google calendar does. The contacts themselves were never kept, so there is nothing of them to delete.
• The record of each MCP call: 90 days, then deleted. The daily limit reads only the last 24 hours of it, because it is a rolling window rather than a counter emptied at midnight. The rest is there so the usage statistics and charts in your control panel have a period to plot, for the account and for each mailbox.

• The audit record of each MCP call: 400 days by default, then deleted, or the shorter period you have chosen for your account. Under Settings the account's owner can set it to any number of days from 90 to 400, and the record is pruned at that number.

  The one exception is the rows of a mailbox you have since removed, which are kept for the default 400 days, because the record outlives the mailbox and there is no longer an owner setting to read.

  This is a second, separate record: which tool ran, whether it worked, the IP it was called from, and, where a read raised one, the name of a warning sign (hidden text, an instruction aimed at the assistant, a program named as a document) as a short label, never the text it was raised on.

  A file downloaded through the server gets its own row naming the message it came from, and a batch of files uploaded gets one recording how many arrived; neither carries a filename, and neither carries the file. It never includes the contents of a message.

  It is kept longer than the one above because it is what a billing dispute is settled from, and the subscription is annual: a question about a charge made last March arrives after this March's renewal, so a year would delete the answer a few weeks before anybody asks for it.

  90 days is the least that still covers a charge, the statement after it and the time it takes anyone to ask, which is why nothing shorter can be chosen.

• Send-as addresses and signatures: until you remove them or close the account, then deleted.
• Routines you save: until you remove the routine, remove the mailbox or close the account, then deleted. Removing a routine here does not remove its scheduled task from your AI; the Routines tab offers the link that asks your AI to do that.
• People you invite: the address, name, level, cap and mailboxes of each person, until you remove them or close the account. A removed person's row is kept as removed, so that an old invitation link and an old connection stay refused rather than reading as new, and it goes when the account does.
• The domains your account has written to: recorded from the day Team Access is bought, kept while the account exists, then deleted with it. Never pruned by age, because pruning would make an old correspondent look new again to the first-time-domain alert. Domains only, never addresses.
• Who holds a claimed message: while the mailbox and the person named both exist, then deleted with either; a person removed from a mailbox has their rows on it deleted by the removal. Never pruned by age. It names a message and a person, never the message's contents.
• IP addresses: kept as part of the 2 records above and deleted with them, so 90 days for a sign-in attempt and, for an MCP call, 400 days or the shorter period the account's owner has chosen for the audit record.
• Payment records: as long as UK tax law requires us to keep accounting records.
• Support emails: up to 2 years, so we can see a recurring problem for what it is.
• A reviewer application: 2 years from the decision, then deleted, or sooner if you ask. 2 years because the programme runs in 12-month grants and somebody who applies again is usually somebody we decided on the year before, so the earlier application is the context for the next one.
• Server logs: a rolling 90 days, so each entry is discarded 90 days after it is written.

Under UK GDPR you can ask us to:

• tell you what we hold about you, and give you a copy;
• correct anything that is wrong;
• delete what we hold, where we are not required to keep it;
• restrict or object to how we use it;
• provide it in a portable form;
• stop sending you anything you did not ask for.

Email support@mailbox-mcp.com and we will respond within one month. There is no charge.

If you are unhappy with how we have handled your data you can complain to the Information Commissioner's Office at ico.org.uk. We would rather you told us first, but you are not obliged to.

The control panel at app.mailbox-mcp.com is a separate application and does use a cookie to keep you signed in, which is strictly necessary for it to work and needs no consent.

A link from this site into the control panel carries the page it was on. If you then create an account, the panel records that page once, as the row on where you came from says, and nothing else about your visit.

If analytics are ever added to this site, this section will name the provider, and consent will be asked for before anything loads.

When this policy changes, the reviewed date at the top of this page changes with it. If a change materially affects what we do with your data, we will email account holders rather than relying on you noticing a date.