[Report] Data AI Governance Realized with Snowflake: AI Agent Governance, Data Exfiltration Prevention, Ransomware Countermeasures, etc. #SWTTokyo26

This is Kawabata.

"SNOWFLAKE WORLD TOUR 2026 - TOKYO" was held on September 10–11, 2026.

This article is a report blog for the session
[Data & AI Governance with Snowflake: AI Agent Governance, Data Exfiltration Prevention, Ransomware Countermeasures, and More].

Speakers

• Masaya Yanase
  • Snowflake Solution Engineering Division, Principal Security Architect

Governance Challenges in the AI Era and Snowflake Horizon Catalog

• AI is now inseparable from business operations. At the same time, concerns are growing around "how to control what AI agents do" and "how to let them use data safely"
• Since the emergence of ChatGPT, AI has evolved from chatbots to agents
  • They don't just answer questions — they take actions, access external and sensitive data, and make decisions on their own
• According to Snowflake's research, most customers consider governance and compliance to be key challenges

• Snowflake Horizon Catalog is a foundation that provides integrated governance capabilities for data, AI, and security on Snowflake
• It combines data classification, tagging, access control, auditing, and control over AI agents to achieve governance over data usage

• The three pillars of Horizon Catalog
  • Discover: Understand what data exists, classify whether it is personal information, and apply tags
  • Protect: Tags alone are not enough — set policies appropriate to the data
  • Trust: In addition to access auditing of who used data and how, data quality and lineage are also important (Garbage in, garbage out)

Governance for Data

Automatic Classification and Custom Classification

• Automatic classification is GA and is used by many customers
  • Names, email addresses, salaries, and more are automatically classified without manually reviewing each one
• For company-specific sensitive data such as serial numbers and employee IDs, custom classification using regular expressions is available

Tag-Based Masking

• Classification alone is not enough for protection. Attach masking policies to tags and apply those tags to multiple tables

  • This enables bulk masking without writing policies for each individual table

• This has been available for 3–4 years and is used by many customers

• If a tag is applied to a table, columns added later are also automatically protected. Eliminating gaps is a major benefit
  

• Attribute-based access control (ABAC)

Sensitive Data Protection Using AI

• A new feature that uses AI to perform more precise classification. Available in public preview
• The built-in rule-based classification has gaps, such as Japanese addresses that it cannot cover
  • Enabling AI mode allows AI to determine "this is an address"

Demo: From Classification to Masking

• A table containing names, email addresses, salaries, phone numbers, and Japanese addresses is first run through standard classification
• Names, email addresses, salaries, and others are classified and masked for general roles via masking policies attached to the tags in advance
• Japanese addresses alone are not classified and therefore not masked
• When AI mode is enabled in the classification profile and reclassification is run, the address column is also detected and tagged as PII
• ACCOUNTADMIN can see the raw data, and when switching to a general user, addresses are also masked
• Japanese addresses can also be protected through the combination of AI mode and tag-based masking

Here is a reference article from my past verification.

https://dev.classmethod.jp/articles/snowflake-auto-and-custom-classification/

Governance for AI

Differentiating Policies with IS_AGENT_ACTIVATED

• A GA feature. You can write conditional expressions in policies such as "if agent, then... ; if human, then..."
• IS_AGENT_ACTIVATED is a context function that determines whether an AI agent is active in the current execution context
• Masking policies, row access policies, and more can be differentiated depending on whether an agent is active or not
  • Even with the same privileges, you can control whether to mask for agents or not return rows
  • In the official documentation, it is referenced as SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')

Demo: Masking Only When Accessed via an Agent, Even with the Same Privileges

• On the left, a human runs SQL in Snowsight; on the right, the same query is submitted to Snowflake CoCo.
• IS_AGENT_ACTIVATED is FALSE on the left and TRUE on the right. The key point is that the value changes depending on the access path, even with the same privileges
• Before the policy change, raw data is visible to both humans and agents
• The masking policy is changed to "return the string AGENT BLOCKED if TRUE." The policy for INTEGER type is changed similarly
• Upon re-execution, the human sees the raw data, while the agent receives only masked values
• The same condition can be incorporated into other policies such as row access policies

Here is a reference article from my past verification.

https://dev.classmethod.jp/articles/snowflake-is-agent-activated-coco-pii-masking/

Cortex AI Guardrails for Sensitive Data Protection

• The existing Cortex AI Guardrails prevent attacks against AI such as prompt injection and jailbreaking
• The feature under development is "output-side" protection that guards against AI outputs containing sensitive data
  • It has been noted that this has not yet reached private preview

Data Exfiltration Prevention

