Privacy policy.

Data controller

Who is responsible

BSolve IT Limited, trading as Mailbox MCP, is the data controller. We are registered in England and Wales, company number 04607330, registered office 5 Epping Close, Barton Seagrave, Kettering, Northamptonshire, NN15 6TR.

For anything on this page, write to support@mailbox-mcp.com. It reaches the person who runs the company.

What we collect and why

We do not buy personal data, we do not enrich what you give us from other sources, and we do not build a profile of you.

Your mail, specifically

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 four 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 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 fifteen minutes.

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. If you need a data processing agreement, ask.

Your calendar, and other people's

A calendar is a separate connection from the mailbox and it reaches data the mail permission does not. There are three 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 data, and Google's Limited Use requirements

Where you connect a Google calendar, 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 four 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 for, which here means answering your assistant's calendar 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.

Three permissions are asked for and all three are about the diary: which calendars the account has, free and busy time, and reading and writing events. None of them reaches your Gmail, your Drive or your contacts, and none is asked for. As with everything else here, calendar data is fetched to answer the thing you asked and is not copied into a database of ours. You can withdraw the permission from your Google account at any time, and disconnecting the calendar in the control panel hands it back rather than leaving it in place.

The token Google issues 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.

How it is protected

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 and for a calendar 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 or your diary, 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.

The part that needs no protecting

The strongest thing that can be said about your messages and your events 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, so there is no store of your mail or your diary 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 deletes its credential rather than retiring it.

Who else is involved

• Stripe takes payments. Card details are entered on Stripe's systems and never reach ours.
• Our hosting providers run the servers this site and the service sit on.
• 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 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

Some of the providers above operate internationally, so data may be processed outside the UK. Where that happens it is done under the transfer safeguards UK data protection law requires.

How long we keep it

• The contents of your mailbox: not kept at all, so there is no period to give. Messages pass through the server in memory while a request is being served and are never written down. Everything below is about your account, not about your mail.
• Account details: until you close your account, then deleted.
• 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.
• 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, then deleted. This is a second, separate record: which tool ran, whether it worked, and the IP it was called from. 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.
• Send-as addresses and signatures: until you remove them or close the account, then deleted.
• IP addresses: kept as part of the two records above and deleted with them, so 90 days for a sign-in attempt and 400 days for an MCP call.
• Payment records: as long as UK tax law requires us to keep accounting records.
• Support emails: up to two years, so we can see a recurring problem for what it is.
• A reviewer application: two years from the decision, then deleted, or sooner if you ask. Two years because the programme runs in twelve-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.

Your rights

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.

Cookies and analytics

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.

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

Changes to this policy

When this policy changes, the reviewed date below 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.