Snowflake Cortex Search and Agent Data Access Security Assessment (2026)

Snowflake documents a consequential access boundary for Cortex Search: a role allowed to query a search service can retrieve data indexed by that service even when the role cannot read the underlying source table or view. A Cortex Agent adds another boundary because its call is authorized by the caller's Snowflake context and its tools require their own privileges. An enterprise rollout needs evidence for both paths, especially when one search index or agent serves multiple teams or tenants.

Quick answer. A Snowflake Cortex Search and Agent data access security assessment should prove what the service owner indexed, who can query that index directly, which role an Agent request actually uses, and which tools that role can reach. Stingrai can scope a human-led cloud, web and API assessment around the customer-controlled Snowflake account and connected application, using synthetic documents and restricted test roles. A passing result is a role-by-role and tenant-by-tenant record of allowed and denied retrieval, tool use and trace access.

The buyer should not buy a generic “AI prompt test” and assume it covers this problem. A fluent answer can be grounded in a document that the end user was never meant to see, or a legitimate agent can run under a role broader than the person using the front end. Conversely, a user-facing denial may reflect a missing tool grant rather than a tested tenant boundary. The assessment must observe the effective role, indexed corpus and returned result. These are application and configuration decisions within the customer's control.

This guide is for security, data platform and procurement teams preparing a Cortex Search service, a Cortex Agent that uses Search or Analyst, or an application that calls the Agent API. It also applies when a team changes the source query, grants USAGE on a service, adds a new tool, enables a shared agent for another business unit, or turns an internal assistant into a customer-facing feature. The test design is proposed buyer acceptance criteria. It is not a claim that Snowflake requires a particular penetration test or that a given Snowflake deployment has a flaw.

Scope the retrieval path, not a product label

A Search service, an Agent and a web application can all be present in one product, but they do not make one authorization decision. The service owner decides what enters the Search index through the source query. Snowflake grants decide who may query the service. A web application may have its own identity and tenant mapping. An Agent request has a Snowflake caller role, configured tools and sometimes tenant-specific session attributes. The final answer can reflect results from Search, Analyst, custom tools or other enabled tools. A buyer needs to know which path produced the answer under test.

Snowflake says a Cortex Search service exposes Python, REST and SQL query methods, with columns and filter request parameters. It also says the query role needs USAGE on the service, database and schema, and that Search runs with owner's rights. These facts make a direct Search query an essential test, even if the planned production user interface only exposes an Agent conversation. If the same role can call the Search service through another approved route, the interface's selected filter is not the complete boundary.

Snowflake's Agent access control guide describes a different chain. The request's Snowflake context identifies the caller, the active role determines authorization, and a role with USAGE on the Agent still needs privileges on each tool it is expected to use. In an application using the REST API, the request role can come from X-Snowflake-Role or the user's default role if the header is omitted. Secondary active roles also matter. The assessment must compare the role that the application intended with the role Snowflake actually used for each test call.

Keep the boundary to customer-controlled configuration, application code and authorized test objects. Do not treat Snowflake's managed service infrastructure as the penetration-test target. The Snowflake data sharing assessment covers provider and consumer shares, grants and secure views; that is a different decision from whether an indexed document becomes retrievable through Cortex Search or an Agent tool.

Define the data contract before the tester asks a question

A meaningful test starts with an approved data contract. For each search service, identify its owner role, source query, source tables or views, indexed text, attributes, returned columns, refresh behavior, query grants and intended audience. For each Agent, identify its owner, caller roles, configured tools, tool resources, warehouse grants, custom procedures, semantic views, thread and trace settings, and consuming applications. For each front end, identify the authenticated user, organization or tenant and the Snowflake identity and role used on its behalf.

The data owner should mark documents that may be retrieved by every intended audience and documents that must remain separated. A small synthetic corpus is enough: one common document, one document for test tenant A, one for test tenant B and one restricted document that the service owner can see but the querying role should not see under the buyer's policy. Give each record a neutral marker that can be recognized in a result without copying real customer, employee or regulated data into a prompt or report. If document metadata itself is sensitive, use synthetic attributes too.

