A contractor's last day was Friday. On Monday somebody in IT asks whether their AI access is gone. The answer was settled months earlier, by whoever configured the first MCP client, and nobody treated it as a decision at the time. MCP connection token vs OAuth grant is the short form of that question. One is a string a person holds. The other is a record your server reads before it does anything.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps Both credential shapes sit underneath it. Both behave identically on the day you configure them. They come apart on the day somebody leaves, and on the day you are asked to prove they left.
What is the difference between a connection token and an OAuth grant?
| Axis | Long-lived connection token | OAuth grant resolved per call |
|---|---|---|
| Revocation latency | Rotate the string, then chase every copy of it | Effective on the next call in Elaichi; revoked_at is re-read from the org store with no cache |
| Sharing risk | Possession is authority; the issuer cannot enumerate copies of the string | The grant is a server-side record, so a copied client config still resolves to the same identity |
| One user, many clients | Zapier's own guidance is a separate server and token per member, so token count tracks the client count | Same endpoint URL across Claude, ChatGPT and Cursor; one OAuth sign-in per client, one grant behind it |
| Offboarding | Inventory exercise across CI stores, shell history, shared docs and personal machines | Preflight refuses removal until personal connections referenced by a toolbox entry are transferred or deleted |
| Blast radius on a leak | Every tool the token was scoped to, until the string is rotated everywhere it was pasted | Bounded by role, restrictions and scopes; a leaked client session stops at the next call after revocation |
A connection token is a bearer credential. Possession is authorization, so whoever holds the string can run the tools behind it. An OAuth grant is a server-side record of access, checked by the server on each call. OAuth is the sign-in flow that lets a client act for a user without holding the user's password, and the grant is the record that flow creates.
The difference that matters is where authority lives. With a bearer token, authority travels with every copy of the string. The issuer does not know how many copies exist, or where they sit. Revocation means rotating the token and hoping nothing legitimate was pointed at the old one. With a grant, authority stays on the server. Revocation is a state change, and the only open question is how quickly the server notices it.
That last question is the one to put to any vendor. A grant cached for an hour behaves like a token for an hour. Ask how the revocation flag is read, and ask whether it is cached.
How does Zapier MCP issue each one?
Zapier documents both paths, and the split is by client type rather than by preference. For most MCP clients the member adds Zapier as a connector and signs in inside the client, and Zapier creates and configures the server during that sign-in. Clients not on Zapier's list, and code you write yourself, use a connection token instead. Zapier describes that token as long-lived, tied to one server, and says it grants whoever holds it the ability to run the server's tools. Its documentation says never to distribute one and to treat it like a password. The endpoint at mcp.zapier.com is not itself a credential. Sources: Zapier MCP quickstart and how connections work, checked September 2026.
So the precise statement is this. Connection tokens are documented for code-based and unlisted clients. Most clients sign in with OAuth. Anyone writing that Zapier MCP is token-based across the board has read one page and not the other.
For an organization rollout, Zapier's guidance is to give each user their own server and token rather than sharing one, with each member signing in and running tool calls as themselves. Admins can restrict members to a Zapier workspace, and account-level app and action restrictions apply through MCP. Source: Zapier MCP rollout overview, checked September 2026.
Why is a long-lived string hard to take back?
Because you cannot enumerate the copies. A token that works in a script works in a second script, in a teammate's shell history, in a CI secret store, and in a config file that got committed once and reverted. None of those copies report back.
That is not a criticism of bearer tokens. It is the definition of them, and it is why Zapier's own documentation tells you to treat one like a password and never to distribute it (Zapier MCP security, checked September 2026). The operational cost is that offboarding becomes an inventory exercise. You have to find the string before you can rotate it, and finding it is a search across systems you do not control.
One thing is not established in public documentation: what happens to a member's server when that member leaves the Zapier account. The security page does not say. That is a question to put to the vendor before a rollout, not a gap to assert.
What does an OAuth grant carry that a token does not?
A grant carries an identity and a set of scopes, so the server decides per call instead of per string. Elaichi checks four OAuth scopes on the endpoint: mcp:read, mcp:write, mcp:destructive and mcp:tools. A tool classified forbidden is reachable under no scope at all. mcp:tools does not replace the ladder, so a connected tool whose method is a delete still needs mcp:destructive.
Ahead of every scope sits a permission. tool:execute gates the whole endpoint. Without it the tool listing comes back empty, and a call returns an in-band error naming the permission. Guest, Auditor and Billing Admin do not have it. A permission here is one of the action strings grouped into a role under role-based access control, and each member in Elaichi holds exactly one role.
Be clear about what a grant does not do. The prompt-injection write gate in the Elaichi agent window does not apply to POST /mcp, and cannot, because an MCP server never sees a user prompt. What holds on the endpoint is per-operation permissions, the forbidden classification, output redaction, scope limits and full audit logging. A grant is a better credential than a bearer string. It is not a content filter.
What happens when you remove somebody from the organization?
In Elaichi the access stops on the next call. This is because removing or suspending a member revokes every live grant in the same transaction as the membership change. The revoked_at flag is re-read from the organization store on every single call, with no cache.
Do not generalize that to the rest of the access model. Role membership and restrictions resolve through a 60 second cache plus edge propagation. A role change or a restriction change takes effect within about two minutes, on MCP, the console and the REST surface alike. Two minutes is the right number to quote to a security reviewer, because it is the true one and because the reviewer will test it. Restrictions themselves target a role or a user. There is no organization-wide rule, and the absence of any rule means allow-all.
The address model is what makes removal workable at company scale. Elaichi serves 450+ connectors through one organization-wide MCP endpoint, POST /mcp, behind OAuth. There are no per-toolbox URLs, no embedded tokens, and no per-user server to track down and delete. Claude, ChatGPT, Cursor and the Elaichi Agent all point at the same address, and the grant is the thing that varies per person.
Offboarding also has a preflight, and it is deliberately not silent. Personal connections referenced by a toolbox entry must be resolved first: transferred to the organization, a team or another member, or deleted. Otherwise the removal is refused. Unreferenced personal connections are cleaned up. A private connection is not transferable at all, because a credential only its owner could ever use does not become somebody else's when its owner leaves. Delegated toolbox entries surface as a non-blocking warning, and re-pinning is the fix.
MCP connection token vs OAuth grant: what the audit trail shows afterwards
Revocation answers what happens next. The audit trail answers what already happened, and the two credential shapes leave different evidence.
A bearer token identifies the server it belongs to. If one token is shared between two scripts, the trail attributes both calls to that one server, and the person behind a call becomes an inference from IP addresses and timing. Zapier's History tab shows user-level activity logs for tool calls under its per-member model, and enterprise SAML SSO extends to MCP access (Zapier MCP security, checked September 2026).
In Elaichi the record is written per attempt. one entry per tool-call attempt, succeeded or failed, and both name the account actually reached, taken from the execution rather than from the intent. That matters the first time somebody asks which of two Notion workspaces the agent wrote to. The field actor_kind is recorded rather than inferred. Its values include ai_assistant, so an AI-initiated action is known at the point of action. The operation, the tool, the connection, the classification, whether it was approved and the outcome are all recorded. Argument names and counts are logged; argument values never are.
The error text is split on purpose. The string returned to the caller is derived from the third party's response body and is written nowhere else. The string written to the audit trail is never derived from the request or the response, because audit records are org-visible, readable by the in-product assistant, and forwarded to whatever destination the customer configures.
The trail is append-only, newest-first and cursor-paginated, with one log tenant per organization. A departed member renders as "Former member" rather than disappearing from the record. The read-only Auditor seat is free, so a compliance reviewer does not consume a license. Rows are eventually consistent, so one may take a moment to appear.
When is a connection token the right answer?
When one person is writing one script against their own accounts. A bearer token is the simplest thing that works, the blast radius is one human, and the revocation story is rotate it and tell nobody, because nobody else has it. Adding a control plane to that is work with no return.
The same holds for a prototype, for a client that is not on any vendor's supported list, and for a team of three where everyone can see everyone's config. If nobody has left yet and nothing is under audit, the honest recommendation is to wait. The case for not buying a gateway yet sets out where that line sits.
The cost curve bends at two points. The first is the first leaver. The second is the first time a reviewer asks you to show, not describe, what an agent did. Before those, tokens are fine. After them, a token inventory becomes a standing job.
How do you check what you have today?
Run this before deciding anything. It takes an afternoon and it usually surprises people.
- List every MCP client in use: Claude, ChatGPT, Cursor, anything a developer wired up directly.
- For each one, record whether it signed in with OAuth or was handed a static string.
- For every static string, find where else it is stored: CI, shell history, shared docs, a teammate's machine.
- Take one person who left in the last quarter and try their access path. Do not ask whether it was revoked; call it.
- Write down how long a permission change takes to reach the tool surface, and verify the number rather than quoting a vendor page.
Step four is the one that changes minds. If a leaver's path still works, the credential was a bearer string and nobody rotated it.
For the address-model side of this comparison, see one endpoint instead of one server per member. If you are weighing running the servers yourself, the real cost of self-hosted MCP servers covers that fork. For the offboarding drill itself, contractor offboarding and AI access goes step by step. To see which systems can be connected once and governed centrally, browse the connector catalog or the team use cases.
