Is there one Snowflake Cortex audit log?

Cortex evidence is distributed. CORTEX_AI_FUNCTIONS_USAGE_HISTORY describes function and model usage. CORTEX_AGENT_USAGE_HISTORY records agent calls and request lineage. QUERY_HISTORY supplies execution context and agent type, while ACCESS_HISTORY covers supported object and column access. A useful investigation joins the relevant views and documents each one's latency and coverage.

How current is Cortex Agent usage data?

Snowflake documents latency of up to one hour for CORTEX_AGENT_USAGE_HISTORY. Some SQL cost-attribution fields can lag further. Collection procedures should record the test time and first retrieval. They should also record the final retrieval and field completeness. A quick empty query immediately after execution cannot close the investigation.

Does every Cortex query have an Access History row?

Snowflake warns that not every QUERY_HISTORY record produces an ACCESS_HISTORY record. Coverage depends on the SQL statement. Investigators should preserve the query type and check documented support. They should describe an absent row as a coverage condition instead of treating it as proof that no object access occurred.

What should a Snowflake Cortex evidence package contain?

Include raw view exports, extraction SQL, collection timestamps, account and time-zone context, role and user resolution, view latency, historical cutoffs, explicit join logic, missing-row analysis, and preserved correlation identifiers. Add any independent routed-request policy record as a separate evidence source with its own scope.

Snowflake Cortex Audit Logs: Build the Evidence Chain Across Views

A Cortex AI investigation starts with a join, not a single log file. Function usage can point to a query. Agent usage carries request lineage. Query history identifies the execution context, while access history links supported statements to tables and views, down to the column level. Those records arrive on different schedules and cover different events. I want to build the evidence chain explicitly because the phrase "Snowflake Cortex audit logs" can hide gaps in attribution and object access. It can also hide missing pre-request authorization.

TL;DR

CORTEX_AI_FUNCTIONS_USAGE_HISTORY links model and function usage to queries, roles, users, tags, warehouse context, metrics, and credits, subject to documented history limits.
CORTEX_AGENT_USAGE_HISTORY adds agent request IDs, parent lineage, identity, interaction interface, inference region, token details, and consumption fields.
QUERY_HISTORY and ACCESS_HISTORY connect execution to agent type and supported object access, but every query is not guaranteed an access-history row.
An assessor package needs join logic, source latency, retrieval time, preserved raw exports, and a separate routed-request decision where external policy enforcement applies.

Function usage establishes model activity

Snowflake's `CORTEX_AI_FUNCTIONS_USAGE_HISTORY` reference documents usage records for Cortex AI Functions. The fields include function and model names, QUERY_ID, warehouse ID, role names, query tag, user ID, metrics, and credits. Snowflake divides usage into one-hour windows, so a long-running operation can appear across multiple records.

Start the evidence package with a bounded time range and retain the raw query result. Group related windows without erasing the original rows. Preserve QUERY_ID, function, model, user, role, warehouse, and query tag. Record the retrieval timestamp and the SQL used to extract the data.

Historical attribution needs a visible qualifier. Snowflake says the user and query-tag fields in this view are available only for data acquired after February 16, 2026. The same limit applies to role fields. A blank field before that date is a coverage boundary, rather than proof that no user or role existed.

Agent usage carries request lineage

The `CORTEX_AGENT_USAGE_HISTORY` view records Cortex Agent calls with user and request identifiers. It also records parent-request identifiers. The view includes agent identifiers and names, tags, token and credit details, primary-role metadata, interaction interface, SQL-cost attribution, and inference region.

Those request identifiers should anchor the agent timeline. Retain the parent-child relationship exactly as returned, then attach related SQL activity and application correlation values. Snowflake documents latency of up to one hour for the view, with some SQL cost-attribution fields able to arrive later. Put that latency in the collection notes. An empty result five minutes after a test call is an incomplete observation.

