Unexpected behavior in Snowflake’s Cortex AI

1. Introduction

AI everywhere, but at what cost?

AI is infiltrating every corner of technology, from chatbots in business analytics tools to generative models powering data discovery. These innovations offer incredible efficiencies and thriving business growth, yet they also bring uncharted security pitfalls. One particularly concerning risk is unexpected data exposure. Whether it is M365 Co-Pilot, Snowflake Cortex AI or any other AI service, your security is only as good as the access policies you configured.

In this post, we’ll examine how Snowflake’s CORTEX Search Service, a cutting-edge AI-driven search and retrieval tool, could end up exposing sensitive data within your Snowflake user base, even in a secure environment with tightly configured access and masking policies.

At the end of the post we explain how Cyera can help protect against this issue. If you need further help, please reach out to us at support@cyera.com. 

We want to thank the entire Snowflake team for their transparency, responsiveness, and collaboration throughout the process, we truly appreciate their support.

2. Use Case: Misusing CORTEX Search to Show Sensitive Data

2.1 Dynamic masking in Snowflake

Dynamic data masking is Snowflake’s method of restricting how data is presented, based on who’s querying it. Typically, you set a masking policy on sensitive columns, like this:

• ADMIN role sees real data (val).
• Everyone else sees masked data (*****).

This is crucial for adhering to compliance requirements—e.g., protecting PII or financial information at query time without duplicating data.

2.2 The CORTEX Search Service

Snowflake’s CORTEX Search is designed to support fuzzy search and LLM-driven RAG (Retrieval Augmented Generation) use cases.

In practice:

• CORTEX runs under a role with the CREATE CORTEX SEARCH SERVICE privilege.
• Users do not need direct SELECT privileges on the underlying tables.
• A user can query data through CORTEX SEARCH as long as they have USAGE on the service.

2.3 CALLERS' RIGHTS vs OWNERS' RIGHTS

One of the most important concepts in database security is the difference between callers’ rights and owners’ rights.

Callers’ rights: The process or function executes with the same privileges as the user who invokes it. If you have limited privileges, the function’s capabilities are similarly limited.

Real-World Example: Think of an ordinary user in a collaboration tool who can’t see a private folder. Any script they run from their account still lacks access to that private folder—it’s bound by **their** rights.

Owners’ rights: The process or function executes with the privileges of the object’s owner, regardless of who calls it. If the owner has elevated or admin privileges, the function can do things that the caller themselves normally can’t.

Real-World Example: In some systems, like certain SaaS platforms or advanced stored procedures, a feature executes with the permissions of a privileged role (such as an administrator role). Even if a regular user initiates the action, the code runs with the service role’s elevated access and can read or write data the user normally wouldn’t be allowed to access.

In many database systems, features run under callers’ rights to preserve the principle of least privilege. However, in Snowflake’s CORTEX Search scenario, as with other features within Snowflake, the code runs under the service’s owners’ rights—often a powerful role such as CORTEX_ROLE or even ACCOUNTADMIN. That means anyone who can call the service inherits the owner’s potentially higher-level privileges during that execution. When used appropriately, owners’ rights semantics can be used to facilitate adherence to the principle of least privilege, such as the case of stored procedures, where the owner can delegate specific administrative tasks, such as cleaning up old data, to another role (the caller) without granting that role more general privileges, such as privileges to delete all data from a specific table. For Cortex search, this could help provide access to select columns of a table without granting access to the entire table.

Why This Matters:

• If CORTEX Search (or any stateful service) is given broad data access (owners’ rights), then any user who can invoke it gains similar read access as the owner who created the index. Even if they lack direct SELECT privilege on a table, they can retrieve unmasked data because the query runs as the owner.
• By contrast, if a service used callers’ rights, it would only return data the actual user has permission to see, keeping dynamic masking and access controls intact.

So because CORTEX Search uses owners’ rights, it effectively “borrows” all privileges of the role under which it’s running, potentially allowing a lower-privileged user read access over indexed data. Use of this feature by an admin who isn’t familiar with these details may result in unintended information disclosure within the company’s Snowflake account.

3. Technical Breakdown

Step 1: Creating the CORTEX search service with AccountAdmin

You, as the accountadmin, set up the CORTEX Search Service to allow analyst_user to query the salary_info table. The service is initialized with the accountadmin role, which has full access to all data in the environment.

Visual 1: Video of Creating CORTEX Service with AccountAdmin

Step 2: Granting permissions to analyst_user

Next, you grant analyst_user the necessary permissions to use the CORTEX Search Service.

Visual 2: Photo of Grants Granted to analyst_user

At this point, everything seems fine. However, the accountadmin may be under the incorrect impression that analyst_user can use the CORTEX Search Service to interact with the table using their own (analyst_user) permissions.

Step 3: Exploiting the configuration

Now, analyst_user tries to query the salary_info table directly,

Unsurprisingly, this data returns masked.

But then, analyst_user tries something else—they use the CORTEX Search Service to query the same table:

‍FULL DEMO

Full demo showing the entire progress from creating the cortex search service to using it and bypassing the masking policy

4. Solution: Stop AI from overreaching

However, Snowflake account administrators can avoid this class of behavior.

For Snowflake Users (You):

✅ Don’t deploy CORTEX Search with highly privileged roles like ACCOUNTADMIN unless you intend to bestow your rights upon users of CORTEX search. Use a least-privileged service role with only the minimal SELECT access needed.

✅ Isolate sensitive tables from general-purpose search services. If a table has masking policies or compliance-relevant data, don’t index the columns with that sensitive data  in a Cortex Search service.

✅ Be careful with USAGE grants on the Cortex Search Service - if you are the owner, any role you grant USAGE on the service to can access all of its materialized contents

✅ Audit role usage: Periodically verify what role was used to create each CORTEX Search Service. If the creator had full access to sensitive tables, consider revoking or rebuilding the service.

Bottom Line: AI services like CORTEX Search, if misconfigured, can result in unintended information disclosure. Without careful scoping, they could allow low-privileged users to quietly punch through masking walls and retrieve sensitive data, with no SELECT permission required.

Principle of least privilege must apply to AI, since AI doesn’t just see your data, it talks.

5. Conclusion: AI services aren’t above access controls

CORTEX Search is a powerful AI-driven tool that brings natural language search to unstructured enterprise data. Yet, this power must be used responsibly. As demonstrated, CORTEX Search runs with owners’ rights, not callers’, meaning it executes queries using the permissions of the privileged role that created the service, not the user who’s calling it.

In this case, the expected outcomes and capabilities of Snowflake’s dynamic masking mechanism may not be realized. A masked column is only masked when access control is enforced. If misconfigured, CORTEX can allow a user to go around SELECT and still see plaintext values.

In effect, AI can become an unintentional channel for exposing data within an organization. That’s why Cyera matters: It helps you automatically discover, classify, and protect sensitive data stored within your environment. Instead of guessing or spending hours manually sifting through, you'll know exactly what's there, how sensitive it is, and if it’s at risk.

Responsible Disclosure and Vendor Response

This issue was responsibly disclosed to the Snowflake team, who responded promptly and professionally. In collaboration with their security and product teams, initial mitigations have already been implemented in the form of updates to the CORTEX Search Service documentation to clarify the implications of owner-executed rights. Further improvements are in the pipeline, including offering caller’s rights execution context for specific Snowflake use cases and enhanced UI warnings for administrators to prevent unintended misconfiguration. We appreciate Snowflake’s engagement and commitment to strengthening the platform’s security posture.

Cyera is ready to help you protect your data with DSPM and DLP. Get started today with a demo.