Then state the expected result per identity and route. The same user may have a different intended outcome when querying a raw Search service, invoking an Agent through the web app, invoking the Agent API with its own role, or viewing a saved conversation. A test cannot conclude that access is “correct” without this table of expected decisions. It can only list observed output. The SOW should require the buyer and assessor to agree on the expectation before execution.

Inventory the effective routes

• Search service source query and its owner role.

• Direct Search query methods the test role can invoke, including any REST, Python or SQL path available in the environment.

• Application backend that selects a Search service, sets a filter or chooses returned columns.

• Agent API or user interface that chooses the effective Snowflake caller and active roles.

• Agent tool resources, including Search services, semantic views, stored procedures and optional external tools.

• Tenant context variables and row access policies used for generated SQL, if the deployment uses that pattern.

• Conversation threads, traces, monitoring roles and any application-side transcript storage.

Mark each route as in scope, out of scope or unavailable, with an owner. This prevents a proposal from saying “Cortex tested” after only prompting the Agent in a playground. The broad claim requires observing the index and role paths as well.

The buyer's acceptance matrix

The following rows describe the evidence a security buyer can request. They are an original test-planning matrix based on Snowflake's documented product boundaries. Replace the sample roles and documents with owned nonproduction objects and the organization's real access policy. For each applicable row, ask the assessor to retain an allowed result, a denied result or an explicit reason the negative case was unavailable.

Figure 1: Buyer evidence boundaries for Cortex Search and Agent data access. Source: Snowflake, Query a Cortex Search Service, Snowflake, Agent access control, and Snowflake, Multi-tenancy for Cortex Agents. The acceptance outcomes are proposed assessment criteria.

The matrix separates capability from policy. Snowflake may permit a Search caller to see all indexed material under owner rights, while the organization's policy says the caller should see only one tenant's material. The finding belongs to the customer's service design, grant or application boundary, not to a claim that Snowflake's own permission system failed. This distinction makes the report useful for remediation.

Test what the Search owner indexed

The Search service's owner rights create the most consequential precondition. Snowflake says any role with sufficient privileges to query a service may retrieve data that service has indexed regardless of the role's rights on the underlying source table or view. Its documentation gives the example of source rows protected by a row-level policy: a querying role can see results from rows the service owner can read even when the querying role cannot read those rows in the source table. The buyer should therefore inspect the source query and owner role together, rather than infer Search access from a base-table grant screenshot. Snowflake, Query a Cortex Search Service

Ask the assessor to trace how the synthetic restricted document enters, or is excluded from, the service's indexed corpus. The evidence should include the source query, effective owner role, relevant source policy and a controlled Search query result. If a restricted document is indexed, do not assume a later query filter makes it safe for every role that has service USAGE. Snowflake's filter parameter filters indexed ATTRIBUTES columns; its documentation does not describe the caller's source-table row policy as a query-time limit for Search. A filter generated or passed by a client should be evaluated as part of the customer's application design, not treated as a universal security boundary by default.

There are several ways an organization might design a smaller audience: narrow the source query before indexing, use separate services for audiences that should not share a full corpus, withhold direct service USAGE from roles that should not see that corpus, or require a customer-controlled gateway to enforce a validated tenant selection. The appropriate design depends on the application's access model. The test should verify the implemented choice with both direct and application-mediated queries. It should not pronounce a filter safe merely because the UI sends the expected value in a normal session.

If the service indexes documents from several business units, the report should describe the exact audience that has query privilege and the full set of indexed records that audience can retrieve. Where no direct end-user USAGE exists and a backend service queries on users' behalf, the backend's authorization and filter construction become critical. The assessor should verify that the backend derives the audience or tenant from authenticated, server-side state and that the response cannot include another partition's marker. That is a test of the customer's application. It does not change Snowflake's documented owner-rights behavior for the service itself.

Returned columns matter as well as the matching text. Snowflake's query documentation says a caller can specify columns from the service's source query, and a Search service can filter on declared ATTRIBUTES columns. The assessor should compare the source query's columns with the approved data contract and inspect the fields returned by direct and Agent-mediated queries. A fragment of a document, an identifier or a metadata field may be enough to violate the expected boundary even if the final Agent answer appears harmless. Use synthetic markers so the report can show the issue without exposing live content.