Overview of Exfiltration Prevention Features

• These features can be used not only for cases where humans exfiltrate data externally, but also for cases where agents attempt to carry data outside
• Snowflake has multiple features for exfiltration prevention
  • Data Movement Policies, the main focus this time (GA in August 2026)
  • External access control to restrict destinations
  • Trust Center scanners to detect where data is going
  • ABAC
• The recommendation is to consider how to combine these features for your use case

Mechanism: Applying Row-Count-Based Rules via Tags

• The setup is almost the same as masking policies — you write conditional expressions. The difference is that control can be based on "data volume (number of rows)"
  • For example, up to 100 rows can be viewed, but 101 or more cannot be viewed or sent externally
• The creation flow is: define a rule → create a policy → attach to a tag → attach the tag to a table

Demo: Five Patterns

Here is a reference article from my past verification.

https://dev.classmethod.jp/articles/snowflake-data-movement-policies-ga/

Ransomware and Unauthorized Operation Countermeasures

Two Approaches

• To prevent destructive operations not only from external attacks but also from insiders and agents, an approval flow is inserted
• Backup: Snapshots can be taken that cannot be deleted or modified even by ACCOUNTADMIN.
• Multi-party Approval (MPA): Without approval from an approver, even ACCOUNTADMIN cannot GRANT to other users
  • Officially released (GA in August 2026 according to official documentation)

Multi-party Approval Flow

• The demo policy has three rules. It protects changes to MPA itself, disabling MFA, and granting privileged roles respectively
  • Approvers and the required number of approvals (1 in the demo; default is 2) are defined in YAML
• The policy is applied to the account with ALTER ACCOUNT SET, and the YAML content and application status can be confirmed
• Executing a protected operation is blocked and a request ID is issued
  • A reason must be submitted with the request, and execution is only possible after the approver grants approval

Demo: Approval and Rejection

• Attempting to GRANT ACCOUNTADMIN to another user is blocked and a request ID is displayed
  • The message reads "Blocked by Multi-party Approval," prompting the user to submit a request
• The request ID is passed to the request function along with a reason. The status can also be checked from the Snowsight menu, and requests can be canceled
• On the approver's Snowsight, pending approvals appear under "Requests and Approvals." After reviewing the content and approving, the same GRANT could be executed
• GRANT and REVOKE are separate operations, so each requires its own request
• In the rejection scenario, an attempt to disable MPA was blocked, a request was submitted, but the approver rejected it as having no valid justification. Re-execution also failed because no approval was given
• Even with the necessary privileges, operations cannot be executed without approval, which also prevents agents from arbitrarily granting roles

Here is a reference article from my past verification.

https://dev.classmethod.jp/articles/snowflake-multi-party-approval-for-critical-operations/

Session Summary

• Discovering and protecting data is of utmost importance. Understanding what information exists in tables and how it should be protected can be achieved while reducing operational burden
• Governance by AI: AI mode in automatic classification enables more precise classification
  • You can also ask Snowflake CoCo "which tables have no masking policy?" — allowing you to strengthen governance without writing SQL
• Governance for AI: Enabling AI to perform tasks is powerful, but "not letting it do too much" is critical
  • Write conditions into policies to prevent agents from viewing data, exfiltrating it, or granting permissions on their own — and proceed with AI adoption safely

New Features Not Covered in the Session

Restricted Session Scope

This is a mechanism that sets a privilege ceiling on what can be used only while an AI agent is operating on behalf of a user. It does not modify RBAC and does not add any privileges.
I believe this is a core feature of AI governance, so please be sure to check it out.

Here is a reference article from my past verification.

https://dev.classmethod.jp/articles/snowflake-restricted-session-scope-coco-permission-limit/

Related Documentation

Here is the official documentation for the features introduced in the session.

https://docs.snowflake.com/en/user-guide/classify-intro

https://docs.snowflake.com/en/user-guide/agent-identity

https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-ai-guardrails

https://docs.snowflake.com/en/user-guide/data-movement-policies

https://docs.snowflake.com/en/user-guide/backups

https://docs.snowflake.com/en/user-guide/multi-party-approval

Thoughts

I attended the session "Data & AI Governance with Snowflake" on Day 2 of SNOWFLAKE WORLD TOUR TOKYO 2026. It was a session covering defense in depth through masking (controlling what is shown), Data Movement Policies (controlling exfiltration), and Multi-party Approval (controlling operations). These were organized under the single narrative of "governance for AI."

Since I had personally been verifying AI-related governance features, there were many points where I found myself nodding along, and I was glad to find that my thinking aligned with Snowflake's.

I hope this article is useful to someone!