Introduction
AI agents are rapidly becoming a core component of business operations, including modern analytics and data platforms. Rather than simply assisting users, they can autonomously interpret natural language requests, generate code, retrieve data, and perform multi-step reasoning to answer increasingly complex business questions. As organizations adopt these capabilities, they must also reconsider how sensitive data is governed when accessed by an AI agent rather than a human.
Unlike a human user, an AI agent may execute multiple queries, process large volumes of data, and incorporate query results into downstream AI workflows to complete a task. While this enables powerful new capabilities, it also increases the importance of ensuring that agents only access the data that is required. Exposing sensitive information, such as personally identifiable information (PII), financial records, or healthcare data to AI workflows when it is not needed creates unnecessary security, privacy, and compliance risks.
Traditionally, data access controls have been built around the identity of the user executing a query. If a user has permission to view a dataset, any query they execute is evaluated against that same set of permissions. While a human user can apply judgment when deciding what information is relevant or appropriate to use, an AI agent operates solely within the permissions it has been granted. If sensitive data is accessible, the agent may retrieve and process it as part of its reasoning, even when that information is not necessary to answer the user's request. This shows an important limitation of identity-based access control: it assumes every workload initiated by a user has the same data requirements. In reality, an AI agent acting on a user's behalf often requires significantly less access than the user themselves to complete a task.
Being able to distinguish between human and agent-initiated queries enables organizations to reduce unnecessary exposure of sensitive information, while still allowing AI agents to deliver valuable insights. Snowflake's new SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED') function introduces exactly this capability, allowing governance policies to dynamically adapt based on whether a query is executed directly by a user or by an AI agent acting on their behalf.
What is IS_AGENT_ACTIVATED?
IS_AGENT_ACTIVATED is a context value available through Snowflake's SYS_CONTEXT function that enables organizations to determine whether a query is being executed by a user directly or via an AI agent. Rather than identifying who is running the query, it identifies how the query is being executed, allowing Snowflake's governance policies to distinguish between human- and agent-initiated workloads.
The value is retrieved using the SYS_CONTEXT function:
SELECT SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED');
This is a Boolean function that returns one of two values:
- TRUE: The current query is being executed by an AI agent.
- FALSE: The current query is NOT being executed by an AI agent, which means it is being executed directly by a user.
While the functionality itself is straightforward, it introduces an important new capability for data governance. Traditionally, policies have relied on attributes such as the current user, role, or session to determine what data should be accessible. IS_AGENT_ACTIVATED adds another dimension by exposing the execution context, enabling policies to adapt their behavior based on whether a human or an AI agent is issuing the query.
This distinction allows organizations to implement more context-aware security controls. For example, a human analyst may require access to detailed customer information to investigate a support case, while an AI agent answering a high-level business question may only require anonymized or aggregated data. By understanding whether an agent is executing the query, Snowflake policies can dynamically tailor the data returned without changing the user's underlying permissions.
Why This Matters
A fundamental principle of information security is the Principle of Least Privilege (PoLP), which states that users, applications, and systems should only be granted the minimum level of access required to perform their intended task. Applying this principle reduces the surface area of potential attacks, limits the impact of accidental data exposure, and helps organizations meet security and compliance requirements.
As AI agents become more deeply integrated into analytical workflows, this principle becomes increasingly important. Many AI-driven tasks, such as summarizing reports, identifying trends, or answering business questions, do not require access to personally identifiable information (PII), protected health information (PHI), financial account details, or other sensitive records. Yet, without agent-aware governance, AI agents may still retrieve this information simply because it is available to the user on whose behalf they are operating. AI Agents also have a tendency to provide additional detail in responses that may not be suitable. For example, prompting an AI agent with “how many tickets were answered outside of the 2-hour SLA” could return a detailed response that also gives the top 5 tickets with the longest response time and who submitted them.
For organizations operating in regulated industries, this is also a compliance concern. Regulations such as GDPR require organizations to follow principles including data minimization and purpose limitation, while HIPAA requires covered entities to limit the use and disclosure of protected health information to the minimum necessary to accomplish the intended purpose. Applying the Principle of Least Privilege to AI workloads helps organizations satisfy these requirements by ensuring that AI agents only process the information necessary to complete their task.
IS_AGENT_ACTIVATED provides the context needed to enforce this principle. By distinguishing between human- and agent-initiated queries, organizations can apply different governance policies without changing a user's underlying permissions, ensuring AI agents receive only the data required for their workload while preserving the user's access where appropriate.
Using Agent Identity Across Snowflake Policies
IS_AGENT_ACTIVATED integrates naturally with Snowflake's existing governance framework because it can be evaluated alongside conditions such as the current role, account, session attributes, or network location. Rather than replacing role-based access control (RBAC), it extends it by allowing policies to consider the execution context of a query. This enables organizations to apply different governance rules for AI agents without creating separate users, duplicating roles, or maintaining additional copies of the data.
One of the advantages of IS_AGENT_ACTIVATED is that it can be leveraged anywhere policy logic is evaluated, making it applicable across Snowflake's broader data protection framework.
- Masking Policies: Masking policies control how individual column values are presented to users at query time, allowing sensitive data to be revealed, transformed or hidden based on policy logic. By incorporating IS_AGENT_ACTIVATED, organizations can return different representations of the same data depending on whether the query is being executed by a human or an AI agent. Like in our previous example, an analyst with an approved role may be able to view customer names or patient identifiers, whereas an AI agent operating on their behalf would receive hashed or fully masked values instead. This reduces unnecessary exposure of sensitive information without affecting access to the underlying dataset.
- Row Access Policies: Row access policies determine which records are returned by a query, allowing access to be filtered dynamically based on contextual information. By evaluating IS_AGENT_ACTIVATED, a row access policy can return only records that have been designated as safe for AI processing when an agent executes the query, while allowing authorized human users to continue accessing the complete dataset. This provides a simple way to separate AI-ready data from records that require human oversight.
- Aggregation Policies: Aggregation policies enforce minimum aggregation requirements, helping prevent sensitive information from being exposed through queries that return small groups or individual records. By evaluating IS_AGENT_ACTIVATED, an aggregation policy can require AI agents to query data at a minimum group size while allowing human users to continue performing more detailed analysis where appropriate. This enables AI assistants to answer questions about trends, averages and patterns without exposing individual customer or patient records. This can also be combined with a modified row access policy, allowing an AI agent to see more records than a human, but also forcing it to aggregate the results.
- Projection Policies: Projection policies control which columns are allowed to appear in the final query results, regardless of whether they were referenced elsewhere in the query. By incorporating IS_AGENT_ACTIVATED into the policy logic, organizations can prevent AI agents from projecting sensitive columns such as names, email addresses or account numbers while still allowing those columns to be returned to authorized human users when required.
- Join Policies: Join policies govern how tables can be combined, helping control when and how sensitive datasets are joined together. By evaluating IS_AGENT_ACTIVATED, organizations can require AI agents to use only approved join paths or approved lookup tables when combining data. This helps reduce the risk of exposing sensitive information through complex joins while still allowing human users to perform broader investigative analysis where permitted.
Demo: Comparing Human and Agent Access
To demonstrate how IS_AGENT_ACTIVATED can be incorporated into Snowflake’s governance policies, we’ll use a simple patient events dataset containing identifiers, regional information, medical specialties, and billing amounts.
For this example, we’ve applied several agent-aware policies to the table, including masking, aggregation, row access and projection policies. Each policy evaluates SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED') to determine whether the query is being executed directly by a user or by an AI agent.
Create a Sample Dataset
We'll begin by creating a small table containing fictional patient event data. While the dataset is intentionally simple, it represents the type of sensitive information commonly found in healthcare, finance or customer support environments. Note that to prepare for row access policies, we’ve included an AGENT_SAFE column to indicate whether or not an agent should have access to that row.
Before running any queries, we'll apply several of Snowflake's data protection policies to the table. The demo includes a masking policy to protect sensitive identifiers, a row access policy to restrict which records an agent can access, an aggregation policy to encourage cohort-level analysis, and a projection policy to prevent sensitive columns from appearing in agent responses. Each policy incorporates `SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')`, allowing the same table to return different results depending on whether the query is executed directly by a user or by an AI agent.
Human Query
An analyst connected directly to Snowflake can query the table as they normally would. Because this query is executed by a human (IS_AGENT_ACTIVATED = FALSE), the existing role-based permissions remain in effect and the user receives the expected level of detail.
In this example, the analyst retrieves patient counts and billing information grouped by region and condition group. Depending on the policies applied, an authorized user could also view the underlying identifiers required to investigate individual records.
Agent Query
Next, we’ll ask a Cortex Agent the equivalent business question using natural language. Although the request originates from the same user, the query is now executed within an agent context, causing IS_AGENT_ACTIVATED to evaluate to TRUE.
Because the execution context has changed, Snowflake evaluates the same governance policies differently. Rather than exposing unnecessary record-level information, the agent returns an aggregated summary suitable for answering the business question. Sensitive identifiers remain protected, while still providing enough information for the agent to generate a useful response.
One of the advantages of Cortex Analyst is that it also surfaces the SQL generated to answer the request. This provides transparency into how the response was produced and allows developers or analysts to validate, refine or reuse the generated query if needed.
Real-World Use Cases
Takeaway
IS_AGENT_ACTIVATED is most effective when used to enforce the principle of least privilege rather than to restrict AI unnecessarily. Organizations should first identify AI workloads that do not require access to sensitive information, then apply agent-aware policies to return masked, aggregated, or filtered data where appropriate. This allows AI agents to perform their intended tasks while minimizing unnecessary exposure of regulated or confidential information.
Rather than replacing existing role-based access control (RBAC), IS_AGENT_ACTIVATED should complement it. Continue using roles to determine who can access data, then use agent context within Snowflake's data protection policies to refine what data is returned based on how the query is being executed. By combining RBAC with context-aware governance, organizations can safely adopt AI while maintaining strong security, privacy, and compliance controls.
Gist of Demo Code: https://gist.github.com/apd-aalexander/55c42816dc660fb602f36c75182dcd60
.png)