Snowflake (Beta)

2025.06.17

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:

CREATE ROLE <cii_integration_role>;

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>;

1. 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>');

2. 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>;

3. 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>;

4. 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 and the alter user command

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 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

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

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

1. You should now see the form in the screenshot

1. 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

2. In the "Service Account Name for CII" field, enter the name of the service account user you created in Snowflake

3. In the "Service Account Role" field, enter the name of the role you assigned to the service account user in Snowflake

4. In the "Your Snowflake Account Identifier" field, enter the account locator and region for your Snowflake account

5. In the "Your Snowflake Warehouse" field, enter the name of your Snowflake warehouse

6. Once you have entered the necessary information, click "Connect" to initialize your Snowflake integration and begin monitoring

Enable Cortex Agent Collection for Snowflake Integration

Note: This feature is currently in Alpha. If you would like access to this feature, please contact your Duo Care team, Duo Support or open a Cisco TAC Case to enable it in your account.

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)

2. Agent inspection (DESCRIBE AGENT <agent_name>)

3. Observability event reads (SNOWFLAKE.LOCAL.AI_OBSERVABILITY_EVENTS)

4. Optional unredacted 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

• Snowflake also requires at least one privilege on the parent database and parent schema for those commands

• Access to SNOWFLAKE.LOCAL.AI_OBSERVABILITY_EVENTS requires AI Observability access roles, specifically SNOWFLAKE.AI_OBSERVABILITY_EVENTS_LOOKUP, and Cortex access via SNOWFLAKE.CORTEX_USER

• Access to unredacted 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.

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) Existing agents: grant MONITOR per agent. Repeat for each existing agent.  
GRANT MONITOR ON AGENT <db>.<schema>.<agent_name> TO ROLE <cii_integration_role>; 
 
-- 2) Future agents in each relevant schema. Repeat for each database/schema.  
GRANT MONITOR ON FUTURE AGENTS IN SCHEMA <database_name>.<schema_name> TO ROLE <cii_integration_role>; 

-- 3) Cortex database role 
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE <cii_integration_role>; 

-- 4) AI Observability application role 
GRANT APPLICATION ROLE SNOWFLAKE.AI_OBSERVABILITY_EVENTS_LOOKUP TO ROLE <cii_integration_role>; 

-- 5) Parent database access. Repeat for each database. 
GRANT USAGE ON DATABASE <database_name> TO ROLE <cii_integration_role>; 

-- 6a) Option A: grant all schemas in database. Repeat for each database. 
GRANT USAGE ON ALL SCHEMAS IN DATABASE <database_name> TO ROLE <cii_integration_role>; 

-- 6b) Option B: grant only selected schemas. Repeat for each database/schema you would like Identity Intelligence to have access to. 
GRANT USAGE ON SCHEMA <database_name>.<schema_name> TO ROLE <cii_integration_role>; 

-- 7) 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>;

Verification (optional)

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

USE ROLE <cii_integration_role>; 
SHOW AGENTS IN ACCOUNT; 
DESCRIBE AGENT <db>.<schema>.<agent_name>; 
SELECT * FROM SNOWFLAKE.LOCAL.AI_OBSERVABILITY_EVENTS LIMIT 10;