Verify grants on the Search service itself

Snowflake's access requirements identify USAGE on the Search service, containing database and containing schema as the query privileges. A source-table SELECT grant is not listed as a requirement for the querying role. The SOW should therefore ask for a grant-path review at the service level: which roles inherit or receive USAGE, which users can activate those roles, and which applications or service identities use them. A seemingly restricted source table does not answer that question.

Test a role that should be allowed to query and one that should not. The allowed role should return the approved synthetic common material. The restricted role should fail to query or see no protected material according to the actual design. Record the active primary and secondary roles, not only the login name. If a restricted role can query because it inherits a service grant, the report should identify that inheritance. If the restricted role receives a denial, record whether it lacked service, database or schema USAGE; that difference tells the owner which grant delivered the control.

The report should also state whether all users with service USAGE are permitted by business policy to see the whole indexed corpus. If yes, a shared service can be appropriate even when source rows have narrower role grants, because Search's access model is explicit. If no, the answer is a design or grant change, backed by a retest. The security test is about alignment between the documented service behavior and the buyer's intended audience.

Test the Agent caller and every configured tool

Snowflake's Agent access control guide says an Agent's permissions are determined by the Snowflake context of the request. For REST calls, the authorization role comes from X-Snowflake-Role or the user's default role when the header is omitted, and active secondary roles also govern checks. The buyer should insist that the assessment observe the effective role for each application user, not infer it from a front-end badge. A shared backend identity with a broad role deserves particular scrutiny because it can collapse many end users into one Snowflake principal unless the application preserves and enforces its own audience decision.

Next, inventory the tools. Snowflake describes Agent support for Cortex Search, Cortex Analyst, custom tools, code execution and other optional capabilities. The access guide says USAGE on an Agent is not enough by itself; the caller's active role also needs rights on each tool it is expected to use. For Search, that includes USAGE on the configured service and its containing database and schema. For a semantic view and custom tool, other grants apply. A stored procedure used as a custom tool may run with owner or caller rights as defined on that procedure. Snowflake, Agent access control

The test should compare an authorized role, a role with Agent USAGE but without a particular tool grant, and a role that should not call the Agent at all. For each, capture which tool the Agent attempted, whether it ran, whether it returned a document or SQL result, and what the answer conveyed. An apparently successful conversational response is insufficient evidence of tool authorization. The Agent might answer from another accessible tool, or from general model knowledge, when the intended restricted tool was unavailable.

Snowflake's inaccessible-tool guide says the default accept mode lets an Agent continue with tools the caller can access and report missing tools as warnings. The buyer should decide whether that behavior is acceptable for its use case. A customer-support assistant may need to say that it cannot access a tool; a regulated decision workflow may require the run to fail if a required source is inaccessible. The assessment should record the configured mode and test the expected business behavior. Do not label Snowflake's documented default as a vulnerability by itself; identify when the customer's answer or workflow misrepresents incomplete evidence as complete.

Where the Agent includes a custom tool, the SOW should require a separate authorization case for that tool. A tool that reads a table or invokes a procedure can have a different execution context from Search. The test should show the caller role, tool grant and result, then compare the effect with the data contract. This is particularly important when the tool changes a record or calls a downstream application. The assessment should use a disposable object and avoid irreversible actions. If an external connector or web search is configured, add its specific trust boundary and owner; do not claim that a Search-only test covers it.

Treat Agent tenant SQL context and Search retrieval separately

Snowflake's multi-tenancy guide describes immutable session attributes supplied in the agent:run variables block and paired with row access policies for generated SQL. Snowflake sets the attributes before generated SQL executes, and the row access policy filters rows using the current tenant value. The tenant value comes from the caller of agent:run, so the customer's application must bind it to the authenticated tenant and test that binding. A user-supplied tenant string is not an authority source merely because it is marked immutable once the run starts.

The SOW should test that SQL path with separate synthetic tenant rows and two authorized tenant identities. The assessor should capture the active role, supplied immutable attribute, policy expected result and actual SQL-backed answer. A result that includes the other tenant's marker is a direct boundary failure. A denial can also be misleading if the test role lacked permission to run the tool; the report should confirm that the positive tenant case succeeds under the same configuration.

