Snowflake MCP Server Tools Ranked by Risk for Customer Financial Data

Where Snowflake access controls stop and the tool-call gap begins

Snowflake role-based access control decides which objects a role can touch. Masking policies change what a column returns to a given role, and row access policies filter which rows that role sees. These are the right foundation for customer financial data such as account, transaction and personally identifiable information, and none of them should be skipped.

They answer one question: what can this role reach? They do not answer a different one: what is this agent doing with this tool call, right now, and should it proceed? An agent holding a legitimately scoped role can still issue a very wide query, repeat a query many times, combine results from several tools, or pass retrieved content to a destination outside the data platform. Each of those actions is permitted by the role and still unacceptable for a particular use case.

The risk is compounded by how MCP tools are consumed. OWASP guidance on MCP servers names tool poisoning, prompt injection, memory poisoning and tool interference as risks of connecting models to tools and data sources. It also describes a technique in which a server that looks benign when approved later changes its tool metadata and uses a connected agent to reach sensitive information. Prompt injection that drives sensitive data to attacker-controlled servers has been disclosed in another AI platform, which makes the egress path a practical concern. A role-level control cannot see any of this. A control at the tool-call level can.

The five criteria behind the ranking

The criteria below are this page's own method, not a published standard. They are chosen because each one changes the worst-case outcome of a single call. Apply them to every tool your MCP server exposes, using the tool's actual definition rather than its name.

Read versus write capability. A tool that can modify or create data can corrupt records, and its effects persist after the session ends. Any write capability raises a tool to the top tier.

Query breadth. A tool that accepts free-form scope over many tables can return far more customer data in one call than a tool bound to a fixed, parameterized query. Breadth is the main driver of exposure volume.

Arbitrary SQL execution. A tool that runs model-generated SQL removes the designer's ability to predict what will be asked. It also lets an injected instruction shape the query directly.

Unstructured or semantic content. Search over documents, notes or semantic layers can surface account details or personal data inside free text. Column-level masking is defined on columns, so values embedded in text may not receive the same protection. Treat this content as sensitive until proven otherwise.

Data egress path. Ask where output can go after the tool returns it: back to the model only, into another tool, or to an external destination. Every additional hop adds exposure.

A tool that invokes another agent takes the tier of the most capable tool that agent can reach, because delegation extends the reach of the original call.

Risk tiers for MCP tool capabilities

Map each enabled tool to the highest tier any of its capabilities qualifies for. Where a tool fits two tiers, the higher one applies. The tiers describe capability classes, so confirm the actual behavior of each tool in your deployment before assigning it.

• Tier 1: Critical: Executes arbitrary SQL, performs any write, or can send output to an external destination. Worst case: broad exposure of customer records, altered data, or exfiltration in a single call.
• Tier 2: High: Runs semantic or analyst-style queries across many structured tables, or searches unstructured content that may hold account or personal data. Worst case: large-volume exposure of sensitive values that column controls do not cover.
• Tier 3: Moderate: Read-only, parameterized queries with a bounded result set and a defined business purpose. Worst case: repeated calls that aggregate into a larger disclosure than intended.
• Tier 4: Low: Returns metadata, schema descriptions or reference data that contain no customer records. Worst case: reconnaissance that informs a later attack.

Audit-ready evidence by tier, and where runtime enforcement fits

A reviewer in a model risk management or examination setting will want to see what the AI was permitted to do and what it did. A role grant and a masking policy show the first half only in the abstract. Evidence needs to be tied to individual calls.

The evidence each tier should produce scales with risk. For every tier: the tool called, the calling agent and role, the policy that applied, the decision taken, and the time. For Tier 3 and above, add whether any output was redacted and which rule triggered it. For Tier 2, add rate-limit events and the volume returned. For Tier 1, add the human approval record: who approved, when, for what request, and the outcome. For all tiers, keep a record of each approved tool definition and a re-approval record whenever that definition changes. NIST guidance supports alerting when AI activity passes a defined risk threshold and periodic monitoring of AI output for privacy risk, so alert events belong in the same record.

This evidence is only as reliable as the point where it is produced. Policy that is enforced at runtime, not reviewed after the fact, generates the record as a by-product of the decision itself. Trussed enforces policy in the execution path across agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval applied to individual interactions and tool calls. The resulting audit-ready evidence is mapped to frameworks including NYDFS and NIST, and it can be generated in a self-managed deployment inside the customer's own cloud, with configurable retention and data residency. Trussed is deepest in insurance, a regulated financial sector, and applies the same enforcement model to any regulated enterprise that must show what its AI was allowed to do and what it did.