Agent identity

Agent identity lets Snowflake recognize when an AI agent is active in a session, so you can govern agent-driven access separately from ordinary human or service access.

Enterprise AI agents can be Snowflake-native (for example, Cortex Agents) or third-party (for example, agents that connect through OAuth or their own service credentials). In many workflows the session is opened by an agent, but authority and accountability still belong to a person. Agent identity closes that gap so you can answer who authorized the access, which agent carried it out, and whether the access was appropriate for the task.

Overview

Snowflake’s agent identity capabilities support four governance functions:

FunctionWhat you can do
IdentifyDetect agentic sessions and distinguish them from ordinary human sessions
AuditAttribute queries and object access to an agent type, and to the user when the agent acts on a user’s behalf
GovernRestrict what sensitive data an agent can see, even when the user’s role would allow more
ControlLimit what an agent can do in a session, independently of the user’s full privilege set

Two modes of agency matter for how you configure identity:

  • Delegated agents act on behalf of a user. The session belongs to the user; Snowflake marks it agent-active so policies and audit views can treat the traffic as agentic.
  • Autonomous agents act under their own identity and authorization. Create a SERVICE_AGENT user and authenticate with workload identity federation or another supported non-interactive method. Every session for that user is agent-active.

Identify agents

Snowflake marks a session as agentic based on the entry point and authentication method. When a session is agent-active, the IS_AGENT_ACTIVATED context function returns TRUE.

The following table lists the supported entry points:

Entry pointCondition
Snowflake-native agentsA user acts through a Snowflake agent such as a Cortex Agent or a Cortex lite agent, including CoCo clients and Snowflake CoWork
Snowflake-managed MCP serverSessions through a Snowflake-managed MCP server are marked agentic automatically
Snowflake OAuthA custom OAuth security integration is configured with IS_AGENTIC = TRUE
SERVICE_AGENT user typeSessions opened by a user created with type SERVICE_AGENT

Choose an identification path

Use the following table to choose how to identify the agent:

If the agent…Configure…
Runs inside Snowflake AI products (Cortex Agents, CoCo, CoWork, managed MCP)Nothing extra. Snowflake marks the session agent-active automatically.
Needs its own Snowflake identity and privileges (autonomous)A SERVICE_AGENT user, typically with workload identity federation (including SPIFFE and SPIRE), key-pair authentication, or programmatic access tokens
Acts on behalf of end users through a custom Snowflake OAuth client (delegated)IS_AGENTIC = TRUE on the custom OAuth integration. Snowflake doesn’t treat sessions that use other delegated methods, such as programmatic access tokens alone, as agentic unless you also use a supported agent identity path.

Audit agent activity

After Snowflake identifies an agentic session, it carries that context into existing audit views so you can review agent activity.

Query history: agent_type

The agent_type column in QUERY_HISTORY identifies the agent that directly invoked a query:

ValueMeaning
CORTEX_AGENTA persistent, named Cortex Agent
CORTEX_LITE_AGENTA Cortex lite agent (REST API or CoCo client)
EXTERNAL_AGENTAn external agent using SERVICE_AGENT or an OAuth integration with IS_AGENTIC = TRUE

The column is NULL when no agent invoked the query. For details, see QUERY_HISTORY view (Account Usage) and QUERY_HISTORY view (Organization Usage).

Access history: agents_info

The agents_info column in ACCESS_HISTORY provides ordered agent details for object access, from the nearest agent to the top-level agent. For example, when a Cortex Agent invokes tools that run queries, the array can list that agent first, then any higher-level agent in the call chain. Each element can include agentType, agentId, and agentName, depending on the agent. The column is NULL when no agent was involved.

For details, see the ACCESS_HISTORY view (Account Usage).

Together, these columns help you reconstruct the causal chain that compliance teams often need: a user invoked an agent, specific queries followed, and specific objects were accessed.

Govern sensitive data access

Identifying an agentic session lets you enforce data protection policies that behave differently when an agent is active. Call IS_AGENT_ACTIVATED in a policy body so regulated or high-risk data isn’t returned to an agent, even when the user’s role would otherwise allow it.

A common pattern is a masking policy that hides a sensitive column whenever an agent is active:

CREATE OR REPLACE MASKING POLICY email_agent_mask AS (val STRING) RETURNS STRING ->
  CASE
    WHEN SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')::BOOLEAN = TRUE THEN '********'
    WHEN CURRENT_ROLE() IN ('ANALYST') THEN val
    ELSE '********'
  END;

You can use the same check in row access, projection, aggregation, and join policies. For guidance and examples, see:

Control session privileges

By default, an agent that acts on behalf of a user inherits the privileges available in that user’s session. Agent workloads can issue many queries in a short time, so that inheritance is often broader than the task requires.

Restricted Session Scopes (RSS) are privilege ceilings that limit what an agent session can do. The effective permission is always the intersection of what the user’s roles allow and what the RSS permits. An RSS never grants privileges the user doesn’t already have.

You can apply an RSS as an account-wide ceiling, attach it for specific users through a session policy, or inject it during token exchange for partner-orchestrated agents. Restricted Session Scopes for agents are in private preview. Contact your Snowflake account team for access.