AI access for new hires: what lands on its own

A new hire's first Monday, in access terms

AI access for new hires splits into two halves: what your directory can decide on its own, and what only a person can do. The directory decides the role they land on. A person still connects each AI client, picks the account behind each app, and puts them in a team. Elaichi sets the role from the join path, and leaves the client sign-in, the app accounts and the team to people.

Picture it. The identity provider creates the account overnight. By nine the new hire is signed in to Claude asking about last quarter's pipeline. They reach company apps at one Elaichi address that Claude, ChatGPT, Cursor and Microsoft Copilot all sign into. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The MCP specification describes it as an open protocol connecting LLM applications to external data sources and tools (checked October 2026). Whether that first question works depends on four decisions, three of which you made weeks ago.

This post describes how Elaichi implements three standard identity patterns. They are SCIM for lifecycle provisioning, SAML or OIDC for single sign-on, and role-based access control (RBAC) for authorization. The specific role names and permission counts below are Elaichi's. The underlying split is general: the directory sets identity and role, and a person sets tools and team. It applies to any directory-driven access system layered on top of SCIM and SSO.

Which parts of AI access for new hires land automatically?

Membership and role. Those are the two things a join path can set by itself.

Apart from the person who creates an organization, people join one of four ways:

SCIM is the standard your identity provider uses to push accounts into another system. RFC 7644 defines it as an HTTP-based protocol for managing identities across domains, such as enterprise-to-cloud provisioning (checked October 2026).

Each verified domain and each SSO connection carries an optional default role for people who join through it. SCIM-provisioned members get the default role of the organization's default SSO connection.

When no default role is set, or the configured role has since been deleted, the person lands on Member. Org Owner cannot be a default role, and whoever sets one has to hold every permission in it. The default role is a decision you make once and then forget. Write it down.

What does a default role give someone on day one?

Member, the common landing role, holds 23 permissions. Among them are connection:create, toolbox:create, template:create, team:create and tool:execute. Absent any admin restriction, a Member can connect any catalog connector using their own account.

tool:execute is the permission that decides whether the Monday morning question works at all. A role without it gets an empty tool list in every AI client, whatever the client was approved for. Guest holds connector:view only, so a Guest can browse the connector catalog and run nothing. Auditor holds twelve view permissions and no tool:execute either.

Guest, Billing Admin and Auditor are free seats. Member is a billable one, and the prorated charge lands within minutes of the person joining.

If you want a contractor to land somewhere narrower than Member, the Guest role walkthrough covers what that seat can and cannot reach.

Why does a group-to-role mapping confer at most one role?

Because a member holds exactly one role in an organization, and the mapping has to resolve to one. A SCIM group-to-role mapping names at most one role, and it can never name Org Owner. Directory groups are themselves a SCIM resource type. RFC 7643 defines SCIM's core schema for users and groups (checked October 2026).

If a member belongs to several mapped groups, Elaichi gives them the single most privileged of the mapped roles, ranked by the system role chain. It never unions permissions from more than one. Some SCIM consumers merge group-derived entitlements instead. Elaichi's model is strictly one role per member, not additive.

That is also why the answer to "can they be an Admin and a Billing Admin" is no. You author a custom role that carries both sets of permissions, which needs the role:manage permission and a plan with custom roles (Gold and Black include them).

A mapping is a deferred grant. It changes nobody's access until the next SCIM sync recomputes membership, which runs on every mutation under the SCIM endpoint and on every mapping write. Creating or updating one needs the sso:manage permission and a fresh identity check from a browser session; reading needs sso:view. Deleting a mapping falls its members back to the domain or connection's default join role on the next recompute. The mechanics of writing one are in the group mapping walkthrough.

Do teams come from the directory?

No. Joining through SCIM, a verified domain or SSO puts the person in no team. Neither SCIM nor group mappings ever add anyone to a team or take them out of one. Team membership comes from an admin afterward, or from teams preset on an invite.

An invitation carries exactly one role and can preset up to 50 teams. That makes the invite path the only join path that seats somebody in a team on arrival. Sending one needs member:manage, plus a fresh identity check from a browser session, and the inviter must hold every permission of the invited role.

Teams matter here because sharing runs through them. A grant of view, use or edit on a connection, toolbox or template can name a user, a team or the whole organization. So a toolbox shared with the support team reaches a new hire the moment they are in that team. Restrictions do not work that way. A restriction, which is a rule that blocks or allows whole connectors and single tools, targets a role or one member. There is no team target. To keep a team off a tool, write the rule on the role its members hold.

How do restriction rules land on a new member's role?

A new hire on Member inherits every restriction rule aimed at that role. Within the role layer, all allow rules merge into one allowlist and all block rules into one blocklist, and a block always beats an allow.

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. Read an empty allow rule as a lockout before you write your first one.

Holding a role to one app's read tools takes one of two shapes. Either an allow rule naming those read tools, plus allow rules for every other app the role uses. Or block rules naming every tool on the app that is not a read. Blocking some write tools leaves the ones you did not name reachable. The empty allow rule covers the failure mode in full.

What happens when a new hire asks for something that is blocked?

They can file their own access request from the AI client, and filing needs no permission. The request is always for the caller themselves.

