How to stop a Snowflake Model Context Protocol agent from running full scans on transaction history

Why MCP-connected agents produce unbounded transaction queries

An agent with a free-form SQL tool writes queries from a task description and whatever schema it can see. The model is optimizing to answer the question, not to limit the work the warehouse does. A request such as "show chargebacks for this merchant" can produce a correct query that filters on merchant but has no date predicate, so it reads every year of history.

Four query shapes cause most of the trouble: no date filter, a predicate that does not line up with how the table is clustered or partitioned, no row limit, and a broad join that multiplies the rows read. Each one is valid SQL and passes any syntax check.

The cost shows up in three places. Compute is consumed by work the task never needed. Latency grows, which can hold a shared warehouse. And the result set puts far more sensitive transaction data in front of the agent, and potentially into model context, than the task required. Because the problem is the shape of the query, the controls that matter must act on shape, not only on who is asking.

Layer two: design MCP tools that constrain query shape

The most effective change at the MCP server is to stop exposing a general SQL execution tool. Replace it with named tools that each answer one class of question, such as transactions for an account over a date range, or daily totals by merchant. The server builds the SQL from a template and the agent supplies only typed parameters.

Several design choices carry most of the benefit. Make start and end dates required, and reject any range beyond a maximum window. NIST gives the general pattern: if users can supply a time range, limit it to the last 30 days instead of allowing a query from 1972 onward. The right window for a transaction table depends on your own business requirements. Apply a server-side row limit with a ceiling the agent cannot raise. Point each tool at an allow-listed view, and define joins inside the view so the agent never composes them. Where possible, require a predicate on the column the table is clustered on, so the engine can skip data that does not match.

Annotate each tool with the permissions it requires so authorization checks can be automated and logged. Issue the agent ephemeral, task-scoped credentials rather than long-lived static secrets.

There are tradeoffs. Parameterized tools reduce flexibility, and the team must build and maintain a catalog of them. Start with the handful of questions that account for most agent traffic. If free-form SQL has to remain for some use, keep it behind a read-only role and a separate, tightly limited warehouse, and treat it as the highest-risk tool.

Layer three: enforce policy on each tool call before it runs

Well-designed tools still leave gaps. A tool may accept a window that is valid but larger than a given task needs. A free-form tool may exist for a legacy use. A tool definition tells the agent what it may ask. It does not evaluate each request at the moment it is made.

Zero trust architecture offers a useful model: requests are directed to a policy enforcement point, and trust is evaluated before access is granted, per session. Applied to agents, the enforcement point sits between the agent and the MCP server or data platform and evaluates each tool call. NIST also describes a hybrid pattern in which a central control holds the full policy suite and a minimum set of application-specific policies sits near each application.

Useful policies at this layer include blocking a call that has no date predicate or exceeds the maximum window, clamping or rejecting row limits above a ceiling, rate limiting repeated calls using the caller's recent history, redacting sensitive fields in returned data, and escalating calls that cross a defined risk threshold to a human approver. Reserve escalation for genuinely unusual requests. NIST warns that frequent escalation leads to consent fatigue and habitual approval. The response plan should also include containment, such as blocking an individual credential or revoking an agent's authority when behavior is anomalous.

Trussed enforces policy in the execution path on individual MCP tool calls: allow, redact, block, rate limit, and escalate for human approval. Enforcement happens at runtime, not through review after the fact, so a query without a bounded date range can be stopped before it reaches Snowflake.