A useful visual is a sheet with application receipt and Snowflake agent usage timestamps highlighted in different colors. Add a third color for SQL execution. The gaps show ingestion delay and clock mismatch. They also tell the investigator how long to wait before declaring the collection complete.

Query history identifies the invoking agent

Snowflake's July 2026 release note for `QUERY_HISTORY.agent_type` distinguishes persistent Cortex Agents and stateless Cortex Lite Agents. It also identifies qualifying external agents. Queries that were not invoked by an agent carry a null value.

Join the function or agent evidence to QUERY_HISTORY with the documented identifiers available for the event. Preserve query text according to the organization's evidence-handling policy, since it can contain sensitive business context. Retain agent_type, user, role, warehouse, query tag, start time, and execution outcome.

I would never hand an assessor a dashboard screenshot as the only Cortex evidence. Dashboards help reviewers locate records. The defensible artifact is the saved extraction, its query text, collection timestamp, source-view latency, and a hash or repository record showing which file entered the review package.

Access history links activity to data

Snowflake's Access History guide links users and queries to accessed tables and views. It also identifies columns and data movement for supported operations. Snowflake explicitly warns that every QUERY_HISTORY entry does not necessarily produce an ACCESS_HISTORY row because coverage depends on the SQL statement.

A later August 2026 release note for `ACCESS_HISTORY.agents_info` adds an ordered JSON chain of agents that accessed data on behalf of a user. The order runs from the nearest agent to the top-level agent and can include the agent type and ID, plus its fully qualified name.

Use that chain to explain delegated data access. Preserve the raw JSON alongside a normalized review copy. If the expected access row is absent, mark it as a documented coverage gap and check the statement type. Silence in this view proves little without that step.

Correlation turns records into evidence

The collection plan should name each join and its fallback.

Function call to SQL: preserve QUERY_ID from the Cortex AI Functions usage view and match it to query history.
Agent request to child work: retain request and parent-request identifiers from Cortex Agent usage.
SQL to objects: join the applicable query record to Access History and inspect base objects and columns. Preserve agents_info with that evidence.
Application to Snowflake: propagate a stable correlation value in a supported tag or application record, then preserve it before execution.
External policy decision: for routed HTTP AI traffic, record the same correlation value with origin identity, relay identity, classification, route, policy version, and outcome.

The AI audit-log schema guide covers the request-level fields that provider usage views rarely carry together. Correlation works only when the application actually writes a common value into both evidence streams. Timestamp proximity is a weaker fallback and should be labeled as such.

The assessor package preserves limitations

Package the raw exports, extraction SQL, view definitions, account and time-zone context, collection times, latency notes, historical cutoffs, and a short join map. Add the identity resolution used for user IDs and roles. Include missing-row analysis for Access History and delayed-field analysis for agent usage.

The AI audit-trail requirements overview explains why evidence needs scope and provenance. For Cortex, that means stating exactly which view supplied each assertion. A model name comes from function usage. Agent lineage comes from agent usage or agents_info. Object access comes from Access History where the statement is covered. Authorization comes from Snowflake privileges or a separate pre-request policy record, depending on the architecture.

Direct Snowsight use and SQL function execution inside Snowflake stay within Snowflake's boundary. Snowflake-managed internal model processing does too. An external HTTP gateway receives none of that evidence automatically. The join becomes possible only for a customer-controlled route that preserves a shared identifier.

DeepInspect

This is the gap DeepInspect closes. DeepInspect is a stateless proxy for routed authenticated HTTP AI traffic between users or agents and LLM endpoints. For a customer-controlled application that sends a model request through it, DeepInspect records application-supplied origin identity, relay identity, prompt classification, selected route, policy version, decision, timestamp, and correlation ID.

Snowflake Account Usage views continue to provide native execution, consumption, agent, query, and object-access evidence. Direct Snowsight activity and internal Cortex AI Function execution remain outside DeepInspect's interception boundary. Snowflake-managed model traffic remains outside it too. A common identifier must be deliberately preserved before the external policy record can join to Snowflake evidence. Book a technical deep dive at deepinspect.ai.