Snowflake Cortex Agents are generally available. Teams are adopting them quickly, and for good reason: a single agent can answer a natural language question like "Which sales reps closed the most deals and what were their customers worried about?" by combining SQL execution over structured data with semantic search over unstructured content. No application code required.

Most organizations want to move faster with Cortex Agents than their current governance posture allows. The blocker is rarely the technology. It is that security and compliance teams cannot answer a basic question: what data can each agent actually reach, how sensitive is it, and who can invoke the agent? Without a systematic way to answer that, the default is either a slow rollout gated on manual review or a broad rollout where the risk is unknown.

Organizations that can see their agent-to-data topology clearly can make graduated decisions: deploy immediately where the data is appropriately scoped, restrict where it is not, and fix specific gaps. Visibility is what turns a months-long governance review into a days-long deployment decision.

This post covers how Cortex Agents work, what makes their data access surface different from standard Snowflake queries, and how Bedrock Data ArgusAI maps and governs these agents so teams can adopt them with confidence.

How Cortex Agents Work

A Cortex Agent is an orchestration layer backed by a foundation model, typically Claude. When a user submits a question, the agent decides which tools to invoke, sequences those calls and synthesizes a final response. Two tools do the heavy lifting.

Snowflake AI Studio: Cortex Analyst, Cortex Search and Cortex Agents

How a single Cortex Agent orchestrates access across structured and unstructured data

Cortex Analyst converts natural language into SQL and executes it against your structured tables. It runs under the caller’s role, so standard Snowflake RBAC, masking policies and row access policies all apply. If you already govern table-level access in Snowflake, Cortex Analyst’s behavior is familiar.

Cortex Search builds a hybrid vector + keyword index over a source table or view. Users query the service via a REST API and results come from the pre-built index. This enables fast semantic retrieval over large unstructured datasets (call transcripts, support tickets, documents) that SQL alone cannot handle effectively.

The agent itself is defined as a YAML specification, deployed as a first-class object in Snowflake and callable via the REST API or Snowsight’s Agent Playground. A single agent can wire together multiple Analyst tools pointing at different semantic models and multiple Search services spanning different databases, all responding to the same natural language question.

That composability is the core value proposition. It is also what makes a full discovery scan valuable: once you can see the complete agent-to-data graph, you can make specific decisions about what to enable and where to focus any remediation.

Snowflake Database Explorer showing multiple databases accessible by Cortex Agents

What Makes Agent Governance Different from Standard Snowflake Auditing

Most Snowflake governance workflows are built around SQL access: which roles have SELECT on which tables, which masking policies are attached, which queries ran against which objects. This works well for the SQL layer and covers a large surface area.

Cortex Agents assemble data access paths that sit outside this model.

A Cortex Search Service is queried via a REST API call, not a SQL statement. Cortex Analyst tool invocations are mediated by the agent runtime, not direct table access. The agent specification itself, which defines which tools are wired together and which data sources each tool can reach, is a YAML object in Snowflake. It does not generate access events in the standard audit trail.

Standard SQL auditing vs. ArgusAI agent-aware governance

This is not a deficiency in Snowflake’s security model. It is a reflection of the fact that agents compose data access across multiple tools and sources in ways that existing audit infrastructure was built before and was not designed to observe. The SQL layer is governed. The identity layer controls who can invoke the agent. But the compound access surface that the agent assembles, combining structured queries with semantic search across databases, is not visible to any single existing control.

For teams trying to expand their Cortex Agent deployment, this is the specific gap that slows them down: they cannot systematically describe what their agents can reach, so every new agent requires manual review. Closing this gap is what turns agent governance from a bottleneck into a repeatable process.

Discovering and Mapping Cortex Agents with ArgusAI

Bedrock Data ArgusAI crawls Cortex Agents in your Snowflake environment and maps their complete configurations. Using the Snowflake REST API v2 with key-pair authentication, the crawler captures:

• Agent metadata: the foundation model configured for orchestration and budget constraints
• Cortex Search Services linked to the agent, including the definition query, search column, indexed attributes and row count
• Cortex Analyst tools, including the semantic model YAML fetched directly from Snowflake stage storage, parsed to extract the tables, dimensions, measures and time dimensions the tool can query
• Cross-database references where a single agent’s tools span multiple databases and schemas

The output is a graph. Each agent node connects to its tools. Each tool connects to the underlying data objects. Those objects carry the classifications and sensitivity scores that the platform has already established through its standard data discovery process.

