# Read-only auditor role setup in Elaichi > The read-only auditor role setup in Elaichi: assign the free Auditor seat, see what its 12 view permissions open, and learn what the role cannot do. **TL;DR** A read-only auditor role setup in Elaichi means assigning the built-in Auditor role, which holds 12 view permissions and takes no billable seat. The Auditor can read the audit log, billing details, restrictions, SSO and SCIM settings, logging destinations and the connector catalog. It cannot run tools, so its MCP tool list is empty, and it cannot see other members' connections, toolboxes or templates. ## The situation An auditor asks for access to your AI tooling two weeks before fieldwork. They want to read the audit log, see who holds which role, and check what restrictions are in place. They do not want to run anything. Your instinct is to create a custom role with a handful of view permissions and hand it over. Do not. A custom role in Elaichi is always a billable seat, even one holding only view permissions. The built-in Auditor role is a free seat, and it is already the shape you want. This post covers the read-only auditor role setup and what that role actually reads. It also covers the four or five things a reviewer will ask for that it does not cover. A permission in Elaichi is an action string a role bundles, such as `audit:view`. A restriction is a separate layer that says which connectors and tools a role or a member may reach. The two are not the same thing, and a reviewer will mix them up if you let them. ## What does the read-only auditor role setup involve? Assign the built-in Auditor role when you invite the reviewer. That is the whole read-only auditor role setup: there is no custom role to author, no restriction to write, and no toolbox to share. An invitation carries exactly one role. Sending one needs the `member:manage` permission. From a browser session it also needs a step-up confirmation, which is Elaichi asking you to prove it is you before a sensitive action. The inviter must hold every permission of the invited role, so whoever sends an Auditor invitation needs those 12 view permissions themselves. Among the system roles, Org Owner and Org Admin qualify. The invite link is valid for 7 days and works once. Accepting it requires being signed in as the invited address. Some email domains belong to an organization that enforces single sign-on (SSO, your identity provider standing in for an Elaichi password). A reviewer on such a domain is sent to that identity provider first. Auditor is one of eight system roles Elaichi seeds into every organization. System roles cannot be edited or deleted. Nobody can quietly widen Auditor later without creating a different role entirely. ## Why Auditor costs nothing Auditor sits in the `free_admin` seat class, alongside Billing Admin and [the Guest role you would give a contractor](/blog/guest-role-for-contractors/). The console marks all three "Free" in the roles list and in the invite dialog. Billable seats are the organization's active members whose role is not one of those three. A suspended member never counts. So adding a compliance reviewer as an Auditor does not add a billable seat, and your Gold subscription quantity does not move when they accept. The trap is the custom role. Elaichi creates every custom role with seat class `billable`, and the role API cannot change it. A custom role holding nothing but `audit:view` and `restriction:view` is still a paid seat. If free access matters to you, Auditor is the only read-only option that is free. Elaichi updates a subscription's quantity after members are added, removed, suspended or reactivated, or have their roles changed. Moving a reviewer from a custom role to Auditor therefore reduces the count; moving them the other way increases it. ## What the Auditor can read Auditor holds 12 permissions, every one of them a view permission: `billing:view`, `connector:view`, `connection:view`, `template:view`, `toolbox:view`, `restriction:view`, `api_token:view`, `sso:view`, `logging:view`, `notification:view`, `audit:view` and `spend:view`. The role's own description reads: "Free, read-only visibility across the organization for compliance and oversight. Cannot change anything or use products." In practice that opens: - The organization's audit log, every event in it, because `audit:view` widens the log from the reader's own events to the whole organization. - Billing details and spend. - The connector catalog, so the reviewer can see which apps are available. - Restrictions, meaning the allow and block rules written on roles and on individual members. - API token metadata, which is names, owners, last use and dates, never token values. - SSO connections, SCIM groups and [group-to-role mappings](/blog/mapping-sso-groups-to-roles/). - Logging and notification destinations. That covers most of what an access review asks for. For the shape of the audit record itself, [what an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/) goes field by field. ## What the Auditor cannot do Three of Auditor's twelve permissions do less than their names suggest. Say this out loud before fieldwork starts rather than during it. `connection:view` and `template:view` are reserved and have no effect. Both are labeled "Reserved (no effect)" in the console. Their descriptions say they grant no connection or template visibility, because access to those resolves from ownership or an explicit share instead. `toolbox:view` covers viewing organization-wide synthetic tool definitions; it grants no access to other members' toolboxes. So the Auditor role does not by itself let someone see other members' connections, templates or toolboxes. Nor does any other permission. In Elaichi a member, including an Org Owner, sees only what they own or what has been explicitly shared with them. Toolboxes and templates have no organization-wide oversight view. A list or detail read shows only the ones the reader owns or was shared with, and one they cannot see answers 404 rather than 403. Auditor also holds no `tool:execute` permission. A role without `tool:execute` gets an empty tool list over MCP (Model Context Protocol, the open standard an AI client uses to call tools), whatever scopes its OAuth grant holds. Every call then answers with an in-band error naming `tool:execute`. The message says re-authorizing cannot grant it, because it is a role and not a scope. Of the eight system roles, Guest, Billing Admin and Auditor lack `tool:execute`, so their MCP tool list is empty. One consequence worth writing into the reviewer's brief: the Auditor's own MCP client cannot read the audit log either. The `elaichi__audit__list` operation needs `tool:execute` on top of the read scope. Among the built-in roles that reaches Org Owner, Org Admin, People Admin, Team Admin and Member. An Auditor reads the log in the console, not in Claude. Auditor holds no `restriction:manage` and no `restriction:override`, so a reviewer can read every rule and change none. It holds no `member:manage`, so it cannot see the organization's queue of access requests, which needs that permission. It cannot approve or deny one either. Nobody can resolve an access request from an AI surface at all; that decision belongs to a person in the console, under Governance, then Access requests. ## What a reviewer will ask for that you have to say no to Four requests come up often enough to prepare for. **"Show me every toolbox in the organization."** There is no such view, for anyone. Toolbox and template reads are scoped to ownership and shares, and no permission widens them. What you can give instead is the audit log. It records `toolbox.created`, `toolbox.updated`, `toolbox.shared`, `toolbox.share_revoked`, `toolbox.transferred` and `toolbox.repinned`, plus the equivalent template events. That is a history of changes rather than a snapshot of state. **"Show me every connection and whose credential is behind it."** Same answer. Connections resolve from ownership or a share. The audit log records connection events, and each connected-tool call names the connection the call actually reached. The trail exists even though the inventory view does not. **"Export three years of history."** Elaichi keeps 90 days of audit history. For a longer record, forward it to your own log service. Logging destinations come with the Black plan, which is launching soon, and Datadog is the destination that delivers. The console's "All time" range sends no start time, and a query with no start time covers only the last 400 days. Do not describe that view as a complete history. The AI clients keep their own clocks, and a reviewer may ask about those too. Anthropic's Compliance API Activity Feed starts recording when the API is first enabled, does not backfill earlier activity, and keeps recorded activity for 6 years ([Anthropic docs](https://platform.claude.com/docs/en/manage-claude/compliance-activity-feed), checked October 2026). Anthropic documents that API as available to Claude Enterprise organizations and to eligible standalone Claude Console organizations ([Anthropic docs](https://platform.claude.com/docs/en/manage-claude/compliance-api-access), checked October 2026). OpenAI says its Compliance Logs Platform retains data for 30 days ([OpenAI help center](https://help.openai.com/en/articles/9261474-openai-compliance-platform-for-enterprise-and-edu-customers), checked October 2026). Cursor documents audit logs as an Enterprise-plan feature, with `mcp_server_config` events when a user or team MCP server is configured ([Cursor docs](https://cursor.com/docs/enterprise/compliance-and-monitoring), checked October 2026). **"Give the reviewer their own session list so they can check for stale logins."** Customers and organization admins have no session list and no sign-out-everywhere control. Ending all of a person's sessions is an Elaichi staff action. If the reviewer asks about certifications, point them at the [Trust Center](https://trust.elaichi.ai) rather than answering from the product. Reports and certificates live there. ## When the Auditor role is the wrong answer Sometimes a reviewer needs to run a single read tool, to pull a report out of a connected app rather than read Elaichi's own records. Auditor cannot do it, and no scope will fix that. They need a role holding `tool:execute`, which means a billable seat, plus restrictions holding them to the read tools they need. That is a different setup, and [least privilege for AI agents](/blog/least-privilege-tool-calls-without-breaking-automation/) covers how to write those rules without breaking the rest of the role. Sometimes the reviewer only needs evidence about a handful of calls, and someone internal can pull it. Then you may not need to add them to the organization at all. A member exported CSV of the audit view, with its filters applied, carries the same records. An export longer than 10,000 entries stops rather than saving a partial file, so narrow the range first. And if you have not yet decided which roles exist at all, start one layer up. [Designing roles for AI agents](/blog/designing-roles-for-ai-agents/) covers why a member holds exactly one role and what that forces about how you draw personas. ## One more thing about timing Role changes are not instant. A member's roles, teams, permissions and resolved restrictions are cached, and a change reaches every surface within about two minutes. Plan a role change a few minutes before a reviewer's call rather than during it. What is immediate is removal. Removing or suspending a member revokes every live MCP OAuth grant they hold in that organization. Grants are re-read on every request, so their clients fail on the next call. Reactivating them does not restore the grants; they consent again. For a reviewer on an Auditor role with no tool access, that is a detail rather than a risk. It is also the same mechanism you rely on when fieldwork ends and you remove the account. For the wider picture of who may reach which app, [MCP governance](/blog/mcp-governance/) is the pillar. The connector side of the question starts at [the catalog](/connectors/). ## FAQ ### Does adding a compliance reviewer as an Auditor cost a seat in Elaichi? No. Elaichi's Auditor role sits in the free seat class alongside Guest and Billing Admin, and the console marks all three "Free" in the roles list and the invite dialog. Billable seats are active members whose role is not one of those three. A custom role is a different matter: Elaichi creates every custom role as a billable seat, even one holding only view permissions, and the role API cannot change that. ### Can an Elaichi Auditor see every connection and toolbox in the organization? No. Two of the Auditor's twelve permissions, connection:view and template:view, are reserved and grant nothing, and its toolbox:view covers only organization-wide synthetic tool definitions. In Elaichi every member, Org Owners included, sees only what they own or what has been explicitly shared with them, and no permission widens a toolbox or template listing. What an Auditor does get is the organization's full audit log, which records when toolboxes and connections were created, changed, shared and transferred. ### Why is an Elaichi Auditor's MCP tool list empty? Because the Auditor role holds no tool:execute permission. In Elaichi a role without tool:execute gets an empty tools/list over MCP whatever scopes its OAuth grant holds, and every tool call answers with an in-band error naming tool:execute and saying that re-authorizing will not help, because it is a role rather than a scope. Guest, Billing Admin and Auditor are the three system roles that lack it. ### What exactly does Elaichi's Auditor role let someone read? Auditor holds 12 view permissions: billing:view, connector:view, connection:view, template:view, toolbox:view, restriction:view, api_token:view, sso:view, logging:view, notification:view, audit:view and spend:view. In practice it opens the organization's whole audit log, billing and spend details, the connector catalog, restriction rules, API token metadata without token values, SSO and SCIM settings including group mappings, and logging and notification destinations. It holds no create, share, manage, override, delete or tool:execute permission. ### How long does Elaichi keep audit history for a reviewer? Elaichi keeps 90 days of audit history. For a longer record, forward it to your own log service: logging destinations come with the Black plan, which is launching soon, and Datadog is the destination that delivers. Note also that an audit query with no start time covers only the last 400 days, and the console's "All time" range sends no start time, so that view is not a complete history. ## Read next - [Contractor Guest role configuration in Elaichi](/blog/guest-role-for-contractors/) — Contractor Guest role configuration in Elaichi: what Guest actually holds, why most contractors need Member plus restrictions, and what removal revokes. - [Vendor Security Questionnaire AI Access: 20 Answers](/blog/vendor-security-questionnaire-ai-agent-access/) — Twenty vendor security questionnaire ai access questions, answered with the mechanism: which key, which role, which log row. - [MCP governance: who may do what, in which app](/blog/mcp-governance/) — MCP governance decides who connects which app, which tools each role calls, whose account a call uses, what is logged and how access ends.