AI-Driven Innovation Meets a New Security Crossroad
Artificial Intelligence isn’t just reshaping technology—it’s redefining the very fabric of data interaction. As businesses race to integrate AI into analytics workflows, they’re unlocking new dimensions of insight and efficiency. But beneath the surface of this transformation lies an often-overlooked risk: AI can unintentionally bypass the very security frameworks designed to protect sensitive information.
A recent case involving Snowflake’s CORTEX Search Service brings this challenge into sharp focus. CORTEX, an advanced natural language search and retrieval engine, allows users to query vast datasets with intuitive, conversational prompts—no SQL required, no direct table access granted. It’s engineered for simplicity, offering fuzzy logic search powered by large language models (LLMs), with only USAGE rights needed.
However, security researchers at Cyera discovered a troubling contradiction. CORTEX doesn’t respect the user’s access level—it operates under the access level of the role that deployed it. If that role has high privileges (e.g., ACCOUNTADMIN), then so does the CORTEX service—even when queries come from less-privileged users. This “owner’s rights” execution model creates a silent backdoor, enabling potential exposure of data that should be protected by dynamic data masking and other access control mechanisms.
The implication is clear: AI-powered features, when not tightly scoped, can unintentionally override granular security policies. In the case of CORTEX, a well-intentioned deployment by a privileged administrator can inadvertently open up masked or sensitive data to unintended audiences.
This is a wake-up call for security leaders. As AI becomes embedded in enterprise platforms, traditional access control assumptions must evolve. Organizations need to re-evaluate how permission inheritance, role-based execution, and data
Privilege Drift in AI Services: When Access Controls Fail Quietly
In today’s AI-augmented data environments, the line between functionality and risk is thinner than ever. One recent finding from Cyera exposes how that line can be crossed silently—and systemically—within Snowflake’s CORTEX Search.
When AI Reroutes Your Security Logic
Under normal conditions, sensitive fields in enterprise data are protected by dynamic data masking, ensuring that users without the right roles see anonymized values instead of actual content. But CORTEX Search introduces an unexpected behavior: any user with basic USAGE permission can query the service and potentially retrieve data in cleartext—even if they lack direct access.
This occurs because CORTEX Search doesn’t enforce the querying user’s privileges. Instead, it executes under the role that originally deployed the service, effectively using that role’s permissions to answer queries.
This subtle but powerful shift in context means that carefully crafted masking policies can be completely circumvented—not because of a flaw in the policy itself, but because the AI service operates with inherited authority, not delegated authority.
A Deeper Look at the Execution Context Conflict
Most secure systems distinguish between two privilege models:
- Caller’s Rights: Executes with the privileges of the user making the request.
- Owner’s Rights: Executes with the privileges of the entity or role that created the service.
Snowflake’s masking policies, for example, rely on this distinction:
sql
CREATE MASKING POLICY mask_sensitive_data AS (val STRING)
RETURNS STRING ->
CASE
WHEN CURRENT_ROLE() = ‘ADMIN’ THEN val
ELSE ‘*‘
END;
This works as expected in standard SQL queries. But in the case of CORTEX Search, the policy is rendered ineffective—because the AI executes under the admin-level role used at setup, not the querying user’s more restricted role.
In real terms, a user who should only see ***** can end up seeing actual data values, simply by routing the query through the AI interface.
What’s Being Done—and What Still Needs Attention
Snowflake has acknowledged this oversight following responsible disclosure from Cyera and has begun addressing it with updated configuration options and clearer administrator alerts.
But the larger takeaway is this: AI services are not neutral extensions of traditional platforms. They can introduce execution paths that bypass conventional security assumptions, especially around permission inheritance.
Organizations should treat AI components like CORTEX as privileged services by default—and configure them with the same caution they’d apply to admin-level database roles.
Invisible Privilege Escalation: When AI Tools Quietly Break Your Data Protections
Source: Cyera
AI-powered systems like Snowflake’s CORTEX Search promise seamless access to enterprise data—but they may also introduce unexpected cracks in your security posture. One such issue arises not from misconfiguration, but from how the tool is fundamentally architected to operate.
From Convenience to Exposure
Once the CORTEX Search Service is deployed, any user with basic USAGE permissions can use it. But here’s the catch: their queries don’t run under their own access rights. Instead, CORTEX uses the privileges of the role that set it up—often a highly privileged role. The result? Users can extract data they normally wouldn’t be allowed to see, including sensitive fields supposedly protected by data masking.
This isn’t a minor edge case—it’s a quiet sidestep around one of security’s foundational principles: least privilege.
Understanding the Root: Execution Context Confusion
At the heart of this behavior is a distinction often overlooked in database architecture:
- Caller’s Rights: The system enforces the permissions of the user executing the operation.
- Owner’s Rights: The operation runs with the privileges of the entity that created it.
CORTEX Search relies on the latter. If an admin role deployed the service, then every user’s query inherits that admin-level access—no matter how restricted their actual role might be.
Consider a typical Snowflake masking policy like this:
sql
CREATE MASKING POLICY mask_sensitive_data AS (val STRING)
RETURNS STRING ->
CASE
WHEN CURRENT_ROLE() = ‘ADMIN’ THEN val
ELSE ‘*‘
END;
This policy works exactly as intended—until CORTEX enters the picture. Since queries are executed under the service’s setup role (not the user’s), CORTEX ignores the caller’s restrictions and returns unmasked data.
Security Through AI Requires More Than Good Intentions
What appears to be a helpful shortcut actually bypasses established safeguards. Organizations relying on masking to prevent unauthorized data exposure might unknowingly be exposing the very data they’re trying to protect—simply by enabling AI-driven access.
Following Cyera’s responsible disclosure, Snowflake has begun rolling out mitigations, including better configuration controls and more visible warnings for administrators. But the broader lesson is clear: AI interfaces need their own layer of privilege management, distinct from traditional roles and policies.
Treat AI services not as passive utilities, but as active execution engines—ones that can rewrite your access boundaries if left unchecked.
