Skip to main content

Connecting Snowflake to AlphaSense

Kristin Mize
Updated

The Snowflake integration lets you securely connect your organization's Snowflake data to AlphaSense for live querying and analysis alongside external research. It runs through Snowflake's managed Cortex MCP server, which exposes Cortex Analyst, Cortex Search, Cortex Agents, and SQL execution as governed tools. This is a real-time connection: AlphaSense invokes these tools at request time and does not ingest or store a copy of your data. Authentication uses Snowflake's built-in OAuth, and every session runs under the connecting user's DEFAULT_ROLE, so Snowflake RBAC governs exactly what each user can see. (Snowflake: managed MCP server)

Before You Begin

  • You must have an active Snowflake account with Cortex available and an accessible virtual warehouse for compute.
  • A Snowflake administrator with ACCOUNTADMIN (or a role with CREATE INTEGRATION, CREATE ROLE, and privileges to create an MCP server) must set up the OAuth security integration, create the MCP server, and grant access. (Snowflake: managed MCP server)
  • Access is governed by Snowflake RBAC. Granting access to the MCP server alone is not enough, each underlying tool and resource needs its own grant. Users only see what their DEFAULT_ROLE is permitted to read.

Step 1: Administrator Setup

Admin SQL

In Snowflake run the following configuration, you must be a Snowflake ACCOUNTADMIN . This follows the Snowflake team's 2026-06-10 implementation guide.

Command 1 — Create the OAuth security integration

CREATE SECURITY INTEGRATION IF NOT EXISTS ALPHASENSE_OAUTH
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = '<https://research.alpha-sense.com/integration/callback/>'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
  OAUTH_ENFORCE_PKCE = TRUE;

Command 2 — Retrieve the client ID and secret

-- Get the OAUTH_CLIENT_ID:
DESC SECURITY INTEGRATION ALPHASENSE_OAUTH;
--   ^ Look for the OAUTH_CLIENT_ID row in the output.

-- Get one of the two OAUTH_CLIENT_SECRETs (either works):
SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('ALPHASENSE_OAUTH');

Command 3 — Grant access to the MCP server and the objects its tools read

AlphaSense calls the MCP server surface (tools/list + tools/call), which uses a two-layer grant model. Replace db, schema, server, view, wh, role;, and username with your values.

-- Layer 1: MCP server discovery (tools/list). Without USAGE on the
-- MCP server, tools/list returns empty.
GRANT USAGE ON DATABASE   <db>                     TO ROLE <role>;
GRANT USAGE ON SCHEMA     <db>.<schema>            TO ROLE <role>;
GRANT USAGE ON MCP SERVER <db>.<schema>.<server>   TO ROLE <role>;

-- Layer 2: per-tool underlying objects (tools/call). Without these,
-- invocation fails even though tools/list succeeds.
GRANT SELECT ON SEMANTIC VIEW <db>.<schema>.<view> TO ROLE <role>;  -- CORTEX_ANALYST_MESSAGE
GRANT USAGE  ON WAREHOUSE     <wh>                 TO ROLE <role>;  -- SYSTEM_EXECUTE_SQL
-- + GRANT SELECT on any tables/views SYSTEM_EXECUTE_SQL must read.

-- MCP sessions use each user's DEFAULT_ROLE + DEFAULT_WAREHOUSE, so
-- ensure both point at a role/warehouse that has the grants above:
ALTER USER <username> SET DEFAULT_ROLE = '<role>' DEFAULT_WAREHOUSE = '<wh>';

Paste the required fields in AlpahSense.

Step 2: Individual User Connection

Once the admin has set up OAuth, the MCP server, and grants:

  • Each user authorizes from AlphaSense via Snowflake's built-in OAuth and connects under their own identity.
  • The session runs under the user's DEFAULT_ROLE, so the tools they can discover and invoke, and the data those tools return, mirror that role's grants.
  • Clients that request all secondary roles (session:role:all) aren't supported for MCP sessions; access stays bound to the DEFAULT_ROLE.

