Governance
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.
What changes
Today
With Elaichi
Who it is for
You need least privilege for AI that holds up in a review: who can act, on which tools, and a record of what happened.
You need evidence you can hand over, and a free reviewer seat that can read the audit log and the setup without changing anything.
You want one place to set the rules for every AI client, instead of configuring Claude, ChatGPT and Cursor one by one.
Real situations
A security lead blocks the delete tools on Salesforce for the Member role and leaves the reads open. In every client the agent can find the delete tools only as restricted, with no way to call them, so nobody has to trust a prompt to stay away from them.
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 just those reads and can run nothing else.
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
Four steps, in the order an admin takes them.
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.
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.
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.
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
| 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 never advertised |
| Where the rules live | No central place | 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
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.
The right role from day one, and a clean exit in one action.
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
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.
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.
Yes. Each entry records the surface and the named client, such as Claude, ChatGPT or Cursor, alongside the person the call ran for.
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.
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.
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.
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.
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.
Start a trial, block one tool for one role, and watch it drop out of what the model can run.
and any other MCP client, or the Elaichi Agent.
