The situation
A contractor starts Monday for six weeks. They need to look at three things in two apps, and nothing else. You want them gone cleanly when the engagement ends. No account should be quietly working in the background afterwards.
The obvious move is the Guest role. Most contractor Guest role configuration starts there, because Guest is free and sounds restrictive. It is both of those. For most contractor work it is still the wrong answer. Read the reason before you assign it and field the first support ticket.
Two words are used throughout. A grant is the OAuth authorization behind an AI client's connection to Elaichi. It is created when the person approves the consent screen. OAuth is the sign-in flow where a person approves an app's access in a browser, rather than handing over a password. A restriction is a rule that says which connectors and tools a role or a member may reach.
Contractor Guest role configuration: what does Guest hold?
Guest holds exactly one permission: connector:view. That permission lets someone browse the connector catalog. The role's own description in the console says it plainly: "Browse-only access to the connector catalog. Cannot connect accounts, use tools, or change anything."
That is the whole role. Guest does not hold tool:execute, the permission that lets a member run a tool. It does not hold connection:create, so a Guest cannot connect their own account to any app. It does not hold toolbox:create or template:create.
Guest sits on Elaichi's system role chain. The chain runs Guest, Member, Team Admin, People Admin, Org Admin, Org Owner. Each tier holds everything the tier below holds, plus at least one more permission. Guest is the floor.
What happens when a Guest connects an AI client?
They can connect. They just cannot do anything with it.
A Guest signs in from Claude, ChatGPT or Cursor, approves the consent screen, and gets a working grant. Then their tool list comes back empty. On the MCP endpoint, a member whose role lacks tool:execute can run no tool at all. That covers connected tools and Elaichi's own operations alike. Of the eight system roles, Guest, Billing Admin and Auditor lack tool:execute, so all three get an empty list.
If the client calls a tool by name anyway, the answer is HTTP 200 with an in-band error naming tool:execute. The message says re-authorizing will not help, because it is the role, not a scope. That wording matters. The contractor will try reconnecting, because that is what people do, and nothing changes.
Client-side controls are separate from this, and they vary by vendor. Anthropic's help pages say an Owner or Primary Owner on Claude Team and Enterprise adds a custom connector from Organization settings > Connectors, and each member then connects it under Customize > Connectors (Anthropic, checked October 2026). Claude's own connector tool permissions are Always allow, Needs approval or Blocked, set on a whole connector, a category of its tools or a single tool (Anthropic, checked October 2026). OpenAI says that on ChatGPT Business only admins and owners can enable developer mode and deploy a custom MCP app (OpenAI, checked October 2026). None of those client settings grants tool:execute. A per-tool setting in a client also cannot tell one connected app from another through Elaichi, because connected-tool calls arrive as execute_tool.
Get ahead of this one. If your contractor's job is to read Jira tickets through Claude, Guest gets them a sign-in screen and a dead end.
When is Guest the right role for a contractor?
Guest fits a contractor who needs to see what exists without touching it. A consultant scoping an integration who wants to know which connectors are in the catalog. A vendor reviewing your tool inventory. Someone who needs an account in the organization without tool access at all.
It also costs nothing. Guest is a free seat, seat class free_admin, and the console marks it "Free" in the roles list and in the invite dialog. Billing Admin and Auditor are the other two free seats. A member counts as a billable seat when their membership is active and their role is not one of those three. Adding a Guest therefore does not add to the bill.
That free-seat point cuts both ways. A custom role is always a billable seat, even one holding only view permissions. Elaichi creates every custom role with seat class billable, and the role API cannot change it. So there is no cheap near-Guest custom role to build. If the contractor needs to run tools, they cost a seat.
How do you configure a contractor who needs to run tools?
Give them Member and narrow them with restrictions.
Member is the base paid role. It holds 23 permissions, including tool:execute, connection:create, connection:share, toolbox:create, template:create and api_token:create. Its description reads: it "Uses connectors, personal connections, templates, toolboxes, the organization's MCP endpoint, and configured assistant features." Absent any admin restriction, a Member can connect any catalog connector using their own account.
That last sentence is the part to fix. Restrictions turn a Member into a narrow contractor account.
In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. To hold a contractor to two apps, write rules on their role or on them personally. How the two layers resolve decides what a contractor can reach. A rule aimed at a single member needs restriction:override on top of restriction:manage. Among the system roles, only Org Owner and Org Admin hold all three.
The cleanest shape for a repeating contractor pattern is a custom role. A custom role can include any of the 58 permissions, but only ones its author currently holds. Creating one needs role:manage plus the custom_roles plan feature, which Gold and Black both include. Build "Contractor" from Member's permissions, minus the ones you do not want. Then write allow rules on that role, naming the whole connectors the contractor needs.
One trap with allow rules. An allow rule turns on the allowlist for its layer just by existing, whatever it names. An allow rule that names nothing therefore blocks every connector and tool for its target; its summary reads "Allows nothing. Every connector and tool is blocked." Once a role carries any allow rule, the rest of the catalog closes behind it. Every connector that none of its allow rules names is blocked for that role. That is what you want for a contractor, as long as you name every app they genuinely need. Elaichi's note on why blocks match tool names but allows match operations covers the matching rules underneath.
How does a contractor get access to the right accounts?
Role and restrictions say which tools exist for them. Sharing says which accounts they can use. Keep the two apart. Mixing them up is the most common way a contractor setup goes wrong.
A connection, a toolbox, a template and a connector are all shared through the same thing: a grant row at one of three levels, view, use or edit. The grantee is a user, a team or the whole organization. A member, including an Org Owner, sees only what they own or what has been shared with them. No organization permission widens a listing.
For a contractor, you have two honest shapes.
They connect their own account. If the contractor has their own login to the app, let them connect it. Every call through a connection fetches credentials from that one connection's bound account. Their calls therefore act as them in the third-party app, and their permissions there apply. When they leave, you deprovision their account in the app as usual.
They use someone else's account through a toolbox. If they should not have their own login, the connection's owner pins the connection into a toolbox entry. The owner then shares the toolbox, not the connection, at use. A toolbox shared at use runs each grantee's call through the connection pinned in the entry. The authority comes from that entry's delegator, the person who pinned it. The contractor never gains their own reach to that connection: seeing, opening or sharing it still needs an independent grant on the connection itself.
That second shape is where frozen parameters earn their keep, because an entry can lock argument values the caller cannot override. The locked values hold only on calls that run through that entry. So keep the connection unshared and share just the toolbox. The post on locking AI agent tool arguments works through the mechanics.
What does removal actually revoke, and when?
Removing or suspending a member revokes their MCP grants, and their AI clients fail on the next call. The timing of role changes is where the wrong sentence is easy to write.
Removing a member revokes every live MCP OAuth grant they hold in that organization, inside the same call that deletes the membership. Suspending a member does the same, including when SCIM sets them inactive. Grants are re-read on every MCP request, so their clients fail on the next one. A person who is no longer an active member gets HTTP 403 from the endpoint: "You are no longer an active member of this organization". It is not a 401, because signing in again cannot fix it.
Reactivating the member does not restore the grants. They have to consent again. That is deliberate: suspension revokes rather than pauses.
Role and restriction changes are slower. A member's roles, teams, permissions and resolved restrictions are cached briefly, and a change reaches every surface in about two minutes. Narrowing a contractor's role mid-engagement therefore takes that long. Removing them from the organization takes effect on the next call. Revoking a share or disconnecting an account is also effective on the next call. Toolboxes, shares and connections are read fresh for every tool call.
Removal also has a preflight. GET /member/:userId/offboarding returns the contractor's whole estate before anything changes. That is the connections they own, their synthetic tools, toolboxes, templates and custom connectors. It also lists the toolbox entries anywhere in the organization that rely on them as delegator. Those delegated entries never block the removal. Once the member is gone they resolve as unmet, and the fix is re-pinning them.
The removal is refused with a 409 until you decide five things: shared toolboxes, shared templates, synthetic tools other toolboxes pin, connections marked as needing resolution, and every custom connector the contractor owns. Connectors have to be transferred; there is no delete option for them. The walkthrough in offboarding AI access, contractors included goes through each decision.
When you do not need any of this
Sometimes the app's own controls are enough. If the contractor works in one app, that app has a guest or external-collaborator concept, and nobody else needs AI access to it, use those controls and skip Elaichi for this engagement. One contractor, one app, six weeks is not a case that needs a control plane.
The case for routing a contractor through Elaichi is the opposite shape. Several apps, a contractor pattern you will run again next quarter, and a removal you want to be one action rather than six. If that is not your situation yet, when you don't need an MCP gateway is the more useful read.
For the wider picture of how roles, restrictions and sharing fit together, start at MCP governance. For why a member holds exactly one role, see designing roles for AI agents.
