Snowflake Cortex Agents

The Snowflake connector brings your account's Cortex Agents into MITRITY. It discovers the agents, imports AI-observability activity as MITRITY audit events and reads account security posture. It authenticates with a key-pair (RSA) JWT that it signs locally. It never writes to your account.

For the connector model, read SaaS-Embedded Agent Governance first. This page covers what is specific to Snowflake.

What it discovers

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

Requirements

Step 1 — Generate a key pair

With key-pair auth, the connector signs a JWT with a private key, and 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 these statements as a privileged role. A service user (key-pair only, no password) is preferred, but 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, either per agent or for a whole schema (current + future agents):

-- 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 and Posture work without the observability grants above. If the grants are missing, or the account has no agents yet, the connector still connects and stays Healthy. It just returns no telemetry (graceful degrade). Without READ UNREDACTED, full prompt and tool content stays redacted, 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, with no token exchange, and calls the Snowflake SQL API. Then it 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 and are marked as observed: recorded, not gated. They flow to the audit log and Insights. They are not forwarded to SIEM destinations.

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.

Getting events to appear. Snowflake logs Cortex Agent traces automatically: there's no event table to create and no tracing flag to set. But the observability table only fills once the agent has actually run in a traced way. In practice, chatting with an agent in the Snowsight playground may not persist queryable events. To generate them reliably, invoke the agent through the Cortex Agent REST API (POST …/api/v2/databases/<db>/schemas/<schema>/agents/<agent>:run), and allow a few minutes of propagation delay before they show up. Confirm directly with:

SELECT * FROM TABLE(SNOWFLAKE.LOCAL.GET_AI_OBSERVABILITY_EVENTS(
  '<db>','<schema>','<agent>','CORTEX AGENT')) ORDER BY TIMESTAMP DESC LIMIT 20;

Zero rows here means that Snowflake has no events yet, which is a Snowflake-side emission or timing matter. It is not a connector or privilege problem: a missing privilege redacts fields, but it never suppresses rows.

Posture

The connector reads account security-configuration proxies, namely 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