Snowflake Cortex Agents

The Snowflake connector discovers your account's Cortex Agents, imports AI-observability activity as MITRITY audit events, and reads account security posture — authenticated with a locally-signed key-pair (RSA) JWT. It never writes to your account.

Read SaaS-Embedded Agent Governance first for the connector model; this page covers Snowflake specifics.

What it discovers

• Cortex Agents defined in the account (SHOW AGENTS IN ACCOUNT), added to your Agents inventory with state discovered.

Requirements

Step 1 — Generate a key pair

Key-pair auth signs a JWT with a private key; Snowflake verifies it with the public key registered on the user. Generate an unencrypted PKCS#8 RSA key pair:

# Private key (PKCS#8, unencrypted) — MITRITY stores this, encrypted. Never register it on Snowflake.
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out mitrity_rsa_key.p8 -nocrypt

# Public key — you register this on the Snowflake user in Step 3.
openssl rsa -in mitrity_rsa_key.p8 -pubout -out mitrity_rsa_key.pub

Step 2 — Create a dedicated user and read-only role

Run as a privileged role. A service user (key-pair only, no password) is preferred; a regular user with a registered key works too.

USE ROLE ACCOUNTADMIN;

CREATE ROLE IF NOT EXISTS MITRITY_GOVERNANCE;

CREATE USER IF NOT EXISTS MITRITY_SVC
  TYPE = SERVICE                    -- key-pair only; omit for a regular user
  DEFAULT_ROLE = MITRITY_GOVERNANCE
  DEFAULT_WAREHOUSE = <YOUR_WAREHOUSE>;

GRANT ROLE MITRITY_GOVERNANCE TO USER MITRITY_SVC;

Step 3 — Register the public key and grant read-only privileges

-- Register the public key (paste the base64 body of mitrity_rsa_key.pub,
-- WITHOUT the -----BEGIN/END PUBLIC KEY----- lines or newlines).
ALTER USER MITRITY_SVC SET RSA_PUBLIC_KEY='MIIBIjANBgkq...';

-- Compute for the connector's read queries.
GRANT USAGE ON WAREHOUSE <YOUR_WAREHOUSE> TO ROLE MITRITY_GOVERNANCE;

-- Observe: read AI-observability events. CORTEX_USER covers Cortex access;
-- READ UNREDACTED gives full prompt/tool content (metadata-only without it).
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE MITRITY_GOVERNANCE;
GRANT READ UNREDACTED AI OBSERVABILITY EVENTS TABLE ON ACCOUNT TO ROLE MITRITY_GOVERNANCE;

Observability is read per agent, so the role also needs MONITOR (or OWNERSHIP) on each Cortex Agent. Run this after your agents exist — per agent, or for a whole schema (current + future):

-- Per agent:
GRANT MONITOR ON AGENT <db>.<schema>.<agent_name> TO ROLE MITRITY_GOVERNANCE;

-- Or cover every agent in a schema, including ones created later:
GRANT MONITOR ON ALL AGENTS IN SCHEMA <db>.<schema> TO ROLE MITRITY_GOVERNANCE;
GRANT MONITOR ON FUTURE AGENTS IN SCHEMA <db>.<schema> TO ROLE MITRITY_GOVERNANCE;

Discover + Posture work without the observability grants above — if they're missing (or the account has no agents yet), the connector still connects and stays Healthy, it just returns no telemetry (graceful degrade). Full prompt/tool content stays redacted without READ UNREDACTED, and events for an agent the role can't MONITOR are skipped.

Then read the fingerprint MITRITY needs:

DESC USER MITRITY_SVC;
-- Copy the RSA_PUBLIC_KEY_FP value, e.g. SHA256:abcd1234…

Step 4 — Connect in MITRITY

In Settings → Platforms → Connect a platform, choose Snowflake and provide:

Save, then click Sync now. The connector signs an RS256 JWT locally with your private key (no token exchange), calls the Snowflake SQL API, and runs Discover → Observe → Posture.

Observe — AI Observability events

The connector reads each agent's activity from Snowflake's AI Observability events (SNOWFLAKE.LOCAL.GET_AI_OBSERVABILITY_EVENTS, queried per agent). Imported events carry source = snowflake, are marked observed (recorded, not gated), and flow to the audit log, Insights, and any configured SIEM destination. Reading an agent's events needs MONITOR (or OWNERSHIP) on that agent plus CORTEX_USER; without the READ UNREDACTED AI OBSERVABILITY EVENTS TABLE privilege, events are imported metadata-only (prompts and tool payloads stay redacted). If the feature or a grant is absent, that agent's telemetry is simply empty and the connection stays healthy.

Posture

The connector reads account security-configuration proxies — over-broad ACCOUNTADMIN / SECURITYADMIN grants and agent presence — and records them as findings (OK / Warning / Unknown). A control it cannot read is recorded as Unknown, never OK. See Posture & Security.

Governing a discovered agent

Assign a policy to a discovered agent to move it to governed (governance mode Constrained), or suppress it. Cortex Agents are observed, not enforced in-band, in this release — see read-only by design.

Related documentation

• SaaS-Embedded Agent Governance
• Posture & Security
• Writing Policies
• SIEM Integration