Why offboarding a member with MCP connections gets refused
Offboarding a member with MCP connections is refused while any of that member's personal connections is pinned into a toolbox entry. The refusal names the entries that block it. You resolve each one, and the removal completes.
The situation behind the refusal is ordinary. A finance analyst leaves on Friday. Their personal QuickBooks account is pinned into two toolbox entries, and three people in finance call those entries every day. A toolbox is a named set of tool entries shared with other members, and each entry points at one specific connected account. Remove the member without deciding about that account and you get one of two bad outcomes. Either the entries stop working in the middle of a month-end close, or a departed person's credential keeps serving tool calls with nobody accountable for it.
Two terms, defined once. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps A grant is the OAuth record that authorizes one member's AI client against the organization's MCP endpoint, where OAuth is the sign-in flow that issues that record instead of handing out a shared password.
What the removal cuts off on the next call
The removal cuts the member's live access to the endpoint. removing or suspending a member revokes every live grant in the same transaction as the membership change. The grant's revoked_at value is re-read from the organization store on every single call, with no cache, so the next call from that person's Claude, ChatGPT or Cursor session fails.
This is the one part of offboarding where "on the next call" is accurate. Role changes and restriction changes behave differently. Those resolve through a 60 second cache plus edge propagation, so they take effect within about two minutes, on the MCP endpoint, the console and the REST API alike.
What the removal does not touch is the credential itself. Connector credentials never live in Elaichi. A separate credential service holds per-account secrets, encrypted at rest, and owns token refresh. Removing a membership does not log anybody out of QuickBooks. It stops the organization's MCP endpoint from reaching that account on the departing member's behalf.
Why one endpoint removes half the problem
Elaichi serves every connected account through one organization-wide MCP endpoint at POST /mcp. There are no per-toolbox URLs and no embedded tokens, so there is nothing per-user to hunt down on somebody's last day.
There is no MCP server to create, list or revoke per member. The address is fixed, and the grant is what varies. Across the 450+ in the catalog, that stays true. Claude, ChatGPT, Cursor and the Elaichi Agent all point at the same address and sign in. Revoking one grant closes every client that person used, which is a shorter checklist than chasing a server URL per team or per person.
What the offboarding preflight checks
The offboarding preflight sorts the departing member's personal connections into two piles. Unreferenced personal connections are cleaned up along with the membership, with no decision required from you. Personal connections referenced by a toolbox entry must be resolved first, or the removal is refused.
The preflight is deliberately not clever about the choice. It does not pick a new owner, because both defaults are wrong. Deleting everything takes a working shared entry away from a support shift, and the first person to notice is an agent whose tool call fails in front of a customer. Keeping everything silently leaves an unowned credential sitting in the path of an AI client. Naming the blocking entries and stopping is the only behavior that does not make a credential decision on your behalf.
The four ways to resolve a pinned connection
A referenced personal connection can be transferred to the organization, transferred to a team, transferred to another member, or deleted. Each carries a different trade-off.
Transfer to the organization. Right for a shared login that was only ever personal by accident, such as a billing portal or a vendor account. Ownership moves to the organization, and access still runs through resource grants of view, use or edit. A member sees only what they own or what was explicitly shared with them. No organization-level permission silently widens that listing, org owners and admins included.
Transfer to a team. Narrower, and usually the better answer. The finance team owns the finance accounts, and the pinned entry keeps working for exactly the people who were already using it.
Transfer to another member. Keeps the account personal and accountable to one name. Worth one check first. If your SaaS offboarding disables the leaver's user inside the third-party app, the stored refresh will eventually fail. A failed refresh marks the connection needs_reauth rather than failing silently, so the new owner reconnects instead of debugging a mystery.
Delete it. Correct when the account was genuinely personal to the person leaving. The affected toolbox entries then get re-pinned to an account whose owner is still in the building, often a shared company login held by a team rather than an individual.
One thing no option gives you is the secret. Read-back of an account's configuration returns public values plus secret_paths, the list of dot-paths that were encrypted, carrying none of their values. Editing one is refused. Nobody moves a token by hand during offboarding, because nobody can read it.
Why a private connection cannot be transferred
A private connection is not transferable. Not to the organization, not to a team, not to another member. A credential only its owner could ever use does not become somebody else's because its owner left.
That leaves one path. Delete the private connection, then re-pin the affected toolbox entries to an account the new owner can authenticate as themselves. It is more work than a transfer, and it is the correct amount of work. The alternative is an organization that quietly inherits logins nobody chose to inherit, which is the thing a reviewer asks about six months later. The free read-only Auditor seat exists so that reviewer can read the record without costing a license.
Delegated toolbox entries are a warning, not a block
Delegated toolbox entries surface as a non-blocking warning during offboarding. They do not refuse the removal. They are flagged so you know which entries need a new pin, and re-pinning is the fix rather than a credential decision.
The console gives you two lists on the same screen with two different meanings. One blocks until you resolve it. The other is a to-do item you can clear after the person has gone. Reading them as the same list is how a shared entry ends up pinned to nothing.
The order of operations on the last day
Run these in order, and the last day stops being a scramble.
- Suspend first if the timing is uncertain. Suspension revokes every live grant in the same transaction, exactly as removal does. Suspended members are also excluded from the billable seat count. You get the access outcome on the day and keep the ownership decisions for a calmer hour.
- Open the removal and read the preflight. It lists the personal connections that toolbox entries reference. Nothing else is blocking you.
- Decide a new owner per connection, not per person. Some accounts belong to a team, some to the organization, and some to one named successor.
- Handle private connections by deleting and re-pinning. No transfer exists for them, so the entry needs a different account.
- Clear the delegated-entry warnings. Re-pin those entries to the accounts you settled in step 3.
- Complete the removal. Unreferenced personal connections are cleaned up with the membership.
- Finish inside the third-party apps. Elaichi stops the endpoint reaching an account. It does not deprovision somebody's Salesforce or Zendesk user for you.
- Read the audit log for the last two weeks, filtered by actor. You are looking for tool calls nobody expected, not for a clean bill of health.
If your identity provider drives Elaichi membership over SCIM v2, which provisions users and groups automatically, make the ownership decisions before the deprovision event rather than after it. The connection questions are easier to answer while the person is still reachable on Slack. A standing habit helps more than any runbook: pin shared toolbox entries to organization-owned or team-owned accounts, and most departures then have nothing to resolve.
What the audit log keeps once the member is gone
The audit log keeps the record of everything that member's AI client did, because it is append-only. Removing somebody does not scrub their history, and that is the design rather than a side effect.
There is one entry per tool-call attempt, succeeded or failed, and both name the account. The recorded connection is the account actually reached, taken from the execution rather than from the intent, which answers "which of our two Notion workspaces did the agent write to". Each record carries the operation and tool, the connection, the classification, whether the call was approved, the outcome, and an error code only. Argument names and counts are logged. Argument values never are.
actor_kind is a recorded field rather than something inferred later, and its values include user, system, staff, scim, api_token and ai_assistant. A departed member renders as "Former member" instead of disappearing from the trail. The log is newest-first, cursor-paginated and filterable by free text, category, actor, action kind and time. It is eventually consistent, so a row from the last few seconds may take a moment to appear. Export forwards to your own destination, with Datadog implemented, and Splunk HEC and Microsoft Sentinel accepted but not yet delivering.
One honest limit. Organization deletion tears down the workspace but has no path to purge the organization's log tenant, and it says so by returning the residue by name. If your retention policy needs total removal of one person's records, raise it on /contact/ before you write the policy.
When none of this applies to you
If nobody shares a connection, none of the refusals above will ever fire. One person connected two apps to their own AI client, no toolbox entry points at anyone else's account, and offboarding is removing the membership and then revoking access inside each SaaS by hand. At that size a control plane solves a problem you do not have yet, which the case for holding off on an MCP gateway sets out in full.
The refusals start mattering the moment one person's account is doing work for three other people. That is also when the short-notice version shows up, and what to do about contractor AI access today covers it. For what a team's accounts look like once they are shared properly, browse the connector catalog or the per-team setups. More on the wider subject sits under governance.
