# Connect Vanta to Claude for compliance work

> To connect Vanta to Claude for compliance work, add it as one connector, allow only its read tools, and prove the limit from the audit log.

**TL;DR** Elaichi puts Vanta behind one MCP endpoint that Claude signs into with each person's own grant, whether Vanta reaches you as a catalog connector or as your organization's own remote MCP connector. Two restrictions do the real work: an allow rule naming only the read tools on the Vanta connector, and a new-tool policy of Review so a newly listed tool cannot run until someone approves it. The audit log then shows every call that ran, with the connector, the connection, the Claude client and whether it read or changed data.

## How do you connect Vanta to Claude for compliance work?

A compliance manager with a week of evidence requests and a Claude subscription will find a way to put the two together. The work is mostly reading: which controls are failing, which policies are unaccepted, which vendor reviews are overdue. The risk is everything else the same connection can touch.

To connect Vanta to Claude for compliance work, do three things in this order. Get Vanta into Elaichi as one connector. Write the restrictions on the roles that will use it. Then have each person add Elaichi once in their own Claude client, at https://api.elaichi.ai/mcp. Elaichi serves MCP at that one address for every organization. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The OAuth grant behind each person's token decides which organization and which person that client reaches. The URL does not.

The order matters. Restrictions written after people connect still apply, because every call re-reads them. But a role change or a restriction change takes effect within about two minutes, not on the next call. Write the rules first and nobody spends that window with more reach than you intended. On Claude Team and Enterprise plans, an Owner or Primary Owner adds a custom connector once for the organization, from Organization settings > Connectors ([support.claude.com](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), checked October 2026). Each member then connects it and signs in as themselves. The client-side mechanics are in the walkthrough for [adding Elaichi in Claude](/blog/connect-elaichi-to-claude/).

## Check the connector catalog before you build anything

Start at the [connector catalog](/connectors/) and look for Vanta by name. Elaichi's catalog holds 650+ connectors of two kinds. Most are connectors Elaichi authors and runs itself. The rest are native MCP connectors: the vendor builds and runs its own MCP server, and Elaichi handles sign-in, access and audit in front of it.

If Vanta is not listed, an organization on Gold can bring in a remote MCP server as its own connector. That needs the connector:create permission. Among the built-in roles, only Org Owner and Org Admin hold it. The server must speak MCP over Streamable HTTP at a public HTTPS host. No IP literals, no internal hostnames. The URL cannot be changed afterwards, so a different server means a new connector. An organization can hold 25 of its own remote MCP connectors, and a new one is private to its creator until it is shared.

