> For the complete documentation index, see [llms.txt](https://docs.oort.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.oort.io/integrations/snowflake.md).

# Snowflake

## Overview

Cisco Identity Intelligence can connect directly to Snowflake warehouses to gather data on user accounts, activity, and other events. These instructions will guide you through the process of connecting your Snowflake account to Identity Intelligence.

## Before you begin...

Make sure you have the following:

* An Identity Intelligence account with Admin permissions that can add integrations to your Identity Intelligence tenant
* A Snowflake login that has `ACCOUNTADMIN` privileges to grant read access to the `SNOWFLAKE` database in your Snowflake account
* The name of your Snowflake warehouse
* The values for the AWS ARN and AWS Account Id that Cisco Identity Intelligence will be using when connecting to your Snowflake account. These can be found on the Intial Setup dialog when creating a new Snowflake integration in Identity Intelligence

## Configuration Steps

### Provision a Identity Intelligence user in Snowflake

To provision the user, you will need to:

1. **Create a role for Identity Intelligence to use and grant it the necessary privileges**
   1. Choose a name for the role that you will assign to the Identity Intelligence user's role
   2. In the examples below, replace `<cii_integration_role>` with the name you choose. Replace `<warehouse name>` with the name of your Snowflake warehouse.
   3. Using the "Query Data" UI in Snowflake, enter each of the following lines individually to provision the role:

<pre><code><strong>CREATE ROLE &#x3C;cii_integration_role>;
</strong></code></pre>

```
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE <cii_integration_role>;
```

```
-- This grant allows CII to read Trust Center events
GRANT APPLICATION ROLE SNOWFLAKE.TRUST_CENTER_VIEWER TO ROLE <cii_integration_role>;
```

```
GRANT USAGE ON WAREHOUSE <warehouse name> TO ROLE <cii_integration_role>;
```

2. **\[Recommended, but optional]** Allow Identity Intelligence to discover your Snowflake-managed MCP servers. For ***each*** database that contains MCP servers, run the commands listed below. Identity Intelligence needs USAGE on the database, its schemas, and the MCP servers to see them

   ```
   GRANT USAGE ON DATABASE <database name> TO ROLE <cii_integration_role>;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE <database name> TO ROLE <cii_integration_role>;
   GRANT USAGE ON FUTURE SCHEMAS IN DATABASE <database name> TO ROLE <cii_integration_role>;
   GRANT USAGE ON ALL MCP SERVERS IN DATABASE <database name> TO ROLE <cii_integration_role>;
   GRANT USAGE ON FUTURE MCP SERVERS IN DATABASE <database name> TO ROLE <cii_integration_role>;
   ```

   **Note**: These grants let Identity Intelligence see the servers and their tools. They don't give Identity Intelligence access to any data beyond what its role already has\
   \
   Snowflake ignores the database-level future grant in any schema that has its own future grants on MCP servers, even grants to other roles. Check each schema that will contain MCP servers:<br>

   ```
   SHOW FUTURE GRANTS IN SCHEMA <database name>.<schema name>;
   ```

   \
   Only where that check lists an MCP server future grant, then run the following command. Do **NOT** run the schema-level grant anywhere else. Doing so makes Snowflake ignore your database-level future grants in that schema<br>

   ```
   GRANT USAGE ON FUTURE MCP SERVERS IN SCHEMA <database name>.<schema name> TO ROLE <cii_integration_role>;
   ```
3. **Create a service account user identified by the AWS Workload Identity Federation and give it access to the role**
   1. Choose a name for the role that you will assign to the Identity Intelligence service account user
   2. In the examples below, replace `<cii_service_user>` with the name you choose. Replace `<cii_integration_role>` with the name of the role you created in the previous step. Replace `<cii_lambda_arn>` with the arn displayed in the Initial Setup dialog for snowflake in Identity Intelligence
      1. ```
         CREATE USER <cii_service_user>
         DEFAULT_ROLE = <cii_integration_role>
         TYPE = SERVICE
         WORKLOAD_IDENTITY = (
         TYPE = AWS
         ARN = '<cii_lambda_arn>');
         ```
4. Next, execute the following commands to limit access to the new service account from just the AWS account id for Identity Intelligence. Replace `<cii_wif_auth_policy>` with the name you choose. Replace `<cii_account_id>` with the account id displayed in the Initial Setup dialog for snowflake in Identity Intelligence
   1. ```
      CREATE AUTHENTICATION POLICY <cii_wif_auth_policy>
      WORKLOAD_IDENTITY_POLICY = (
      ALLOWED_AWS_ACCOUNTS = ('<cii_account_id>'));
      ALTER USER <cii_service_user> SET AUTHENTICATION POLICY <cii_wif_auth_policy>;
      ```
5. Next, execute the following command to give the new service account user access to the role:
   1. `GRANT ROLE <cii_integration_role> TO USER <cii_service_user>;`
6. If you would like to further secure Identity Intelligence's access to your warehouse by restricting the allowed IP addresses, you may also add a network policy to the user you just created. In the example below, replace the `<nat_ip>` placeholders with the IPs for your region (found in the Initial Setup for Snowflake in Identity Intelligence):
   1. ```
      CREATE OR REPLACE NETWORK POLICY <cii_service_network_policy>
      ALLOWED_IP_LIST = ('<nat_ip_1>', '<nat_ip_2>')
      COMMENT = 'Created for CII. Only allows access from known CII NAT gateways';
      ALTER USER <cii_service_user> SET NETWORK_POLICY = <cii_service_network_policy>;
      ```

      For more information, see the Snowflake documentation on [network policies](https://docs.snowflake.com/en/sql-reference/sql/create-network-policy) and the [alter user command](https://docs.snowflake.com/en/sql-reference/sql/alter-user)

### Create your integration in Identity Intelligence

The last step is to create your integration in Identity Intelligence. For this, you will need:

* The name of the service account user you created in Snowflake
* The name of the role you assigned to the service account user in Snowflake
* The [account locator and region](https://docs.snowflake.com/en/user-guide/admin-account-identifier#format-2-account-locator-in-a-region) for your Snowflake account. Please note that your organization and account name will NOT work instead.
  * If you are having trouble finding this, you can run\
    `SELECT current_account(), current_region();` in your Snowflake account. You should see that the account is a string of letters and numbers like `SF12345` and the region is something like `AWS_US_WEST_2`. For these values, the combined identifier would be `sf12345.us-west-2.aws`
* The name of your Snowflake warehouse

1. Navigate to the Integrations page in Identity Intelligence and click "Add Integration" at the top right

<figure><img src="https://582105988-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FqPSBzsjxd7KYg9DNVZ4l%2Fuploads%2FXCgyUXD7VM4DuErv8UZi%2FScreenshot%202024-11-18%20at%206.31.10%E2%80%AFPM.png?alt=media&amp;token=21110473-1f1d-4c9e-9b44-ccdbfea556ba" alt="" width="375"><figcaption></figcaption></figure>

2. Find the Snowflake tile and click "Add Integration"

<figure><img src="https://582105988-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FqPSBzsjxd7KYg9DNVZ4l%2Fuploads%2Fw7N6aLRumgjsbkoYozCd%2FScreenshot%202024-11-18%20at%206.32.26%E2%80%AFPM.png?alt=media&amp;token=e1aac7ca-8a57-4f22-ba0a-2a1af5fa50cd" alt="" width="188"><figcaption></figcaption></figure>

3. Click "Complete Setup" below the instructions to go to the General Settings configuration

<figure><img src="https://582105988-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FqPSBzsjxd7KYg9DNVZ4l%2Fuploads%2FdyqeaEUlSUmG79f3tuM1%2FScreenshot%202026-03-16%20at%2011.22.10%E2%80%AFAM.png?alt=media&amp;token=4e2442b5-5735-4748-9dd7-85689d76f78b" alt=""><figcaption></figcaption></figure>

4. You should now see the form in the screenshot

<figure><img src="https://582105988-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FqPSBzsjxd7KYg9DNVZ4l%2Fuploads%2FmZjvMcCD73YZB83klD9M%2FScreenshot%202026-03-16%20at%2011.24.08%E2%80%AFAM.png?alt=media&amp;token=7669d400-09ed-422e-9d9c-a5966ad7f81d" alt=""><figcaption></figcaption></figure>

4. Choose and enter a name for your integration within Identity Intelligence that relates to the specific Snowflake warehouse that will be monitored into the "Name" field
5. In the "Service Account Name for CII" field, enter the name of the service account user you created in Snowflake
6. In the "Service Account Role" field, enter the name of the role you assigned to the service account user in Snowflake
7. In the "Your Snowflake Account Identifier" field, enter the [account locator and region](https://docs.snowflake.com/en/user-guide/admin-account-identifier#format-2-account-locator-in-a-region) for your Snowflake account
8. In the "Your Snowflake Warehouse" field, enter the name of your Snowflake warehouse
9. Once you have entered the necessary information, click "Connect" to initialize your Snowflake integration and begin monitoring

## Enable Cortex Agent Collection for Snowflake Integration

To allow Identity Intelligence to collect Cortex Agent metadata and observability events, the Snowflake role used by the existing Identity Intelligence integration service account (`<cii_integration_role>`) must be granted privileges for:

1. Agent discovery ([`SHOW AGENTS IN ACCOUNT`](https://docs.snowflake.com/en/sql-reference/sql/show-agents))
2. Agent inspection ([`DESCRIBE AGENT <agent_name>`](https://docs.snowflake.com/en/sql-reference/sql/desc-agent))
3. Observability event reads ([`SNOWFLAKE.LOCAL.GET_AI_OBSERVABILITY_EVENTS`](https://docs.snowflake.com/en/sql-reference/functions/get_ai_observability_events-snowflake-local))
4. Optional un-redacted observability content reads, if you want Identity Intelligence to collect Cortex Agent conversation content such as user prompts, executed SQL queries, and agent responses.

**Why these grants are required**

* Snowflake requires the executing role to have at least one privilege on each agent (`OWNERSHIP`, `USAGE`, `MONITOR`, or `OPERATE`) for `SHOW AGENTS` / `DESCRIBE AGENT` . On the agents themselves, Identity Intelligence only needs MONITOR, which lets it read each agent's configuration and activity but not run the agent. Don't grant USAGE or OPERATE on agents to Identity Intelligence. USAGE on the parent database and schemas is still required (step 1 in the grants below)
* Snowflake also requires at least one privilege on the parent database and parent schema for those commands
* Reading agent events with `GET_AI_OBSERVABILITY_EVENTS` requires `MONITOR` on the agent and the `SNOWFLAKE.CORTEX_USER` database role. The integration role already has `CORTEX_USER`, because Snowflake includes it with `IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE`, granted during setup. No AI Observability application role is needed
* Access to un-redacted Cortex Agent conversation content requires the `READ UNREDACTED AI OBSERVABILITY EVENTS TABLE` account privilege

#### Managing Cortex Agent Conversation Data Collection Preferences

Snowflake Cortex Agent observability events can include both conversation metadata and conversation content. Identity Intelligence can leverage conversation metadata to understand agent usage patterns, tool execution, timing, errors, and other activity details. Conversation content can provide deeper insight into user prompts, SQL queries executed by agents, and agent responses.

Because conversation content may be sensitive, Identity Intelligence provides collection settings that let you determine what Cortex Agent conversation data Identity Intelligence is allowed to process and retain based on your org's needs.

The available settings are:

1. **Do not collect Cortex Agent conversation logs**
   1. Identity Intelligence will not retain Cortex Agent conversation metadata or content from observability events
2. **\[Default Setting] Collect conversation metadata only without conversation content**
   1. Identity Intelligence will retain Cortex Agent conversation metadata and executed SQL queries, but will not retain fields containing user prompts, or agent responses
3. **Collect conversation metadata and conversation content**
   1. Identity Intelligence will collect and retain Cortex Agent conversation metadata and content, including user prompts, executed SQL queries, and agent responses

| Capability / Data                                                                                                      | Option 1: Do not collect Cortex Agent conversation logs | Option 2: Collect conversation metadata only without conversation content                 | Option 3: Collect conversation metadata and conversation content |
| ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| Cortex Agent inventory and configuration (e.g. agent name, creation date, tools and resources)                         | ✅                                                       | ✅                                                                                         | ✅                                                                |
| Conversation metadata (e.g. timestamp, session and record ids, event name, status code, actor user name, SQL query id) |                                                         | ✅                                                                                         | ✅                                                                |
| User prompts                                                                                                           |                                                         |                                                                                           | ✅                                                                |
| Executed SQL query text                                                                                                |                                                         | Only if `READ UNREDACTED AI OBSERVABILITY EVENTS TABLE ON ACCOUNT` is granted (see below) | ✅                                                                |
| Agent responses                                                                                                        |                                                         |                                                                                           | ✅                                                                |

Snowflake also controls whether unredacted observability content is visible to the integration role.\
\
If you select either **Collect conversation metadata and conversation content**, OR **Collect conversation metadata only without conversation content** and you want Identity Intelligence to collect also the executed SQL queries, you ***must*** also grant the following Snowflake account privilege to `<cii_integration_role>` :

```
GRANT READ UNREDACTED AI OBSERVABILITY EVENTS TABLE ON ACCOUNT TO ROLE <cii_integration_role>;
```

If this privilege is **not** granted, Snowflake will only expose metadata to the integration role even if Identity Intelligence is configured to collect conversation content.

<figure><img src="https://582105988-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FqPSBzsjxd7KYg9DNVZ4l%2Fuploads%2F92CwXmyoYtwFralfiv21%2FScreenshot%202026-08-04%20at%201.54.32%E2%80%AFPM.png?alt=media&amp;token=a2de2cbd-d41b-46e9-bd10-f8df6e6daee9" alt="" width="563"><figcaption></figcaption></figure>

#### **Configuring the required grants**

Using a role that can grant the necessary permissions (typically `ACCOUNTADMIN` or equivalent role with required grant authority), run the following:

```
-- 1) Parent database and schema access. Repeat for each database that contains agents.
--    Skip if you already ran these for MCP servers during setup.
GRANT USAGE ON DATABASE <database_name> TO ROLE <cii_integration_role>;
GRANT USAGE ON ALL SCHEMAS IN DATABASE <database_name> TO ROLE <cii_integration_role>;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE <database_name> TO ROLE <cii_integration_role>;
--    To limit access to specific schemas instead, replace the two schema grants with:
--    GRANT USAGE ON SCHEMA <database_name>.<schema_name> TO ROLE <cii_integration_role>;

-- 2) Existing and future agents. Repeat for each database.
GRANT MONITOR ON ALL AGENTS IN DATABASE <database_name> TO ROLE <cii_integration_role>;
GRANT MONITOR ON FUTURE AGENTS IN DATABASE <database_name> TO ROLE <cii_integration_role>;

-- 3) Optional: only required if Identity Intelligence should collect Cortex Agent conversation content.
GRANT READ UNREDACTED AI OBSERVABILITY EVENTS TABLE ON ACCOUNT TO ROLE <cii_integration_role>;
```

As with MCP servers, Snowflake ignores the database-level future grant in any schema that has its own future grants on agents. Run `SHOW FUTURE GRANTS IN SCHEMA <database_name>.<schema_name>;` on each schema that will contain agents. Only where it lists an agent future grant, also run `GRANT MONITOR ON FUTURE AGENTS IN SCHEMA <database_name>.<schema_name> TO ROLE <cii_integration_role>;`\
\
If you configured a Snowflake integration using an earlier version of these instructions (prior to Oct 2026), your existing grants still work and you don't need to change anything. Optionally, you can switch to the grants above. They're simpler and also cover new agents.

#### Verification (optional)

After grants are applied, use the following to test with the Identity Intelligence integration role:

```
USE ROLE <cii_integration_role>;
USE SECONDARY ROLES NONE;
SHOW MCP SERVERS IN ACCOUNT;
SHOW AGENTS IN ACCOUNT;
DESCRIBE AGENT <db>.<schema>.<agent_name>;
SELECT COUNT(*) FROM TABLE(SNOWFLAKE.LOCAL.GET_AI_OBSERVABILITY_EVENTS('<db>', '<schema>', '<agent_name>', 'CORTEX AGENT'));
```