Do not copy that conclusion to Cortex Search without another test. The multi-tenancy document explains row access policies for generated SQL, while the Search document describes owner-rights retrieval over an indexed corpus. A shared Agent can use both tools, and the Agent may adjust Search filters and returned columns based on a user's request. Snowflake, Cortex Agents Therefore, even if generated SQL respects a tenant row policy, the assessor should separately verify the Search service's indexed data, grants and query behavior for the same caller. The final answer can combine results from both routes, so the evidence package should preserve tool provenance.

If the application relies on a tenant filter for Search, the assessor should identify where that filter is formed, whether the end user can change it, whether every Search call uses it, and whether another query path is available to the same role. That is the customer's design to validate. The report should distinguish a Snowflake-enforced role or service boundary, a customer-enforced application boundary and a prompt-level instruction. The last of these should not be accepted as the sole guard on indexed data.

Include trace access in the data contract

The Agent's answer is not the only place sensitive text may appear. Snowflake's Agent monitoring documentation says logs include conversation history, planning and tool-execution spans, SQL execution and inputs and outputs associated with spans. It says viewing Agent logs requires MONITOR or OWNERSHIP on the Agent plus the specified Cortex database role. A data access assessment should therefore consider who can inspect traces that contain synthetic document text, query results or user questions.

Give one monitoring role and one ordinary caller role a controlled synthetic conversation. Then compare the views each role has of the thread and trace. The security owner should define whether the monitor is intended to see full tool results and how the organization handles sensitive content in logs. The tester can show whether the configured grants match that policy. It should not paste full production prompts or retrieved records into its own report. If application-side logging copies Agent responses or tool results, include that store separately because its access controls are not proved by Snowflake's Agent MONITOR grant.

Trace data can also make the final finding more precise. A final answer may omit the source marker while a tool result contains it, or the final answer may include the marker from a source the end user was not meant to access. The report should state whether the undesired data appeared in a Search result, a generated SQL result, a custom tool output, a trace or the user-visible response. Each location has a different remediation owner.

Rules of engagement for an enterprise test

Use customer-owned nonproduction Snowflake objects and a synthetic corpus. The buyer should provide the test service, Agent, roles, warehouse, datasets, application accounts and approved query window. State whether the assessor may change grants or the source query, invoke a custom tool, inspect monitoring events or test the app's tenant selector. If the test spans a production account, limit it to approved disposable objects and state query limits and stop conditions. Do not use real employee, customer or regulated documents as test markers.

The test should avoid broad adversarial prompt strings or instructions that would cause unnecessary data retrieval. Authorization can be demonstrated with benign questions about unique synthetic markers. For a direct Search case, a controlled query is enough to show which documents are returned. For an Agent case, a question about the same marker shows the route taken and what is visible in the answer and trace. The report should describe the authorization decision and business impact without publishing an extraction recipe.

Ask for an environment and change log. The effective grants, source query, Agent version, tool configuration and tenant policy should be captured at the time of testing. A result from last week's Agent specification may no longer describe the release candidate. When a grant or source query changes to fix a finding, retest the original positive and negative cases against the new version. This avoids closing a finding merely because the screenshot of a grant looks narrower.

Deliverables that support a release decision

The executive summary should tell the buyer which identities could query which indexed material, through which service and Agent tool, and whether any result crossed the intended team or tenant boundary. The technical report should list tested roles, active secondary roles, source service, synthetic markers, returned columns, Agent tool calls, trace visibility, observed decisions and remediation. The evidence should be sanitized and reproducible by the owner. Findings should be prioritized by the actual data contract, not by a generic “AI” label.

The report should also list what was not proved. Examples include a production source query that differs from the sandbox, a custom tool not available to the assessor, a direct Search route not granted to test identities, or a trace store owned by another team. If the test only observed the Agent playground, it cannot conclude that all direct Search query paths are safe. If it tested only base-table row policies, it cannot conclude that owner-rights Search results are limited to the end user's source-table rights. These limits should be explicit in the release recommendation.

What Stingrai can scope