Public reachability is not a formality on the Claude side either. Claude reaches a custom connector's remote MCP server from Anthropic's cloud rather than from the user's device, on every Claude client ([support.claude.com](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), checked October 2026). Here that server is Elaichi's own endpoint, which is public. Anthropic gives the outbound range its traffic to MCP servers comes from as 160.79.104.0/21 ([claude.com](https://claude.com/docs/connectors/building/authentication), checked October 2026). Elaichi then reaches Vanta's server in turn.

Three questions go to Vanta before you create anything. A third-party list is not an answer to any of them. Does Vanta publish a remote MCP server, and at what address? How do members sign in to it: its own OAuth, your pre-registered OAuth client, an API token, or nothing? Which tools does it list, and does it annotate them as read-only? Elaichi never forwards its own MCP access token to a remote server. An OAuth server behind that connector sees only a token its own authorization server issued. The reasoning for putting a vendor's server behind Elaichi, rather than wiring it into each client, is set out in the piece on [governing vendor MCP servers](/blog/vendor-mcp-servers-through-elaichi/).

## The failure to stop: a tool that changes compliance state

The obvious failure is not a leak. It is an assistant that marks a control as passing, dismisses a failing test or clears a policy assignment. A model read a prompt literally, and the tool was available.

Two defaults make that reachable. On a remote MCP connector, Elaichi tiers each tool from the server's own annotations. readOnlyHint true is a read, and destructiveHint false is a write. Anything else, including no annotations at all, counts as destructive. On the consent side, the "Run your connected tools" checkbox (mcp:tools) runs every tier of connected tool, deletes included. Leaving "Create and change data" unticked does not make a connected app read-only. That checkbox governs Elaichi's own write operations.

Claude has its own per-tool permissions. Each takes one of three settings, Always allow, Needs approval or Blocked, applied to a connector, a category of its tools or a single tool ([support.claude.com](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities), checked October 2026). Those settings cannot single out one connected app inside Elaichi. Elaichi's connected tools all run through one tool name, execute_tool, rather than appearing one by one. Per-app and per-tool control belongs in Elaichi, as restrictions.

## Restriction one: an allow rule naming only the read tools

Write one allow rule on the compliance role. Name the Vanta connector's read tools and nothing else. An allow rule naming single tools admits those tools and leaves the connector's others blocked for that role.

Two consequences need planning. An allow rule turns on the allowlist for its whole layer just by existing. Once the role carries one, every connector and tool that none of its allow rules names is blocked for that role. If the same people also use Jira or Google Drive through Elaichi, the role needs whole-connector allow rules for those too. The upside is automatic. A tool the Vanta server starts listing next month is blocked for that role, because nothing names it.

Check the matching rule before you audit the result. Allow rules match the operation Elaichi pinned when the rule was saved, never the tool's label. Block rules match by name or by operation. For a remote MCP tool, the operation is resource mcp with the upstream tool name as its method. The asymmetry has a reason, explained in [why blocks match names and allows do not](/blog/block-matches-name-allow-matches-operation/).

## Restriction two: hold newly listed tools for review

Set the connector's new-tool policy to Review rather than Automatic. Under Review, a tool the server lists for the first time is held as pending_review. It cannot run until someone who can manage the connector approves it. The approval is bound to the exact definition the reviewer saw. If the server later presents a different definition of that tool, that connection cannot call it until the new definition is approved too.

This matters on a remote MCP connector because tools are discovered per connection, with each connection's own credential. Different accounts can see different tools. A manager with edit access approves a tool, turns it off or re-tiers it. Each change writes a connector.tool_updated row to the audit log. Someone with only use access sees the tools that are switched on and none of the review detail.

## Restriction three: write the rule on the role, not the team

In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule therefore reaches every member who holds a role, or one named member. To keep a team off a tool, write the rule on the role its members hold, or on each member.

Two layers then apply at once: the rules on the role, and the rules aimed at the person. A connector or tool is reachable only when both admit it. A personal rule can narrow what a role allows and never widen it, as the [resolver's order of checks](/blog/restriction-resolver-decision-tree/) shows. If an admin later approves an access request for one person, that creates an access grant. The grant lifts the role rules for that connector or tool for them alone. It writes no restriction rule and changes nobody else's reach. Restrictions are read-only on every AI surface, so nobody talks Claude into editing them.

## Who the connection acts as inside Vanta

Every call through a connection uses that connection's own stored credential, whoever makes the call. A connection shared with a team acts as the account that signed in when it was created.

For compliance work that is a real fork. If members each connect with their own sign-in, their own permissions in the app apply. The audit trail on the vendor's side names them. If the connector signs in with an API token or another single credential, everyone sharing that connection acts as one identity upstream. Only Elaichi's audit log then tells you which person asked. Pick the first where the app's own roles mean something. Pick the second where you want one fixed, narrow permission set.

## The audit query that proves the restrictions

Open the audit log in the console. Set the category filter to Assistant and search the connector's name. Connected-tool calls sit in the Assistant category, not MCP, because their action is assistant.toolbox_tool. The MCP category holds client grants and similar events. Over the API the same query is GET /audit-log with q, category and since.

Each row's detail panel opens with where the call ran. Then it names who did what to which item through which connection, in a sentence that starts "Using Claude,". Below that sit lines for Connector, Connection, Ran from, What it did and Approval. For a read, What it did reads Read data. The Approval line reads "Didn't need approval because it only read data". For a call from an MCP client it reads "Allowed by the access Claude was granted". Export the filtered view as CSV for the reviewer. An export longer than 10,000 entries stops rather than saving a partial file.

Be honest about what that proves. The log shows every call that reached execution. A call a restriction withheld, or one refused for a missing scope, writes no row at all. The absence of write calls is not by itself proof that writes were impossible. Pair it with the restriction.created and restriction.updated rows, which record when the rule was written and by whom. Keep the connector.tool_updated rows from your reviews alongside them. Elaichi keeps 90 days of audit history. A longer trail means forwarding it to your own log service, which comes with the Black plan, launching soon. On what a reviewer should expect from each row, see [what an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/).

One staffing note. A compliance reviewer can hold the Auditor role, which carries 12 view permissions including audit:view and restriction:view. It is a free seat rather than a billable one. They can read the whole organization's log and every restriction, and change nothing.

## When you do not need any of this

If one person does the compliance work and Vanta is the only app they touch, this is overhead. Vanta's own interface already enforces Vanta's own permissions. A single reviewer reading a single app does not need a second vendor in the path. The case for one address and one set of rules starts when several people, across several roles, reach several apps from more than one AI client. That threshold is drawn more carefully in [when an MCP gateway is premature](/blog/when-you-dont-need-an-mcp-gateway/). The wider model of roles, restrictions and grants sits in the [MCP governance pillar](/blog/mcp-governance/).

## FAQ

### Is Vanta in Elaichi's connector catalog?

Check the catalog at elaichi.ai/connectors before assuming either way. Elaichi's catalog holds 650+ connectors of two kinds: connectors Elaichi authors and runs itself, and native MCP connectors, where the vendor builds and runs its own MCP server and Elaichi handles sign-in, access and audit in front of it. If an app is not in the catalog, an organization on the Gold plan can add that vendor's remote MCP server as its own connector, which needs the connector:create permission that only Org Owner and Org Admin hold among the built-in roles.

### If I leave "Create and change data" unticked when connecting Claude, can it still change data in a connected app?

Yes. On Elaichi's consent screen, "Create and change data" (mcp:write) governs Elaichi's own write operations. "Run your connected tools" (mcp:tools) runs every tier of connected tool, writes and deletes included, so unticking the write box does not make a connected app read-only. To hold a client to reads, either pick toolboxes of read tools at consent, or block the app's write and delete tools with a restriction on the role.

### Which audit log category shows a tool call a Claude user made in a connected app?

The Assistant category. In Elaichi, a connected-tool call is recorded with the action assistant.toolbox_tool, which falls under Assistant whatever client made it. The MCP category holds actions that start with mcp or oauth_grant, such as a client's OAuth grant being created or revoked, so filtering the audit log to MCP does not show tool calls.

### Does Elaichi send my AI client's token to the vendor's MCP server?

No. Elaichi never forwards its own MCP access token to a remote MCP server. An OAuth server behind a remote MCP connector sees only a token its own authorization server issued, and the AI client holds only an Elaichi token. The connection's credential is held by Elaichi's separate credential service, encrypted at rest with AES-256-GCM, and fetched into memory only for the call that needs it.

### How quickly does a new restriction apply to someone's AI client?

Within about two minutes. Role, team membership, restriction and access-grant changes reach every surface once each location sees the organization's new cache epoch, which the product's own design puts at roughly two minutes in the worst case. Some changes are faster and are effective on the next call: revoking a grant, removing or suspending a member, revoking a share and disconnecting an account.

## Read next

- [MCP restriction resolver precedence, as a decision tree](/blog/restriction-resolver-decision-tree/) — How the mcp restriction resolver precedence works across Elaichi's enforcement points, traced through one real tool call from browse to outbound request.
- [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.