Reads for everyone, deletes for admins
A security lead restricts the Salesforce delete tools for the Member role and keeps the reads open. In every client, members’ agents work with the reads, and the rule holds whatever a prompt says.
Governance
Control and a clean record for every AI action
Decide who can act, choose exactly which tools each person’s agent can use, and keep an attributed record of every call that runs, all from one place.
In short
Governance in Elaichi is three layers over one endpoint.
Roles decide who may act: eight predefined roles or your own, with one role per person. Restrictions decide which connectors and individual tools each role or person can reach, and the model cannot run a restricted tool. The audit log records every tool call that runs, succeeded or failed, with the person, the account it reached and the client it came through.
- 8
- predefined roles, plus custom roles
- 1
- role per person, so a role describes everything they can do
- Per tool
- restrictions, not only per app
- ~2 min
- for a new rule to reach every client
What changes
Today
What governance often looks like
- When a team shares one key, every call is recorded under that one key.
- Models are often given the full set of tools an app offers.
- When an auditor asks for an account of activity, it is put together from each app’s own records.
With Elaichi
Three checks before a call, and a record after
- Roles decide who may act: 8 predefined roles and any custom role you build, with exactly one role per person so each role is a complete persona.
- Restrictions decide what the model can run. A restricted tool is left out of the tools Elaichi advertises, and search names it only as restricted, with no way to call it.
- Every connector you add is governed by the same roles and restrictions from the start, so adding apps never means adding a separate set of rules.
- Every tool call that runs, successful or not, lands in an append-only log with the person, the account actually reached, the client it came through and how it was approved.
Who it is for
For the teams responsible for how AI is used
Security leads
You need least privilege for AI that holds up in a review: who can act, on which tools, and a record of what happened.
Compliance and audit
You need evidence you can hand over, and a free reviewer seat that can read the audit log and the setup without changing anything.
IT and platform owners
You want one place to set the rules for every AI client, instead of configuring Claude, ChatGPT and Cursor one by one.
Real situations
What it looks like in practice
A contractor who sees only what they need
An engineering lead gives a contractor a person-level rule that allows only the read tools in Jira and Sentry. A person-level rule can only narrow what the role allows, so the contractor reaches exactly those reads.
Evidence on request
Before an audit, the compliance team gives the reviewer a free Auditor seat. The reviewer reads the audit log and the configuration and filters every call by person, action and time, without the ability to run a tool or change a rule.
Setup
How to set it up
Four steps, in the order an admin takes them.
-
1
Give everyone one role
Start from the predefined roles, from Guest to Org Owner, or build custom roles from the permission catalog. Each person holds exactly one, so a role always describes the whole of what they can do.
-
2
Write restrictions where they matter
Allow or block connectors and individual tools for a role or for one person. A person-level rule can only narrow what the role allows, a block always beats an allow, and an allow rule that names nothing blocks everything.
-
3
Let people ask for more
Someone who hits a restriction can file an access request. Approving it opens exactly that connector or tool for that one person, and nothing else about their role changes.
-
4
Read the record
Review every call in the audit log, filtered by person, action and time, and give reviewers a free, read-only Auditor seat.
Compare your options
Three ways to govern what AI can do
| Aspect | Shared keys | Each AI client’s own settings | Elaichi |
|---|---|---|---|
| Who can act | Whoever holds the key | Whoever has the client set up | One role per person, predefined or custom |
| What the model sees | Every tool the key can reach | Set client by client | Only allowed tools; restricted ones are left out of the list |
| Where the rules live | Wherever the key is shared | In each client, separately | In one place, for every client |
| Changing a rule | Rotate keys and reconfigure clients | Edit every client’s settings | Edit it once; it lands within about two minutes |
| The record | Under one shared identity | In each client, where kept | Each call that runs, with person, account, client and approval |
Under the hood
Details that matter
The specifics a careful reviewer checks, answered up front.
-
Rules bind the operation, not the label. A rule is pinned to the underlying operation when you write it, so renaming a tool in a connector’s documentation cannot slip it past a block.
-
Restricted means not runnable. A restricted tool is left out of what Elaichi advertises. If the model searches for it, search names it as restricted, with no description, no schema and no way to call it.
-
Values stay out of the log. The log records no argument values, names or counts, only the id of the record a call targets. A failed call is logged with a fixed error code and the upstream status, not the third party’s own error text.
-
Your log, in your Datadog. Forwarding the audit log to your own Datadog comes with the Black plan, launching soon. The audit trail inside Elaichi is part of Gold.
Related use cases
Automated provisioning and deprovisioning
The right role from day one, and a clean exit in one action.
Read the use caseContext sharing across teams
Share a capability, not a secret. A colleague works through your connection without ever seeing it.
Read the use caseConnect once, use across every LLM
Connect 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
Frequently asked questions
Can I choose which specific tools the model can use?
Yes. Restrictions work on individual tools, not whole applications. Set an allow or block rule on a role or on one person; a person-level rule can only narrow what the role allows. A restricted tool is left out of what Elaichi advertises, and search shows it only as restricted, with no way to call it.
Can’t I set these rules in each AI client’s admin settings?
Each client offers its own controls, set and kept up client by client. Elaichi sets roles and per-tool restrictions once, for every client that connects, and keeps one audit log across them. A client sees Elaichi as one server, so control over the apps and tools behind it is set in Elaichi, as restrictions.
What does the audit log record for each call?
One append-only entry for every tool call that runs, succeeded or failed: the person, the operation and tool, the account actually reached, the client it came through, how it was approved and the outcome. A call refused before it runs, for example by a restriction, writes no entry. Argument values are not recorded, only the id of the record a call targets.
Can I tell which AI client made a call?
Yes. Each entry records the surface and the named client, such as Claude, ChatGPT or Cursor, alongside the person the call ran for.
Can I give a compliance reviewer access without paying for a seat?
Yes. The Auditor role is read-only and free. A reviewer can see the log and the configuration without a license and without the ability to change anything.
How do restrictions resolve between a role and a person?
Restrictions target a role or a person. A person-level rule can only narrow what the role rule allows, a block always beats an allow, and with no rule the default is open, so you narrow access deliberately with role and person rules.
How long until a new restriction takes effect?
About two minutes. Roles and restrictions resolve through a short cache on every surface. Revoked shares and suspended members take effect on the next request.
Can I send the audit log to my own SIEM?
Forwarding to your own Datadog comes with the Black plan, which is launching soon. On Gold, the audit trail lives in Elaichi, searchable by person, action and time.
Who approves what an AI agent does?
Over MCP, the person approves on Elaichi’s consent screen when they connect a client, choosing whether it may read, change, run tools or delete, and delete is never pre-ticked. Elaichi adds no per-call approval over MCP; a confirmation before a single action is the client’s own prompt, where the client offers one.
Set your first restriction in minutes
Start a trial, set one rule for one role, and see it apply in every client.
- Works with
-
and any other MCP client, or the Elaichi Agent.
- When the trial ends
- Nothing is deleted. Connections, roles and the audit log stay where they are, so subscribing picks up exactly where you left off.