Context sharing across teams
Connect an account once and share it as a capability, so everyone who needs it works with your access while the credential stays sealed in the vault.
In short
With Elaichi, one person connects an account and shares what it can do, not the credential behind it.
Share the connection itself with a person, a team or the whole organization at view, use or edit, or keep it private and share a curated toolbox over it instead. Either way the secret stays in the vault and is never returned by the API, and each person sees only what they own or what was shared with them.
What changes
Today
With Elaichi
Who it is for
You set up the Salesforce or Zendesk connection once and want the whole team working from it, without five people repeating your setup.
You want shared access in one place, where you can see it, narrow it and take it back at any time.
You want the right tools to simply be there in Claude or ChatGPT, scoped to your job, without asking anyone for a password.
Real situations
A sales lead connects Salesforce, keeps the connection private and shares a toolbox with the read and activity-logging tools. The SDRs run it from Claude or ChatGPT, the credential stays with the lead, and the toolbox holds just the tools the team needs.
A support manager keeps the Zendesk connection private and shares a toolbox with the ticket tools the team needs, their own queue frozen in place. Agents get help working tickets in their AI client, and the tools always work on the right queue.
A finance lead keeps the QuickBooks connection private and shares a read-only toolbox with operations. Ops pull invoices and balances into their answers, and every tool they can reach is read-only.
Setup
Four steps, in the order an admin takes them.
Pick the app from the catalog and sign in through the hosted flow. The connection belongs to you, a team or the organization, and the credential goes straight into the vault.
Share the whole connection when the team should have everything it can do. When they should not, keep it private and build a toolbox: choose the tools, rename and describe them for the model, and freeze the values that must not change.
Give view, use or edit to a person, a team or the whole organization. Use is enough to run tools and edit lets someone change the toolbox. Share a template instead and teammates can stamp their own copy.
Teammates sign in to the one Elaichi endpoint from Claude, ChatGPT, Cursor or any MCP client, and the shared tools are there. Revoke a share and it stops on their next request.
Compare your options
| Aspect | Shared API key | Each person’s own client connectors | Elaichi |
|---|---|---|---|
| What teammates get | The key, with everything it can do | Their own access to the app | A capability: only the tools you shared |
| Setup effort | Once, then shared around | Repeated by each person, in each client | Once, by the owner |
| Locking it down | Limited to what the key allows | Through each app’s own permissions | A toolbox with frozen values over a private connection |
| Who did what | Calls appear as the key’s owner | In each app’s own logs | Each call that runs, recorded against the person, in one log |
| Taking it back | Rotate the key and share it again | Revoke it in each app, person by person | Revoke the share; it stops on the next request |
| When someone leaves | Handled by rotating the key | Accounts closed app by app | An offboarding preflight resolves what others depend on |
Under the hood
The specifics a careful reviewer checks, answered up front.
Calls run on the owner’s account. A shared connection reaches the app as the account that connected it, while Elaichi records which person actually made each call and which account it reached.
Freezes follow the toolbox. Frozen values hold for everyone who runs the tool through the toolbox. Anyone you also give use on the connection itself can call the tool unfrozen, which is why a lock-down keeps the connection private.
Visibility follows sharing, not rank. A member sees only what they own or what was shared with them. No organization-level permission widens that, org owners and admins included.
The link is not the key. A connect link opens a one-time sign-in session and carries no access token, refresh token or secret, which is why an AI can safely hand one to a person.
The right role from day one, and a clean exit in one action.
Read the use caseDecide who can act, choose which tools each agent can use, and keep an attributed record of every call that runs.
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
They can, and each of them then holds their own access to the app and repeats the setup in every client they use. Sharing through Elaichi means one connection, set up once, that the team works through from any client, narrowed to what you choose and revoked on their next call.
Yours. A shared connection runs on its owner’s credential, so the app sees the account that connected it. Elaichi still records which person made each call and which account it reached.
Keep the connection private and share a toolbox that holds only the tools they need. Frozen values are merged in when the tool runs, so the AI cannot change them, whatever it is asked. Sharing the connection itself would give them every tool it has.
Start a trial, connect an account, and share a toolbox over it with a colleague.
and any other MCP client, or the Elaichi Agent.