What's Accessible

AlphaSense invokes Cortex MCP tools live; nothing is ingested. Availability depends on the connecting role's grants:

Tool What AlphaSense can do (read-only)
Cortex Analyst Translate a natural-language question into SQL over a semantic view and return rows.
Cortex Search Semantic / keyword search over a configured Cortex Search service.
SQL execution Run SELECT queries against the warehouse (DML/DDL blocked in read-only posture).
Cortex Agents Run a configured agent that orchestrates Search + Analyst tools.
Custom (GENERIC) Invoke a UDF or stored procedure exposed as a read tool, per-object grant required.

How It Works

  • Real-time access, no stored copy. AlphaSense discovers tools (tools/list) and invokes them (tools/call) on Snowflake's managed MCP server at request time. Snowflake confirms the server and tool are enabled before executing. Results are not ingested or indexed into AlphaSense. (Snowflake: managed MCP server)
  • Permissions evaluated at query time. Every session runs under the user's DEFAULT_ROLE, and the same RBAC, masking, and row-access policies that protect the data apply to the tool call. Access to the MCP server alone grants nothing, each tool/resource is granted separately. (Snowflake: access control overview)

Items to Note

  • Read-only by design. SQL execution is limited to SELECT; DML/DDL is blocked in the read-only posture. [CONFIRM]
  • Per-tool grants required. USAGE on the MCP server does not grant the tools; each Cortex resource, view, agent, or UDF must be granted to the role.
  • Default role only. Secondary roles aren't supported in MCP OAuth sessions; the session uses DEFAULT_ROLE.
  • OAuth set up first. A per-account OAuth security integration must exist before connecting; recommended over hardcoded tokens. If using a PAT, restrict it to a least-privileged role.
  • Warehouse + result size. Tool calls consume warehouse compute; a single natural-language query can scan and return large, potentially sensitive result sets, so scope roles carefully.
  • Cortex Analyst quality depends on the configured semantic view; ambiguous questions can mis-map columns. [CONFIRM]

Review data security, architecture, and more at https://trust.alpha-sense.com/

Modify or Revoke Access

To change what's accessible (admin):

  1. Adjust the access role's grants in Snowflake, GRANT/REVOKE USAGE on the MCP server or specific tools/resources, or SELECT on semantic views. Changes apply on the next call because permissions are evaluated live.
  2. To rotate or revoke credentials, adjust or disable the OAuth security integration, or revoke a PAT.

To disconnect:

  1. Click Disconnect on the Snowflake integration tile in AlphaSense, or disable/drop the OAuth security integration or MCP server in Snowflake.
  2. AlphaSense stops invoking Snowflake tools. Because nothing was ingested, there is no stored Snowflake data to remove.

Troubleshooting & FAQs

I can't connect Snowflake in AlphaSense.

Confirm the admin created the OAuth security integration and MCP server, and granted your role USAGE on the server.

I'm connected but don't see a tool or any data.

USAGE on the MCP server isn't enough; your DEFAULT_ROLE needs grants on each underlying tool/resource (e.g. SELECT on the semantic view, USAGE on the Cortex Search service). Ask your admin to add them.

I have access to more roles than I'm seeing.

MCP OAuth sessions ignore secondary roles and use your DEFAULT_ROLE. Ask your admin to set the right default role, or to use a dedicated role for AlphaSense.

Can AlphaSense change data in Snowflake?

No. In the read-only posture, SQL execution is restricted to SELECT and DML/DDL is blocked.

Are our credentials shared with anyone?

No. OAuth tokens are stored encrypted server-side and used only to invoke the tools your role is authorized for, in real time.

What happens to our data when we disconnect?

AlphaSense stops querying Snowflake and the credentials are revoked. Since data is never ingested, there is no stored copy to delete.

Sources

All Snowflake platform facts in this guide are drawn from Snowflake's official documentation:

Was this article helpful?

0 out of 0 found this helpful
Return to top