Whose Snowflake user does the call act as?
Connect Snowflake to Claude, and an admin can ask which people hold ACCOUNTADMIN and get a list back. The question a security review asks next is whose Snowflake user read that. The answer is the user behind the connection, never the person chatting.
Elaichi's Snowflake connector is Snowflake's object-management API. Its tools manage users, roles, grants and warehouses: list_all_snowflake_users, list_all_snowflake_roles, list_all_snowflake_role_grants, list_all_snowflake_user_grants, snowflake_role_grants_grants_of and list_all_snowflake_warehouses on the read side, and create_a_snowflake_user, create_a_snowflake_role, create_a_snowflake_role_grant, create_a_snowflake_user_grant, update_a_snowflake_user_by_id, snowflake_role_grants_revoke, snowflake_user_grants_revoke, delete_a_snowflake_user_by_id, delete_a_snowflake_role_by_id, snowflake_warehouses_suspend, snowflake_warehouses_resume, snowflake_warehouses_abort_queries and update_a_snowflake_warehouse_by_id on the write side. There are future-grant and database-role grant tools alongside those.
The connector reaches further than access administration. It also has database and table tools, get_single_snowflake_result_by_id, and tools that run code inside Snowflake: snowflake_procedures_call, snowflake_functions_execute, snowflake_tasks_execute and snowflake_notebooks_execute. Treat the four that run code as write-class, and keep every tool in this paragraph off any review or audit role.
Read the two grant tools carefully, because they answer different questions. list_all_snowflake_role_grants lists the grants given to a role, meaning what that role can reach. Who holds a role comes from snowflake_role_grants_grants_of.
The connector signs in with OAuth, so a person's connection acts as their own Snowflake user, on top of whatever Elaichi allows. Every call through a connection fetches that connection's own stored credential, and the caller's identity plays no part in which credential is used. A connection shared at the use level therefore acts as its owner's Snowflake user, for everyone it is shared with.
That leaves two shapes, and you pick one before you connect Snowflake to Claude:
- Per-person connections. Each admin adds their own Snowflake connection and leaves it private. Each person's own Snowflake roles then bound what their calls can do. The same per-person shape, for Google accounts rather than a warehouse, is worked through in Sheets and Docs across a whole team.
- One shared connection. One person connects, then shares it at use. Everyone acts as that one Snowflake user, which suits a read-only review account the whole team should share.
Elaichi records who asked, either way. Every call made with a grant (the approval a person gives one AI client on Elaichi's consent screen) acts as the person who approved it, and the audit row names them. A shared credential is not an anonymous one. The same mechanic, seen from the sales side, is laid out in per-rep CRM access.
How to connect Snowflake to Claude for a platform team
The order matters: connect the app first, write the rules second, let people connect their clients third. Doing it the other way round means the first week of calls runs under no restrictions at all.
- One person on the platform team opens Connections in Elaichi and selects Add connection. The dialog asks you to choose the connector, gives an optional label, and starts Share with at Private. Connect then opens the Snowflake sign-in step. The Snowflake connector page lists its tools before you start.
- Decide sharing. Leave it private for per-person access. Share it at use for a shared review account. A view grant does not run tools, and an edit grant lets that person reconnect it.
- Write the restrictions on each role, as below. Role and restriction changes take effect within about two minutes, so do this before anyone signs a client in.
- Add Elaichi once in Claude. On Team and Enterprise plans an Owner or Primary Owner adds it as a custom connector in the organization's connector settings (Anthropic's remote MCP help article, checked October 2026). Connect Elaichi to Claude has the exact clicks for each plan. The address is
https://api.elaichi.ai/mcp, the same string for every organization, with no key to paste. - Each person finds it under Customize > Connectors and clicks Connect (Anthropic's remote MCP help article, checked October 2026), signs in to Elaichi and approves their own grant.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Once connected, connected tools are never listed one by one, however few there are. Claude finds them with search_tools and runs them with execute_tool. The client-side walkthrough, with the consent screen step by step, is in connecting Claude to Elaichi.
Anthropic's outbound traffic to MCP servers comes from 160.79.104.0/21 (Anthropic's connector authentication docs, checked October 2026). The same page says Claude uses a Client ID Metadata Document only where the authorization server advertises support for one. Elaichi does not advertise it, so Claude registers itself through dynamic client registration, and nobody pastes a client id or secret.
One thing the consent screen cannot do: hold Snowflake to reads. Ticking "Run your connected tools" lets that client run every tier of connected tool, writes and deletes included. "Delete data and remove access" covers Elaichi's own deletes, not a connected app's. Read-only is a restriction, not a checkbox.
Three restrictions that stop the obvious failure
A restriction is a rule on a role, or on one member, saying which connectors and which single tools they may reach. Three rules cover what a platform team actually worries about here.
Hold a review role to an allow rule, not a block list. For a role that should only review access, write an allow rule naming exactly six read tools: list_all_snowflake_users, list_all_snowflake_roles, list_all_snowflake_role_grants, list_all_snowflake_user_grants, snowflake_role_grants_grants_of and list_all_snowflake_warehouses. Every other tool on the connector then stays unreachable for that role. That includes create_a_snowflake_user_grant, update_a_snowflake_user_by_id, create_a_snowflake_role, the future-grant and database-role grant tools, the database and table tools, and the tools that run code inside Snowflake. A block list cannot do this job, because a layer with only block rules has no allowlist, so everything it does not block passes it, which leaves any tool the rules do not name reachable.
Know what an allowlist does to the rest of the role's apps. The Snowflake allow rule above switches the review role to an allowlist across every connector, not just Snowflake. So the role also needs an allow rule for every other app it uses. Mind the empty case too: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. The empty allow rule trap and the wider allowlist against blocklist question both go deeper.
Keep the connector away from every other role. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. If only the platform team should reach Snowflake at all, write a rule on each other role blocking the connector whole. A whole-connector block also blocks every fork that declares descent from it.
Do not read tool names and guess the tier. Elaichi classifies a catalog tool from the HTTP verb and method it performs, and a documented annotation can mark a POST search read-only, so a name alone proves nothing. The label on the connector page is the thing to read: it marks each tool Read only or Makes changes. Allow rules match the stored operation rather than the name, which is covered in why blocks match names and allows do not.
Restrictions are checked for the person calling, at execution, before the connection is used. That is why they bind whatever sends the call, a scheduled task or a Code Mode program included. Claude's own tool permissions take one of three settings: Always allow, Needs approval or Blocked (Anthropic's connectors article, checked October 2026). Each applies to a whole connector, a category of its tools, or one tool. No tool in Elaichi's list names a connected app, so a client-side per-tool control cannot single out one Snowflake tool. Per-tool control lives in Elaichi.
Where a tool takes an argument you want fixed for everyone, pin the connection into a toolbox entry and freeze that argument. The model can see a short frozen value and cannot change it, which is the point of locking tool arguments.
The audit query that proves the restrictions hold
Two questions get asked later: did anything change a grant, and who ran what. Both are answered from one place.
In the console, open Governance, then the Audit log tab, filter the category to Assistant and search the connector name. Connected-tool calls sit in the Assistant category, because their action is assistant.toolbox_tool. The MCP category holds grant events, not tool calls, which is where most people look first and find nothing.
Over the API the same read is:
GET /audit-log?category=assistant&q=snowflake&since=2026-10-01T00:00:00Z
Free text matches each word anywhere in the action, the resource type and id, the acting user id and the event's metadata. It also returns events by members whose name or email matches. Entries come back newest first, 50 a page by default and at most 200, behind an opaque cursor. There is no end-time filter, so narrow with the start time and page forward.
In Elaichi, the log keeps one entry for each connected-tool call that reaches execution (a call refused earlier writes none). For this playbook the field that matters is the tool's classification, next to the person and the Snowflake connection the call reached. What an AI agent audit log must capture lists every other field.
The classification field is the evidence. A month of Snowflake rows all classified as reads, with no write or delete row, is what a reviewer wants to see when the claim is that nobody changed a grant through Claude. The console says it in a sentence in the detail panel, for example "Using Claude, Emily Carter...", with an Approval line reading "Didn't need approval because it only read data".
Reading the whole organization's log needs the audit:view permission, held by Org Owner, Org Admin and the read-only Auditor role, which does not take a billable seat. Without it, a member sees their own events and those of connections they own or can edit. The console exports the current view as CSV with its filters applied, up to 10,000 entries. Elaichi keeps 90 days of audit history; for anything longer, see audit retention at 90 days.
What the audit row does not record
It does not record the arguments. A connected-tool row records no argument values apart from the one path argument that names the object, and it records neither argument names nor an argument count. For a list or search call it records the resource type and how many items came back, nothing about the items themselves. Connected-tool rows carry no duration either.
So be precise about what you are promising a reviewer. The audit log proves who ran which tool, as which connection, with what classification, from which AI client, and whether it worked. For the full before-and-after of a grant change, Snowflake's own account history is the second half of the evidence pack.
The other thing not in the row is a human approval. Over MCP there is no per-call approval step: the grant is the approval, decided once on Elaichi's consent screen. Any prompt a person sees before a call is their own client asking. The layers, and where each one actually sits, are set out in approval for AI agent actions.
When a platform team does not need this
One admin, one client, one Snowflake user, and a reviewer satisfied by Snowflake's own account history: that team does not need a control plane yet, and buying one adds a vendor without removing a risk. The honest version of that argument is in when you do not need an MCP gateway.
The case changes on the second thing. A second AI client, a second app the same admins reach, or a second team asking to review the same grants, and the rules and the trail start living in two places that disagree. One governed address is worth it at that point, not before.
What changes when an admin leaves
Removing or suspending a member revokes every grant they hold in that organization, so their Claude connection fails on its next call rather than after a token expires. Reactivating them does not bring the grants back; they consent again.
Their connections need a decision during the removal, not after. A private connection nothing else depends on is deleted with them. A shared connection stays owned by the removed member unless you transfer it in the same removal, and afterwards only an owner can transfer or delete a connection, so there is no one left who can. Toolbox entries they pinned stop resolving for everyone until somebody with edit access re-pins them.
Removal ends their reach through Elaichi. It does not touch their own Snowflake user, which still has to be dropped there or through your identity provider. The full sequence, contractors included, is in offboarding AI access.
For the layers underneath all of this, roles against restrictions against sharing, start at MCP governance. The directory-side shape, for Okta rather than a warehouse, is in Okta access for IT admins, and the tools themselves are listed on the Snowflake connector page.
