Snowflake Cortex AI security is now a data governance question as much as an AI one. Cortex puts search, LLM functions, analyst-style text-to-SQL, agents, and a coding CLI inside the same platform that holds your most sensitive tables. That is convenient, and it also means every new AI surface is a new access path to data your existing controls were built to protect.
This guide covers the three risks we see CISOs and platform security teams underestimate: owner's rights execution in Cortex Search, indirect prompt injection in Cortex Code (CVE-2026-6442), and inference routing and residency. It then compares what built-in guardrails do and do not cover, and ends with a hardening checklist you can hand to a platform team.
Key Takeaways
- Cortex Search services read data under the owner's role. A user with only USAGE on the service can retrieve content that masking policies and column grants would block on a direct query.
- CVE-2026-6442 showed that an allowlist of "safe" shell commands is not a sandbox. A poisoned README was enough to push Cortex Code CLI past approval prompts and out of its sandbox. The fix shipped in version 1.0.25.
- Cross-region inference is controlled by one account parameter, CORTEX_ENABLED_CROSS_REGION. Know its value on every account, and do not assume the default matches your residency commitments.
- Guardrails filter model output. They do not replace authorization, sandboxing, or audit trails.
- The highest-value controls are boring ones: least-privilege service roles, scoped USAGE grants, network policy, and attributable logging.
- Test authorization at every access path. Comparing a service's results with direct SELECT as a low-privileged role takes minutes and finds real problems.
What Is Snowflake Cortex AI and What Is Its Attack Surface?
Cortex AI is a family of capabilities running inside the Snowflake account boundary: LLM functions callable from SQL, Cortex Search for hybrid vector and keyword retrieval, Cortex Analyst for natural-language questions over structured data, Cortex Agents that orchestrate those tools, and Cortex Code, a coding assistant with a CLI. Each one is a different trust arrangement.
A useful way to model the surface is to ask, for each component, three questions:
Where the answer to the first question is "the owner" and the answer to the second is "anything a user can write into a table," you have the classic confused deputy setup. Where the third answer includes "run commands," the impact of a successful injection is bounded only by the credentials the agent holds.
None of this is unique to Snowflake. We see the same pattern in managed enterprise assistants such as the one covered in our Amazon Q for Business security guide. What differs is the blast radius: in Snowflake, the credentials involved often have broad read access to the warehouse.
Risk 1: Owner's Rights Execution in Cortex Search
Cyera's research on Cortex Search documented behavior that surprises teams who assume Snowflake's access controls compose automatically. In their demonstration, an administrator created a Cortex Search service over a salary table using the ACCOUNTADMIN role and granted USAGE on the service to an analyst. A direct SELECT by the analyst returned masked values. A query through the search service returned the unmasked data.
The mechanism is owner's rights. The service reads the indexed table under the privileges of the role that created it. Dynamic masking is evaluated against the role doing the read, so the policy is evaluated for the owner, not the caller. Anyone with USAGE on the service effectively inherits the owner's read access to whatever was indexed, without needing SELECT on the base table.
Per Cyera's write-up, Snowflake responded by updating documentation to explain owner's rights behavior and described caller's rights options and administrator warnings as in progress. Check current Snowflake documentation for the state of those changes in your edition and region before relying on them. We could not confirm from public material whether the caller's rights option is generally available.
Why this matters operationally
This is not a vulnerability in the usual sense. It is documented behavior with a security consequence, and it tends to appear in three situations:
- Services built by administrators. Someone demos a RAG prototype as ACCOUNTADMIN, and the service survives into production.
- Broad USAGE grants. A service is granted to a broad role because "it is just search."
- Sensitive columns in general indexes. HR, finance, or customer PII columns are indexed alongside harmless text for convenience.
What to do
- Create each service with a dedicated, least-privileged role that has SELECT only on the columns being indexed.
- Keep masked or row-restricted columns out of general-purpose services. If a column needs masking, it probably should not be in a shared index.
- Treat USAGE on a search service as equivalent to read access on its entire materialized contents, and review grants on that basis.
- Inventory existing services and the role that owns each. Rebuild any owned by a high-privilege role.
- Add the comparison test to your release process: query as a low-privileged role through the service, then directly, and diff the results.
Risk 2: Indirect Prompt Injection in Cortex Analyst and Cortex Code
Cortex Analyst and Cortex Agents read content that users and external systems influence: column values, descriptions, documents, and tool output. Any of it can contain instructions. The general mechanism is described in our indirect prompt injection guide, and OWASP lists prompt injection as LLM01 in its Top 10 for LLM Applications.
For data-facing agents, the practical question is what happens when an injected instruction reaches a tool call. If the agent can run SQL as a role with write access, a poisoned text field in a support ticket table can become a DROP or an exfiltration query. The mitigation is not a better system prompt. It is making sure the role the agent runs as cannot do anything you would be unwilling to let an attacker do.
Cortex Code is the clearest documented example of what happens when the agent can also execute commands.
Sandbox Escape Anatomy: CVE-2026-6442
PromptArmor reported that indirect prompt injection could push the Cortex Code CLI past both its approval prompts and its sandbox. The sequence, as publicly described:
cat. The validation did not account for process substitution syntax, so a command that looked like a harmless cat ran arbitrary content.Tenable's entry lists a CVSS v3.1 base score of 8.3 and notes that exploitation was non-deterministic and model-dependent. Snowflake fixed the flaw in version 1.0.25 on February 28, 2026, applied automatically on relaunch, with public disclosure on March 16, 2026. No confirmed real-world exploitation was reported.
The lesson is architectural
The specific bug was a parsing gap, and parsing gaps get fixed. The durable lesson, which Simon Willison drew in his write-up, is that command allowlists are unreliable as a security boundary. Shell syntax is rich enough that "safe" commands can be composed into unsafe ones. A boundary that the agent can influence, or that depends on the agent not being persuaded, is not a boundary.
What holds up better:
- Enforce isolation outside the agent process. Containers, VMs, or OS-level sandboxes configured by the platform, not toggled by a flag the model can set. See our AI agent sandboxing guide.
- Scope credentials. A coding agent should not hold a session that can read production warehouses. Use a role limited to development data, with short-lived tokens.
- Treat repository content as untrusted input. READMEs, issue text, and dependency docs are attacker-controllable. Our AI coding assistant security guide covers the broader pattern.
- Keep CLI versions current and pinned by policy. This fix auto-applied, but you should verify rather than assume across your developer fleet.
Risk 3: Inference Routing and Data Residency
Snowflake's cross-region inference documentation states that accessing the full range of frontier models and Cortex features may require inference in another region. The behavior is governed by one account parameter, CORTEX_ENABLED_CROSS_REGION. Per the docs:
- Setting it to DISABLED keeps processing in the account's home region. This is the strictest residency posture, and it limits you to models and features deployed there.
- Administrators can instead allow specific clouds or geographies.
- Customer data remains stored only in the account's region. Prompts and responses travel to the processing region for the duration of the call.
- Traffic within the same cloud provider stays on that provider's backbone. Across providers, it uses mutual TLS over the public internet.
Snowflake has also announced a behavior change that would set a same-cloud, same-region default for eligible commercial accounts that have not set the parameter explicitly, with regulated segments excluded. Documentation versions we reviewed differ on exactly how this is applied, so verify against your own account rather than a blog post, including this one. Run SHOW PARAMETERS LIKE 'CORTEX_ENABLED_CROSS_REGION' IN ACCOUNT on every account and record the result.
Cortex Guardrails: What They Cover and What They Miss
Snowflake offers model-level safety filtering for Cortex LLM functions. We did not find public documentation detailed enough to characterize its detection rates, so we will describe the category rather than benchmark it.
Filters of this type classify prompts and completions against harm categories. That is useful for reducing toxic output. It is a different problem from the three risks above:
| Risk | Does an output safety filter address it? | What does | |---|---|---| | Owner's rights data exposure | No. The data returned is legitimate content, accessed by the wrong person. | Least-privilege service roles, scoped USAGE | | Indirect injection leading to a tool call | Partially at best. Injected instructions are often benign-looking text. | Credential scoping, tool allowlists, human approval for writes | | Sandbox escape via command parsing | No. | Isolation outside the agent, patching | | Cross-region inference | No. | CORTEX_ENABLED_CROSS_REGION, residency review | | Missing attribution | No. | Query history, ACCOUNT_USAGE, SIEM export |
The honest summary is that guardrails reduce one category of harm and leave authorization, execution isolation, and residency to you. Layered controls follow the same logic as the one in our prompt injection defense guide: assume the model can be talked into something, and bound the consequences.
CISO Hardening Checklist for Snowflake Cortex AI
Identity and access
- Inventory every Cortex Search service, Analyst semantic model, and Agent. Record the owner role and who holds USAGE.
- Rebuild services owned by ACCOUNTADMIN or other broad roles under dedicated least-privileged roles.
- Segment RBAC so AI workloads use roles separate from analyst and admin roles.
- Exclude masked, row-restricted, and regulated columns from general-purpose indexes.
- Run Cortex Code CLI only in sandboxes enforced outside the agent, with development-scoped credentials.
- Verify CLI version is at or above 1.0.25 across developer machines.
- Require human approval for any agent action that writes, deletes, or executes code.
- Record CORTEX_ENABLED_CROSS_REGION on each account and align it with residency commitments.
- Apply network policies to restrict where Snowflake sessions can originate.
- Review which external integrations and tools each agent can call.
- Confirm AI queries are attributable to a named user or service principal in query history.
- Export logs to your SIEM and alert on new Cortex objects created by high-privilege roles, and on unusual volumes through search services.
- Add the authorization diff test (service result versus direct SELECT as a low-privileged role) to change management.
- Seed test repositories and table fields with injected instructions and observe what the agent does.
- Re-test after Snowflake feature releases, because default behavior can change.
Conclusion
Snowflake Cortex AI security comes down to knowing whose identity each AI component runs as and what untrusted content it reads. Owner's rights in Cortex Search, the CVE-2026-6442 command validation gap, and inference routing are different problems with one root: AI features inherit trust from the platform, and that trust is easy to over-extend. The fixes are mostly disciplined RBAC, isolation the agent cannot override, explicit residency settings, and logging you can use in an investigation.
If you want a quick view of what your AI endpoints expose externally, run a Securetom scan. For a deeper look, the deep scan goes further, and our AI security audit guide for SMBs lays out how to scope an assessment.
Check your AI endpoint against these findings
SecureTom runs a free quick scan on any AI endpoint in about a minute. No signup needed.