Only a person in the console can decide it, under Governance, then Access requests, and that needs member:manage and a fresh identity check. No AI surface can approve or deny one, denials included. Approving a request for a connector, or for a tool that names its connector, records an access grant for that one person. It writes no restriction rule and edits nobody's role. The grant lifts exactly the approved connector or tool out of the requester's role rules. Every other role rule keeps applying, including ones added later. It follows the member across role changes and lasts until they are removed or an admin approves a replacement.

How does a new hire get a toolbox on their own accounts?

Share a template at use, and each new hire stamps their own toolbox, picking their own account for each app. A toolbox is a named list of tools, each one pinned to a connected account. A template is the same list without the accounts: template entries carry no connection at all.

When the new hire stamps it, the console shows one connection picker per connector, each starting at "Skip and add a connection later." Only the connections they pick are sent, and nothing is pre-filled from their own connections. A connector they skip leaves an entry marked "Needs connection," which is not advertised or runnable until somebody pins one. The toolbox that results is owned by the person who stamped it, and they are recorded as the delegator on every entry that received a connection. Because every call runs on the connection it was made through, each person's own permissions in the third-party app apply.

The alternative looks easier and is not the same thing. A toolbox shared with a team at use runs every grantee's call through the connection pinned in the entry, under the authority of whoever pinned it. That is one fixed account for the whole team. It is right for a shared mailbox and wrong for a CRM where each rep should see their own territory. Sharing of any kind needs Gold or Black; a Personal workspace is one member and cannot share.

Which four steps cannot be automated away?

Four things need a person, and no directory feature removes them.

First, connecting the AI client. Each person opens their client once, signs in to Elaichi in a browser and approves their own grant, the standing approval behind that client's token. They pick one organization on the consent screen, tick the scopes, and choose either all their tools or a short list of toolboxes. Ticking "Create and change data" or "Delete data and remove access" locks "Read your organization's data" on. A grant's scopes never change after consent, so a scope the client was not given takes a reconnect. Elaichi's MCP sign-in supports only the authorization-code grant with PKCE, plus refresh, so nothing lets a client obtain a grant unattended.

Second, connecting each app account. A Member connects their own account for a connector, or an admin shares an existing connection with them, which then runs every call on its owner's sign-in to that app.

Third, team membership, as above.

Fourth, a second factor, if the organization requires two-factor authentication. A member who has one keeps working, even if they connected their client earlier. A member with neither an authenticator app nor a passkey is refused in their AI client and told to set one up in Elaichi. Once they do, the same connection works again with no reconnect.

How soon does a role or team change reach a running client?

Role, team-membership, restriction and access-grant changes take effect about two minutes. That covers a group mapping that lands the person on a different role after their first sync.

Some changes are faster. Elaichi reads shares and connections fresh for every tool call. In Elaichi, revoking a share or disconnecting an account takes effect on the caller's next call. Removing or suspending a member revokes their MCP client grants in that organization, and removing or suspending a member revokes every live grant in the same transaction as the membership change.

Onboarding is the mirror image of offboarding

What arrives automatically does not leave automatically. The directory can suspend a membership. It cannot decide who inherits the Stripe connection that four toolboxes are pinned to.

SCIM writes a narrow set of fields: a member's status, their profile name, their role assignment through a group mapping, their identity provider ID (externalId), and the member fields an admin set to be filled by SCIM. Nothing in SCIM writes a connection, a toolbox or MCP endpoint configuration.

SCIM deprovisioning suspends a member rather than removing them. It revokes their MCP grants, API tokens and SCIM tokens, so their clients fail on the next request. It keeps their role and team rows. Nothing moves: the entries they pinned resolve as unmet, and ownership does not change.

Removing a member outright is the admin action that moves things. It runs a preflight that returns their whole estate first: connections they own, their synthetic tools, toolboxes, templates and custom connectors, plus every toolbox entry anywhere in the organization that relies on them. A private connection nothing depends on is deleted by default. A private connection a shared toolbox depends on, every shared toolbox and template, and every custom connector they own all block the removal until somebody is named.

A transfer rewrites only the connection's owner. It leaves existing grants as they were and does not replace the stored credential. So the connection keeps acting in the third-party app as the account that first authorized it. Deprovision that account separately. Transferring also does not change who vouches for the entries pinned to it. Entries the departing member pinned keep them as delegator and stop resolving for everyone once the removal completes, until someone with edit access re-pins them.

The onboarding decision that saves you here is whose connection backs a shared toolbox. Pin it to someone who will stay. Offboarding when the agent holds access walks the removal itself.

When this is more process than you need

At ten people with one shared toolbox and no hires this quarter, skip most of it. Send invites with the teams preset, let everyone land on Member, and write one restriction on that role for the tools you do not want anyone running. Group mappings, SSO and custom roles come with Gold. If you are not provisioning from a directory they add setup without removing a step.

The moment it starts earning its keep is the second or third hire a month, or the first time someone asks which role a leaver held. Role names, permission counts and plan gating reflect Elaichi's current console behavior under Governance. If you are checking a specific number before relying on it, the in-console role editor shows the live permission list for any role.

For the wider picture of who may do what in which app, see how MCP governance fits together. For the role design itself, read one role each, as a complete persona. To see which of your apps a new hire could connect on day one, browse the connector catalog.