Team 3
£10.00 a month Per account, paid annually at £119.99 + VAT
- 3 named people, across every mailbox on the account
- Own connector URL and permission level per person
- Own daily cap per person, set by you
- Remove a person in one action
For teams
Your shared inbox, worked by Claude or ChatGPT, with the controls a team needs.
Shared inbox AI for teams, on the mailbox you already own: put named people on it, and each of them works it from their own Claude, ChatGPT or any AI that speaks MCP, with their own connection, at a level and a cap you set, and every call they make is recorded under their name, a per-person audit line. On a Claude Team or Enterprise plan they sign in through your own identity provider and never see a consent screen. This page is what a team gets. Connecting your own mail? See everything it can do.
- Sign-in Single sign-on, Okta today
- People 3, 5 or 10 per account
- From £119.99 + VAT a year
Single sign-on
Sign in through your own identity provider: single sign-on for Claude Team and Enterprise
A Claude Team or Enterprise administrator enables Mailbox MCP for the organisation once, in the Claude admin console, and from then on each person opens Claude and the shared mailbox is there. No password is typed here, no consent screen is shown and no Connect button is pressed. Claude presents this server with an identity assertion, a signed token from your identity provider vouching for who the person is; the server verifies it and issues that person a connection to the mailbox they already hold on our side, at the level its owner already set. One connection per person, renewed in place at each exchange, so the mailbox's Connector tab shows one line for them rather than a fresh one every hour.
For IT, single sign-on for Claude Enterprise connectors, and for Claude Team ones, which is the plan this was verified on, is provisioned and revoked where everything else is. Okta is the identity provider it works with today: a person is let in because Okta signed for them, the access token lasts an hour with no refresh token, and so removing the person in Okta ends their access at the next exchange, within the hour, with nothing to do on our side. Removing them under People ends it at the next call. It needs a Claude Team or Enterprise organisation whose members sign in through Okta, and Team Access here. The account's owner enters the Okta issuer URL under Settings and switches single sign-on on; the server fetches that issuer's discovery document as the setting is saved, so a mistyped URL is caught there rather than at somebody's first call.
Single sign-on never adds a person to a mailbox, never widens a level and never reaches a mailbox that has not been shared. It replaces the sign-in and the consent screen, and nothing else. The set-up, 7 steps across Okta, the Claude admin console and our control panel in the order they were taken, is on the Claude.ai page for administrators.
Verified, and when
Verified live on 15 September 2026: a Claude Team organisation signing in through an Okta organisation, set up as the administrators' section of the Claude.ai page describes; Claude's own connection test passed all 4 of its steps against this server, and a member's chat read a mailbox with no consent screen. Before that, on 14 September, Okta's Cross App Access playground and the server's own tests.
Your identity provider
Okta today
signs the person in
Claude
Team or Enterprise organisation
presents the identity assertion
Mailbox MCP
one connection per person, renewed in place
opens exactly the mailboxes they were given
The mailbox
Outlook, Gmail or IMAP
Anthropic announced the flow on , under the name enterprise-managed auth, and its post names the connectors that supported it on the day:
Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase support Enterprise-managed auth at launch, with Slack coming soon.
Anthropic, Centrally manage authorization for MCP connectors
Read that list for what it does not contain. Every connector on it is a project, design, notes or data tool, and the one to follow is chat. The update the same post carries, dated , adds Datadog, Notion and Slack, with Exa, Miro and Zoom to follow. None of those is an email connector, and email is the tool a team's outside world actually arrives through. The post also says Okta is the identity provider supported at launch, with others to come, which is why this page says Okta today. On this server passed Claude's own connection test for the flow, all 4 of its steps, from a Claude Team organisation signing in through Okta, and a member's chat then read a mailbox with no consent screen. That is the dated fact, and it is the whole of the claim: a Claude Team or Enterprise organisation can now give its people a shared mailbox the way it gives them Linear or Figma, enabled once by an administrator and simply there on first use, which Anthropic's page for connector developers describes as a user who "never sees a browser redirect or a consent screen". The difference is what is on the other end of it: a mailbox, with a level and a limit its owner set, on a server that keeps no copy of the mail.
People
People on a mailbox they do not own, each with their own connection
Since a mailbox on Pro, on Microsoft 365, Google Workspace or any IMAP host, can be shared with named people. You invite a person by email address from the People tab, choose which of your mailboxes they may reach, and set 3 things for them: a permission level, whether the calendar is included, and a daily cap. Each person then gets their own connector URL, one per mailbox they are on, which they paste into their own AI client. Nothing of yours is shared with them: not your password, not your token, not your connection. A person on 3 of your mailboxes is one seat.
An invitation is bound to the address it was sent to. It is accepted only by an account whose verified email address is the invited one; a forwarded link does not work for anybody else, and the refusal names the account that is signed in and shows the invited address in masked form. Once accepted, every call the person makes carries their name in the activity record, an audit line per person, so the log on a shared mailbox says who did what rather than only what was done. Level, calendar, cap and display name are changed from the People tab and land on every mailbox the person is on at once, on their next call, without anybody reconnecting.
So a colleague, an assistant or a contractor works your shared inbox from their own Claude or ChatGPT, on their own connection, and the mailbox stays yours.
Claims and approvals
Claim it, get it approved, send it: a shared inbox with a second pair of eyes
Every mailbox on a Team account registers 6 tools that a mailbox on an account without a tier never sees. They exist so that 2 colleagues, each with their own assistant, do not both answer the same message, and so that a person who may not send from the mailbox can still get a reply out through you.
Claims: who is dealing with which message
Claim a message, or a set of them, so colleagues sharing the mailbox know somebody is dealing with it and nobody answers it twice. Hand a message to a named colleague. Release a claim when it is done. Every listing on a Team mailbox says who holds each message, and a reply, forward or draft reply to a message somebody else holds opens with one sentence naming them and still does the work: it is information, not a refusal. The claim is a keyword on the message in the mailbox itself, set by the mail server, so it survives the assistant, the session and the connection and vanishes with the message if the message is deleted; who holds it is a record of ours naming the mailbox, the folder, the message and the person, never a subject, an address or a line of the message.
claim_emailrelease_emailassign_email
Approvals: a draft waits for the owner to send it
A person whose connection may draft but not send writes the reply as a real draft in Drafts and marks it as waiting for the owner. The owner's assistant lists every draft waiting, newest first, with who asked, when, the recipients, the subject and a preview, and sends the one the owner approves through the ordinary send path: one Sent copy, the draft's own attachments and threading, and the draft removed from Drafts the way a mail client removes one it has sent. A draft nobody asked about is refused. Sending a draft back for changes is an ordinary email from the owner to the person; there is no tool for it.
request_approvallist_pending_approvalsapprove_and_send
So "who is answering this one" is written on the message itself, and "can I see it before it goes" is a step in the mailbox, where the owner can approve before sending, rather than a habit you hope people keep. The Team Access guide walks through a claim and an approval end to end.
Per person
The owner sets each person's ceiling: read, draft or send
Each person carries one of the same 3 permission levels every connection on this site carries, Read only, Draft and file or Send and delete, with the calendar on or off beside it, and their own daily cap. A person at Read only is never handed the send tool, so their assistant cannot ask for it; a person at Draft and file writes the reply and puts it up for approval; only Send and delete sends. Shared mailbox permissions are set per person, from the People tab, and obeyed on that person's next call.
Above every person sits the mailbox's own limit, set on its Connector tab. No person can be given more than it, and a person set above it is capped to it, which the People tab says beside their name. Lower the limit and every person above it is capped on their next call; raise it again and each gets back exactly what you chose for them, because nothing is rewritten. A person who arrives through single sign-on gets the same level, from the same share, decided here and never by the assertion.
So one colleague can read the shared inbox, another can draft, and a third can send, on the same mailbox, and the most any of them can do is a setting only you can reach.
Account security
A second factor for everyone, held at the door until they have one
One switch under Settings, Security requires a second factor of everyone on the account. While it is on, a person without a confirmed authenticator can do nothing in the control panel but set one up, sign out or close their own account; they cannot accept an invitation onto your mailboxes until they have one, and the invitation link stays live until then; and every AI connection they made is refused on its next call until they do. The People tab says so beside their name, in the card above: a chip reading No second factor and the sentence that their AI connections are refused until they set one up.
You cannot lock yourself out with it. The switch cannot be turned on until your own authenticator is set up, and yours cannot be turned off while the switch is on. A person the gate is holding can still list the shares they hold and leave one, since , because the accepted share is what gates them and leaving it is what lifts the gate. A mailbox's pasted access token is the mailbox's credential rather than a person's sign-in and is not affected.
So the account every person's access hangs off is one that needs more than a password to enter, for every person on it, and a colleague who has not set that up is held at the door rather than waved through.
What you are told
The 2 owner alerts: the Monday digest and the first-time-domain alert
Both are emails, both are on unless you turn them off under what we email you about, and neither holds anything back: they are information an owner cannot get by reading their own mailbox, because the sends were made by somebody else and the Sent folder does not say who.
- The Monday digest. Every Monday at 08:00 London time, an owner with somebody active on a mailbox gets one email: per person, the sends, filings and reads over the last 7 days, and the drafts waiting for approval across the shared mailboxes.
- The first-time-domain alert. The first time a shared person sends to a domain the account has not written to since Team Access began, through any mailbox, you are emailed once: who, which mailbox, the domain and the subject. Your own sends never alert; they only teach the account which domains it knows.
So the 2 things an owner of a shared inbox actually wants to know, what each person did this week and whether somebody has written to a stranger, arrive in your inbox rather than waiting in a screen.
Metering
An allowance that grows with the team
A Pro mailbox has up to 1,000 MCP calls a day, counted over a rolling 24 hours. Sharing it does not divide that between people: it grows by 1,000 for each person entitled on the mailbox. The allowance is 1,000 multiplied by 1 plus the number of people active on it, so a Pro mailbox shared with 2 people has 3,000 calls a day between the 3 of you. A parked or paused person does not count.
You can cap any one person lower than that. A cap is a figure you set per person from the People tab; it applies on each mailbox they are on, and a person who reaches theirs is told so in a sentence their assistant can relay: that the mailbox itself still has capacity, and that the owner can raise their ceiling. Sharing is on top of Pro: a mailbox that is not on Pro cannot be shared, and if Pro lapses on a shared mailbox the people stay attached and the mailbox drops to 5 calls a day between everybody on it until Pro is bought again.
So adding a person to a shared mailbox adds their share of the work to its allowance, and never takes any of yours.
- A Pro mailbox, the owner alone 1,000 calls a day
- Shared with 1 person 2,000 calls a day
- Shared with 2 people 3,000 calls a day
Coming and going
Leaving, removing, and what happens to the connection
Removing a person is one action. Every share they held and every connection they made end together, each connection refused on its next call, and they are emailed to say so. Pausing a person is the same control without the email, and resuming them takes one seat check. A person who is not entitled, because the tier lapsed, you downgraded, or you paused them, is refused with a plain sentence in the control panel and an opaque refusal in their AI client; nothing of theirs is deleted, and a tier that covers them again seats them without re-inviting.
A person can leave a share themselves, since : leaving ends the share exactly as your revoke ends it, every connection under it ended in the same moment and its connector URL refused on the next call, with the seat offered to whoever is parked. Over single sign-on there is a second door, and either one closes it: removing the person at your identity provider ends their access at the next exchange, within the hour, and removing them under People ends it at the next call. Closing your own account stops the Team Access renewal with it, since , rather than leaving a subscription running for an account that no longer exists.
So a person's access ends when you say, or when they say, or when your identity provider says, and never carries on because somebody forgot to press something.
Browser clients
From a browser-hosted client too
Since server version 1.11.0, on , the MCP endpoint itself answers a browser's CORS preflight, so an AI client that runs in a browser, the MCP Inspector's browser transport, Okta's Cross App Access playground or a web-hosted agent, can connect a shared mailbox as a desktop one does. Until then such a client could discover the server and mint a token and then not connect. Claude, ChatGPT and Claude Code call from their own backends and never send an Origin header, so nothing changed for them; the changelog entry lists the headers and the methods the preflight allows.
What it costs
What it costs: 3 tiers, bought once for the account
A tier is a number of named people. Each may be given their own connection to any Pro mailbox on your account, and one person on several mailboxes is still one person.
Team 5
£16.67 a month Per account, paid annually at £199.99 + VAT
- 5 named people, across every mailbox on the account
- Own connector URL and permission level per person
- Own daily cap per person, set by you
- Remove a person in one action
Team 10
£33.34 a month Per account, paid annually at £399.99 + VAT
- 10 named people, across every mailbox on the account
- Own connector URL and permission level per person
- Own daily cap per person, set by you
- Remove a person in one action
Mailboxes are bought per mailbox. People are bought once, for the account. A tier includes no mailbox: every mailbox you share stays on Pro at £34.99 + VAT a year, and the tier sits on top. Moving up or down between tiers is immediate and prorated, cancelling runs to the end of the paid year, and a full refund of the year ends the tier the same day. The Team Access pricing page has every case, and the refunds policy the 14-day right.
For IT
For IT: hosting, encryption, audit retention and the DPA
The 4 answers a security questionnaire asks for first, each with the page that gives it in full.
- Servers run by us, in London, United Kingdom
- Every stored credential AES-256-GCM, its own key
- Audit record kept 400 days by default, 90 at the least
- Data processing agreement a page, part of the terms
The servers are run by us, in London, and nothing that holds customer data is hosted outside the United Kingdom except payment, which is Stripe's. Every stored credential is encrypted with AES-256-GCM under its own random key, wrapped by a master key held outside the database and outside the source code; the server keeps no copy of your messages. The audit record of each call is kept 400 days by default, or the shorter period from 90 days the account's owner has chosen, and it holds the fact of the call and never its contents. The data processing agreement is a page, incorporated into the terms, so it applies to every business customer without anything being signed. The page for IT answers the questionnaire in the order it asks, the security page sets out what is held and what is not, and the DPA is the agreement itself.
Okta, on becoming a featured identity provider for Claude on , put the administrator's side of single sign-on in one sentence:
This enables IT admins to authorize MCP connectors once for their organization, scope access by Okta groups or roles, and revoke access through Okta when users or deployed agents are offboarded.
Okta, Okta becomes a featured identity provider powering secure AI agent connections for Anthropic's Claude
That is exactly the shape of it from Okta's side, and the half of the sentence to hold on to is the last one: revoke access through Okta. On this server a person let in that way holds an access token for an hour and no refresh token, so the revocation Okta describes lands here at the next exchange with nothing for us to do. What Okta's sentence does not decide, and cannot, is which mailbox the person reaches and how far. Scoping by group or role says who may use the connector; the share under People says which mailbox that person holds here and at what level, and an assertion for somebody with no share mints nothing. So IT keeps the door, the mailbox's owner keeps the room, and neither can widen what the other set.
Limits
What it deliberately does not do
A feature list that admits nothing is a feature list nobody believes. These are the ones a team is disappointed by, listed before you invite anybody rather than after.
-
No Exchange shared or delegated mailboxes
A Microsoft 365 shared or delegated mailbox, the kind with no sign-in of its own that Outlook reaches through Full Access or Send As, cannot be connected. A mailbox you own can be shared with named people through Team Access, which is a different thing: each person gets their own connection at a level you set. A shared CALENDAR is different again and is supported on Microsoft 365: one that has been shared with you can be read, and written to where the person who shared it allowed that.
-
Claims need a server that accepts keywords
A claim on a message and an approval request on a draft are IMAP keywords in the mailbox itself, and a mail server may refuse new keywords: one whose PERMANENTFLAGS for the folder lacks \* drops them. On such a server the Team tools say claiming or approval is unavailable and store nothing; every other tool works as it did. Nobody has yet opened a claimed message in a mail client; the expectation is that Outlook shows nothing for a custom keyword and Thunderbird shows one as a tag, and the mail-client check settles it.
-
Nothing of yours is kept
Stored credentials are encrypted at rest with AES-256, and the server keeps no copy of your messages.
-
Every mailbox has a ceiling
Every mailbox has a daily ceiling on MCP calls: 5 a day on Free and 1,000 a day on Pro, per mailbox, in any rolling 24 hours. A Pro mailbox shared through Team Access grows by 1,000 for each person active on it, so one shared with 2 people has 3,000. Pro is a published limit, not an unlimited plan.
Out-of-hours alerts and behavioural alerts are deliberately not built: the 2 alerts above are the ones an owner cannot get by reading their own mailbox, and a system that guesses at a person's intent from the shape of their day is not one we want to run over your colleagues. Single sign-on works with Okta today and with no other identity provider yet, and it needs a Claude Team or Claude Enterprise plan; a free or Pro Claude plan connects through the consent screen as one person does. The tool reference lists what each of the 6 Team tools refuses, and the security page what you can limit per person.
Questions
Questions teams ask
Does it support single sign-on?
Verified live on 15 September 2026: a Claude Team organisation signing in through an Okta organisation, set up as the administrators' section of the Claude.ai page describes; Claude's own connection test passed all 4 of its steps against this server, and a member's chat read a mailbox with no consent screen. Before that, on 14 September, Okta's Cross App Access playground and the server's own tests. It works today with Okta as the identity provider, and it needs a Claude Team or Enterprise plan, because those are the plans on which a Claude administrator can enable a connector for the whole organisation with managed authorisation. The account here needs Team Access, since single sign-on lets the people on the account in and people on an account are what Team Access provides. Each person then gets their mailbox in Claude with no sign-in here and no consent screen, and their access ends when they are removed at the identity provider or under People.
Do I have to make a new inbox or move my email?
No. There is no inbox product to move into: the mailbox you share is the one you already own, on Outlook, Gmail or any IMAP host, on Pro at £34.99 + VAT a year. Your mail stays where it is, your own mail client sees exactly what it saw before, and the people you invite reach that mailbox through their own AI client. Only a mailbox on Pro can be shared, and the control panel says so if you try to share one that is not.
Can I make somebody get approval before an email is sent?
Yes. Give the person the Draft and file level and they cannot send at all: their AI client is never handed the send tool. What they can do is write the reply as a real draft in Drafts and mark it as waiting for you with request_approval. Your own assistant lists what is waiting with list_pending_approvals, newest first, with who asked, when, the recipients, the subject and a preview, and sends the one you approve with approve_and_send through the ordinary send path: one Sent copy, the draft's own attachments and threading. A draft nobody asked about is refused. The claim tools, claim_email, release_email, assign_email, are the other half: they stop 2 people answering the same message.
Can each person be limited differently?
Yes. Each person carries their own permission level, Read only, Draft and file or Send and delete, with the calendar on or off beside it, and their own daily cap, all set by the owner from the People tab and applied on the person's next call without anybody reconnecting. Above every person sits the mailbox's own limit, set on its Connector tab: no person can be given more than it, and a person set above it is capped to it, which the People tab says beside their name. So one colleague can read the shared inbox while another drafts and a third sends, on the same mailbox.
What does the owner see?
Every call any person makes to a shared mailbox is a row on the Activity tab under that person's name: when, which tool, which mailbox, whether it worked, how long it took and where it came from, and never the contents of a message. On top of that, 2 emails. Every Monday at 08:00 London time, an owner with somebody active on a mailbox gets one digest: per person, the sends, filings and reads over the last 7 days, and the drafts waiting for approval across the shared mailboxes. And the first time a shared person sends to a domain the account has not written to since Team Access began, through any mailbox, the owner is emailed once: who, which mailbox, the domain and the subject. The owner's own sends never alert; they only teach the account which domains it knows.
How many people, and what does it cost?
A tier is 3, 5 or 10 named people, bought once for the account, from £119.99 + VAT a year. One person on several of your mailboxes is still one person. It sits on top of Pro on the mailboxes themselves, £34.99 + VAT a year per mailbox, and it includes no mailbox: mailboxes are bought per mailbox, people once for the account. Moving between tiers is immediate and prorated, cancelling runs to the end of the paid year, and the pricing page for teams has every case.
Can I require a second factor of everyone?
An account's owner can require a second factor of everyone on the account, with one switch under Settings, Security in the control panel. While it is on, a person on the account without a confirmed authenticator can do nothing in the control panel but set one up, sign out or close their own account; cannot accept an invitation onto the account's mailboxes until they have one, and the invitation link stays live until then; and has every AI connection they made refused on its next call until they do, at the mailbox's connector URL and at the base URL alike. The switch cannot be turned on until the owner's own authenticator is set up, and the owner's authenticator cannot be turned off while the switch is on. A mailbox's pasted access token is the mailbox's credential rather than a person's sign-in and is not affected.
Attribution
Sources
- Anthropic: centrally manage authorization for MCP connectors The announcement of enterprise-managed auth, 18 June 2026, and the sentence naming the connectors that supported it at launch, quoted above. Read 15 September 2026.
- Okta: Okta becomes a featured identity provider powering secure AI agent connections for Anthropic's Claude The press release of 18 June 2026 and the sentence on what IT administrators can do from Okta, quoted above. Read 15 September 2026.
- Anthropic: Enterprise Managed Auth for connectors The page for connector developers: the identity assertion, the JWT bearer grant of RFC 7523, the plans it is available on, and the phrase on the user never seeing a redirect or a consent screen. Read 15 September 2026.
- Anthropic help centre: Okta SSO setup Claude's own single sign-on with Okta, which the flow above relies on: the plans it applies to and the domain verification it needs. Read 15 September 2026.
The verification is ours, and it is dated in the section it belongs to: the flow was walked on on a real Claude Team organisation signing in through a real Okta organisation, and the day before on Okta's Cross App Access playground and the server's own tests. The changelog dates every release named on this page, and the Claude.ai page carries the set-up step by step.
Keep going
Read next
Invite the first person from the People tab.
Connect a mailbox, buy a tier on the Billing screen, and the invitation takes an address, a level and a cap. Nothing of yours is handed over.