# Governance for AI agents and MCP tools | Elaichi

> Govern AI agent access with roles, per-tool restrictions, and an append-only audit log. A restricted tool is never advertised to the model.

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 governance often looks like

- When a team shares one key, every call looks the same in the logs, so it is hard to tell who actually did what.
- Models are frequently given the full set of tools and trusted to use them well, which leaves more surface than most teams intend.
- When an auditor asks for a precise account of activity, assembling it after the fact is slow.

## 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.

## 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.

## What it looks like in practice

### Read, never delete, in the CRM

*Security.* 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.

Connectors: [Salesforce](https://elaichi.ai/connectors/salesforce/)

### A contractor who sees only what they need

*Engineering.* 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.

Connectors: [Jira](https://elaichi.ai/connectors/jira/), [Sentry](https://elaichi.ai/connectors/sentry/)

### Evidence on request

*Compliance.* 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.

## How to set it up

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.

## Three ways to govern what AI can do

| | 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 |

## Details that matter

- **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.

## Further reading

- [What an AI agent audit log must capture](https://elaichi.ai/blog/what-an-ai-audit-log-must-capture/)
- [Restrict one AI tool or the whole app? Six cases](https://elaichi.ai/blog/per-tool-vs-per-app-restrictions/)
- [Designing roles for AI agents: one role each](https://elaichi.ai/blog/designing-roles-for-ai-agents/)
- [Least privilege for AI agents without breakage](https://elaichi.ai/blog/least-privilege-tool-calls-without-breaking-automation/)
- [SOC 2 evidence for AI agents: CC6 and CC7](https://elaichi.ai/blog/soc2-evidence-ai-agents-cc-controls/)
- [MCP security review checklist: ten questions](https://elaichi.ai/blog/mcp-security-review-checklist/)

## Frequently asked questions

### Can I stop the model from using a specific tool?

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.

### 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.

## Related use cases

- [Automated provisioning and deprovisioning](https://elaichi.ai/use-cases/provisioning/)
- [Context sharing across teams](https://elaichi.ai/use-cases/context-sharing/)
- [Connect once, use across every LLM](https://elaichi.ai/use-cases/connect-once/)

See also [Product](https://elaichi.ai/product/) and [Security](https://elaichi.ai/security/), or [start a trial](https://app.elaichi.ai/signup).