Provisioning and deprovisioning
Bring people in through the sign-in system your company already uses, with the right role from the start, and close their access in one action when they leave.
In short
Elaichi follows the system your company already uses to manage employee accounts, known as an identity provider.
People join through SAML or OIDC single sign-on, SCIM, a verified domain or a single-use invite, and arrive with the right role. When your identity provider deactivates someone, SCIM suspends them in Elaichi and every live grant is revoked, so their access ends on the next request. Removing them for good is one action, with a preflight that makes sure anything a teammate depends on is handed over first.
What changes
Today
With Elaichi
Who it is for
You already manage employee accounts and sign-in in one place, and want Elaichi to follow it automatically instead of becoming one more list to keep up to date.
When someone moves on, you want their AI access closed in every AI app they had connected, in one step.
You want new starters working from their first day, and access wrapped up neatly when someone moves on, without a ticket for every app.
Real situations
An engineer is added to the Engineering group in the identity provider. SCIM creates them in Elaichi, the group mapping gives them the right role, and they sign in through single sign-on. They connect their own Jira account in minutes, and the restrictions on their role are already in force.
Someone moves on, and IT deactivates them in the identity provider. SCIM suspends them in Elaichi, so their AI access ends on the very next call. Later, an admin removes them; the preflight flags the HubSpot connection the marketing team’s toolbox depends on, and the admin transfers it to the marketing lead instead of deleting it.
An auditor asks what a former employee did through AI before they left. The audit log keeps every call of theirs that ran, by name, and a departed member stays in the record as Former member.
Setup
Four steps, in the order an admin takes them.
Prove you own your email domain with a DNS TXT record. A verified domain can let new people join on their own, with a default role you choose.
Add SAML or OIDC single sign-on, built in-house with no third-party auth vendor in the path, and enforce it so your people always sign in through it.
Provision users and groups with SCIM v2 and map groups to roles. Each group mapping grants at most one role, and deactivating someone in your identity provider suspends them in Elaichi.
When someone leaves for good, remove them in Elaichi. The preflight lists anything a shared toolbox depends on, and the removal goes through once each item is transferred or deleted.
Compare your options
| Aspect | By hand | Identity provider alone | Elaichi |
|---|---|---|---|
| Joining | Accounts set up app by app | Sign-in covered; AI access set up separately | Arrive with a role through SSO, SCIM, a domain or an invite |
| Roles | Granted person by person | Per app, where each app supports it | Mapped from identity provider groups |
| AI access when someone leaves | Keys revoked one by one | Sign-in ends; keys and tokens set up for AI tools are handled separately | SCIM suspends them, and every live grant is revoked on the next call |
| Shared work | Reassigned by hand | Reassigned app by app | The preflight transfers what teammates depend on |
| Proof it ended | A manual checklist | The sign-in log | Every call that ran, in the audit log, by name |
Under the hood
The specifics a careful reviewer checks, answered up front.
SCIM suspends, an admin removes. Deactivating a user in your identity provider suspends them in Elaichi. Reactivating them brings their membership back, and each AI client connects again with fresh consent. Removing a member, with its preflight, is a deliberate step, so a sync mistake never deletes anyone’s work.
Revocation is not cached. Grants are re-read on every call, so suspension and removal take effect on the next request. Roles, restrictions and team membership ride a short cache and land within about two minutes.
Private stays private. A private connection that nothing else depends on is never handed to someone else; it is deleted. If a shared toolbox relied on one, an admin decides whether to transfer or delete it before the removal goes through.
Try it in the trial. Every organization starts with a 14-day Gold trial, no credit card needed, and single sign-on, SCIM and group-to-role mapping are part of it.
Decide who can act, choose which tools each agent can use, and keep an attributed record of every call that runs.
Read the use caseShare a capability, not a secret. A colleague works through your connection without ever seeing it.
Read the use caseConnect each app once and use it from Claude, ChatGPT, Cursor, and any MCP client.
Read the use caseSee the whole picture in the product tour and the security model.
FAQ
On their next request. When your identity provider deactivates them, SCIM suspends them in Elaichi and every live grant is revoked in the same transaction. Suspending or removing them by hand has the same effect.
Single sign-on controls who can sign in to a client. The connections people make inside a client to your apps are set up separately, by each person. With Elaichi, people arrive with a role, and when they leave, every AI client they connected through Elaichi is refused on its next call.
No. A SCIM deactivation or delete suspends the member, which revokes every grant their AI clients hold. Reactivating them restores the membership, and their clients connect again with fresh consent. Removing a member for good is a separate step an admin takes, with the offboarding preflight.
Elaichi supports SAML and OIDC single sign-on and SCIM v2 provisioning, all built in-house with no third-party auth vendor in the sign-in path, so an identity provider that speaks those standards can manage who has access.
No. A SCIM group mapping grants at most one role and never sets team membership. Invites can preset teams, and people who arrive through SCIM, single sign-on or a verified domain are added to teams afterward.
About two minutes. Roles, restrictions and team membership resolve through a short cache. Suspension, removal and revoked shares take effect on the next request.
Not once they are suspended. Billable seats are active memberships, so suspended members, along with free roles such as Auditor and Guest, are not counted.
Yes. Every organization starts with a 14-day Gold trial, no credit card needed, and single sign-on, SCIM and group-to-role mapping are all part of it.
Start a trial, connect single sign-on or SCIM, and see access update on the very next call.
and any other MCP client, or the Elaichi Agent.