This graph is the foundation for every governance decision that follows. With it, a security team can evaluate a new agent in minutes instead of days: look at what it connects to, check whether those data sources carry sensitive classifications, and decide whether it is ready to deploy or needs scoping changes first.

ArgusAI AI Agents Inventory: agents discovered across Snowflake with impact scores and data classifications

Classifying What Each Agent Can Reach

Once the agent topology is mapped, the platform evaluates the sensitivity of every data source connected to each agent.

For Cortex Search Services, this means analyzing whether the indexed columns contain PII, financial data, healthcare identifiers or other sensitive categories. The source query for each service is inspected to understand which columns are included in the index and what access controls are in place at the source.

For Cortex Analyst tools, this means evaluating the tables referenced in the semantic model: which columns are exposed to natural language queries and what sensitivity those columns carry.

Each agent receives an Impact Score that aggregates sensitivity across all its connected data sources. A high score does not mean the agent should be blocked. It means the agent warrants review before broad deployment, and it tells the reviewer exactly where to look.

ArgusAI Agent Overview: Impact analysis, data classifications and business context

Identifying Configuration Gaps

Mapping the topology and classifying the data tells you what each agent can reach. The next step is identifying where an agent’s configuration does not align with the organization’s data handling requirements, so that remediation can be targeted.

ArgusAI examines each agent’s connected search services and analyst tools against the sensitivity of the data they access. Specifically:

Unredacted sensitive columns in search indexes

A search service whose source query includes sensitive columns without corresponding source-level redaction means that sensitive content is embedded in the index and retrievable via natural language queries, outside the reach of column-level masking policies.

Unreviewed sensitive references in semantic models

An analyst tool whose semantic model references tables with sensitive classifications that have not been reviewed against the tool’s intended use case. The model may expose columns that the tool’s purpose does not require.

Scope exceeding purpose

Agents with broad data access whose reach exceeds what their documented purpose requires. A customer support agent that can also query the HR database is a configuration gap, not a feature.

Each gap maps to a concrete remediation: remove a column from the search service definition, narrow the semantic model, restrict the agent’s tool set. The point is precision. Rather than auditing the entire Snowflake environment before deploying any agents, teams can fix the specific issues that matter and move forward.

ArgusAI Policy Flow: Mapping data flow from data sources through the agent to the foundation model

Continuous Monitoring as the Agent Inventory Evolves

Cortex Agent configurations change. New agents get deployed. Search service definitions get updated. Data sources accumulate new sensitive columns. Each of these changes can alter an agent’s exposure profile, and the teams that deployed the agent may not be the teams responsible for governing the data it accesses.

A governance posture established at deployment time degrades unless it is continuously validated. An agent that was correctly scoped last quarter may be overexposed today because someone added a column to a source table, updated a semantic model or created a new search service that indexes a previously ungoverned dataset.

ArgusAI’s continuous monitoring engine re-crawls agent configurations and cross-references them against the current data classification state. When a search service is updated to include a new source column that carries a PII or financial classification, ArgusAI re-scores the associated agents and surfaces an alert.

The agent graph also captures when Cortex Analyst semantic models reference tables that have gained new sensitive columns since the model was last updated. This is a scenario where the sensitivity of what an agent can reach changes without any modification to the agent configuration itself.

The four-stage ArgusAI governance pipeline: Discover, Classify, Identify Gaps, Monitor

When a developer deploys or updates an agent, the system:

1. Rebuilds the agent’s data connection graph based on the latest configuration

2. Re-scores the agent’s impact level against the current data classification state

3. Notifies security or compliance teams with actionable context: what changed and why it matters

This is what makes agent adoption sustainable. Teams can deploy new agents knowing that the governance layer will catch drift and flag issues as they emerge, rather than requiring a full review cycle for every change.

Governing Cortex Agents at Scale

Snowflake Cortex Agents represent a meaningful step forward in how structured and unstructured data can be queried together. The ability to answer complex business questions by orchestrating SQL execution and semantic search through a single natural language interface is genuinely useful, and the pace of adoption reflects that.

The organizations that will adopt Cortex Agents fastest are not the ones with the fewest security requirements. They are the ones that can see what each agent reaches, classify what that access represents and detect when the posture changes. That visibility is what converts a manual, agent-by-agent approval process into a scalable governance model where teams can deploy with confidence and security can verify continuously.

Bedrock Data ArgusAI

A persistent map of agent-to-data connections, automated classification of what each agent can reach, and continuous monitoring that keeps the governance picture current as the agent inventory evolves.

Learn more at bedrockdata.com