Cortex Analyst Tool vs Raw SQL Tool on the Snowflake Model Context Protocol Server: Which Is Safer for Agents?

What actually differs between the two tools

The core difference is who controls the shape of the query. With a Cortex Analyst tool, the agent passes a natural-language request. SQL is generated against a defined semantic model, so the tables, metrics and relationships the agent can reach are bounded by what the model describes. With a raw SQL tool, the agent writes the statement itself and the tool executes it. The tool argument is the full query.

This matters because MCP tool arguments are LLM output, and that output can be shaped by untrusted context. OWASP's MCP guidance says to validate all inputs to MCP server tools and treat them as untrusted. That applies to both tools. The difference is what an untrusted argument can express. A question passed to a semantic-model tool is constrained twice, once by the model and once by the role. A statement passed to a raw SQL tool is constrained only by the role, plus whatever limits you add.

A third point is excessive agency. OWASP advises granting agents the minimum tools required for their task. Exposing a raw SQL tool to an agent that only answers business questions fails that test even if the role is carefully set.

Side-by-side comparison across six criteria

The table applies the same criteria to each tool. It describes the control posture each tool allows, not a guarantee of any specific deployment.

• Query surface: Cortex Analyst: the agent supplies a question and SQL is generated within a semantic model. Raw SQL: the agent supplies any statement the tool will accept.
• Data scoping: Cortex Analyst: the semantic model defines what is queryable, and the role limits it further. Raw SQL: scope depends on role privileges and schema design alone.
• Reliance on roles and privileges: Cortex Analyst: generated SQL still runs under a role, so the role must be least-privilege. Raw SQL: the role is the primary control, so any excess privilege is directly reachable.
• Injection exposure: Cortex Analyst: injected instructions can steer the question but not write the statement directly. Raw SQL: injected instructions can steer the exact statement executed.
• Result predictability: Cortex Analyst: results follow semantic model definitions, so model quality drives accuracy. Raw SQL: results depend on the agent's SQL, schema understanding and any applied limits.
• Auditability: Cortex Analyst: evidence needs both the request and the generated SQL. Raw SQL: the statement is the tool argument, but it still must be tied to the agent request.

Where Cortex Analyst narrows risk, and where it does not

Cortex Analyst reduces the chance that an agent issues a destructive or unexpectedly broad statement, because the agent never composes SQL directly. A defined semantic model also makes results more consistent: the same business term maps to the same logic each time. For security reviewers, that makes expected behavior easier to describe and test.

The limits are just as important. Generated SQL still runs under a role. If that role can read sensitive columns or write to tables, the semantic model is not a substitute for removing those privileges. A semantic model is also a modeling artifact, not an access control. If it exposes more than the use case needs, the agent can request more than it should. Model quality affects results, so an inaccurate definition can return a confident but wrong answer, which is a reliability concern as well as a security one.

Prompt injection also remains relevant. OWASP separates prompt-level injection that redirects agent intent (AAI2) from tool-layer input validation and sandboxing weaknesses (AAI8). A semantic-model tool lowers exposure to the second category, but it does not remove the first. An injected instruction can still ask for data the agent was never meant to retrieve, and the tool will answer if the role and model allow it.

When a raw SQL tool is defensible

Some workloads need flexibility that a semantic model does not provide, such as engineering diagnostics, data profiling or exploratory analysis on a bounded dataset. A raw SQL tool can be acceptable there if the surrounding controls are strict and tested.

The baseline is a read-only role with no write or administrative privileges, so a malicious or mistaken statement cannot modify data. Scope the role to specific schemas that hold only data the use case requires. Apply enforced limits on query cost and result size so an over-broad query is cut off instead of exhausting resources or returning bulk data. Give each agent its own identity so activity can be attributed. Test authorization on the tool directly, since OWASP MCP07 covers failure to enforce access controls during interactions.

Even with these controls, the residual risk is higher than with a semantic-model tool. The agent can still read anything its role can read, and a statement can be crafted to pull data in volume. Treat the raw SQL tool as a reviewed exception. OWASP recommends handling the addition of an MCP server as a controlled dependency change with review before use, and the same discipline fits enabling a high-capability tool.

Choosing a tool by use case

Start from the task and the least capability that completes it. These rules of thumb follow from the criteria above.

• Business questions over curated data: Use Cortex Analyst with a tightly scoped semantic model and a least-privilege role.
• Agents that must never modify data: Expose no write-capable role. Do not rely on the tool type to prevent writes.
• Exploratory work on a bounded dataset: A raw SQL tool may fit if the role is read-only, schemas are scoped and limits are enforced.
• Sensitive or regulated data: Prefer the narrower tool, and require tool-call evidence of what ran for either choice.
• Higher-risk actions: Add human approval before execution rather than relying on the agent's judgment.

What role permissions cannot enforce, and where tool-call policy fits

Native roles and privileges answer a static question: what is this identity allowed to access? They do not evaluate each request in context. NIST describes attribute-based access control as policy evaluated against attributes of the subject, object, operation and sometimes environment conditions, which is a different model from role membership alone. A role cannot, by itself, pause a statement for human approval, redact a field in a response for a particular request, or stop a call that is permitted in general but wrong in this instance.

Auditability is the second gap. OWASP MCP08 notes that limited telemetry impedes investigation and incident response. For a regulated enterprise, the question is both what the agent was permitted to do and what it actually ran. That requires the request, the executed SQL and the policy decision tied together for each call.

Trussed enforces policy in the execution path at the MCP tool call. For either Snowflake tool type, it can allow, redact, block, rate limit or escalate a call for human approval, and enforcement is at runtime, not reviewed after the fact. Each decision produces audit-ready evidence of what was permitted and what ran. Scope is individual interactions and tool calls. Trussed complements, and does not replace, least-privilege roles and a well-scoped semantic model.