Stingrai is a CREST-accredited offensive security firm. Its human-led API penetration testing examines authorization and business logic across roles and tenants; its web application testing can cover the front end that chooses the user and tenant context. For a Cortex deployment, a scoped engagement can combine customer-controlled Snowflake grants, Search results, Agent tool behavior and the connected app's identity mapping under agreed rules of engagement.

The aim is a decision that a data owner and security lead can defend: this role can retrieve these synthetic documents, that role cannot, this Agent run used these tools, and the trace is visible to these monitoring roles. The results can support the customer's compliance program and provide evidence for an audit. The SOW should name the exact services and agent paths under test, including any separate cloud configuration work that the buyer wants covered.

Procurement questions to settle before a quote

Ask whether the test vendor will inspect the Search source query and service owner role, or only ask the Agent questions. Ask whether it will test a direct Search query as a role that has service USAGE but lacks source-table access. Ask how it will verify the role selected by the application and the tools actually available to that role. Ask whether the tenant test covers generated SQL, Search retrieval or both. Ask whether Agent traces and application-side copies of answers are in scope. Ask how the vendor will report the currently configured inaccessible-tool behavior and any untested path.

These questions make competing proposals comparable. A generic LLM assessment may be useful for prompt handling and response quality, while this scope requires grant, index, role and result evidence. The buyer should purchase the latter when the release decision is about who may retrieve governed enterprise data through Cortex Search and Agents.

FAQ

What does a Snowflake Cortex Search and Agent data access security assessment cover?

It covers the Search service's indexed corpus and owner role, service query grants, direct Search results, the Agent caller role, configured tool privileges, tenant-specific SQL policy where used, and access to Agent traces. The buyer should require allowed and denied results with synthetic records for each applicable audience.

Can a role without access to a source table query its Cortex Search index?

Yes, if the role has the privileges to query the Cortex Search service. Snowflake says Search runs with the service owner's rights and a query role may retrieve indexed data even when that role cannot read the underlying source objects. The buyer should test the indexed corpus and service grants directly.

Does a source-table row access policy automatically restrict every Cortex Search caller?

No. Snowflake says a Search caller may see results from rows the service owner can read even when the caller cannot read those rows in the source table. Assess the Search service's indexed data and query audience separately from the source-table policy.

Is USAGE on a Cortex Agent enough to use all its tools?

No. Snowflake says the caller's active roles also need privileges on each configured tool. The assessment should record the effective caller role, each tool grant, whether the tool ran, and what the Agent returned when a tool was unavailable.

Do immutable tenant session attributes protect Cortex Search results?

Snowflake documents immutable session attributes paired with row access policies for generated SQL in Cortex Agents. Its Cortex Search documentation separately describes owner-rights queries over indexed data. Test the SQL policy and Search retrieval as distinct paths; do not assume one result proves the other.

What happens if an Agent cannot access a configured tool?

Snowflake documents accept as the default inaccessible-tool mode: the run can continue with accessible tools and report the others as warnings. The buyer should define whether that behavior is acceptable for the workflow and test whether the answer accurately reflects missing evidence.

Should the assessment inspect Agent traces?

Yes, when traces are enabled for the deployment. Snowflake says Agent logs can include conversation history and tool inputs and outputs, and that monitoring privileges control who can view them. Test trace access with synthetic content and approved monitoring roles.

Can this assessment replace a Snowflake data sharing review?

No. A Cortex assessment examines indexed retrieval, Agent roles and tool paths inside the buyer's application. A data sharing review examines provider grants and consumer access across Snowflake accounts. A deployment that uses both mechanisms needs each boundary named in the statement of work.

Related reading

• Snowflake data sharing security assessment

• RAG vector store access control testing

• Multi-tenant SaaS penetration test scope

• AI agent audit log evidence gap

Sources

• Snowflake, Query a Cortex Search Service

• Snowflake, Cortex Search overview

• Snowflake, Cortex Agents

• Snowflake, Agent access control and authentication

• Snowflake, Inaccessible tool handling

• Snowflake, Multi-tenancy for Cortex Agents

• Snowflake, Monitor Cortex Agent requests

Talk to Stingrai

For a Cortex release that needs role-by-role data access evidence, Get a Quote for a scoped human-led assessment or book a free discovery call to review the services, roles and test fixture.