Query Approval Thresholds for Data MCP Servers: Setting Rules by Row Count and Data Sensitivity

Why row count and sensitivity belong in one policy

A data MCP server lets an agent run queries against a database or warehouse through tool calls. Two properties of a query determine most of its risk: how much data it returns and how sensitive that data is. Treating them as separate controls leaves gaps. A row cap alone allows a ten-row query that returns restricted fields. A sensitivity block alone gives no protection against a broad pull from a moderately sensitive table.

The operating context makes this more pressing. OWASP notes that, unlike traditional APIs, MCP servers run with delegated user permissions, dynamic tool-based architectures and chained tool calls, which raises the impact of a single weakness. Its MCP Top 10 also lists scope creep (MCP02), insufficient authentication and authorization (MCP07) and missing audit telemetry (MCP08). Prompt injection adds another path: injected content can steer data-access calls, and NIST documents injection attacks that push sensitive data to an attacker-controlled URL.

Review after the fact does not address any of this, because the data has already been returned. The thresholds have to be evaluated before results leave the server, on each call.

Define row-count bands and sensitivity tiers

Start with four row-count bands. The cutoffs are yours to set, because no standard prescribes numeric values. Tie them to the size of your datasets and to what a legitimate agent task needs.

A minimum-count band covers results so small that individual records become identifiable. NIST de-identification guidance describes suppressing cells whose counts fall below a predefined threshold, and warns that a poorly chosen threshold can leave re-identification risk higher than intended. A normal band covers typical task-sized results. A large band covers results that are plausible but warrant extra scrutiny. An excessive band covers results with no credible task justification.

Then define sensitivity tiers. Four are usually enough: public, internal, confidential and restricted. Classify at the column level where possible, since one table often mixes tiers. The query's tier is the highest tier among the fields it selects, filters on or joins. Classification comes from your existing data catalog or labeling work. The policy only needs a reliable tier for each field at decision time.

Set initial thresholds conservatively and loosen them against measured evidence. NIST advises choosing the most conservative threshold that still meets utility goals, and the same logic applies here. It is easier to relax a limit with data behind the decision than to recover from an exposure.

Combine the dimensions into a decision matrix

The matrix below shows one way to map sensitivity tier and row-count band to an action. Treat it as a starting template. Your organization sets the exact cells, and each exception should have a named owner.

• Public: Minimum: allow. Normal: allow. Large: allow with rate limit. Excessive: block or escalate.
• Internal: Minimum: allow. Normal: allow. Large: rate limit. Excessive: escalate for human approval.
• Confidential: Minimum: redact identifying fields. Normal: allow with redaction of sensitive columns. Large: escalate. Excessive: block.
• Restricted: Minimum: escalate, since a small result can still identify a person. Normal: escalate. Large: block. Excessive: block.

Enforce the matrix at the tool-call level

OWASP recommends requiring action-specific approval for high-risk operations before they run, and applying the same authorization and approval policy at each tool boundary. For a data MCP server, that means policy evaluation sits in the execution path of each tool call, not only at the client and not only in a later review.

The main design question is when row count becomes known. There are three workable approaches, and they combine well. First, constrain the query before execution, for example by requiring or applying a maximum row limit. Second, use an estimate where the data platform can provide one, and treat it as approximate. Third, hold the result at the enforcement point and count rows before returning anything to the agent. The third approach is the only exact one, and it means a query may execute before the decision is final. Pair it with a restriction on what the query is allowed to touch, so that the exposure is limited even if the count only appears afterward.

Sensitivity is easier to establish before execution. Parse the query, resolve the fields it references, look up their tiers and take the highest. Redaction then applies to specific columns instead of rejecting the whole call.

Escalation needs a precise scope. The approver should see the actual query, the tiers involved and the row-count band, and the approval should apply to that query only. A changed query is a new request. Define approver roles and escalation paths in advance, and decide what happens when no one responds. The default should be to deny.

Because tool calls can chain, evaluate each call independently. Independent evaluation does not bound the cumulative total across a session, so consider a per-session or per-identity rate limit as well. Also remember that thresholds enforced only on sanctioned servers do not cover shadow MCP servers (MCP09), so inventory matters as much as policy.

Evidence the enforcement should produce

An enforcement point that blocks or approves without a record is hard to defend and hard to tune. For each call, capture the query, the sensitivity tiers resolved, the row-count band and whether it was estimated or counted, the decision, the approver where one was involved, and the outcome. NIST guidance on interactive query interfaces recommends logging both queries and results, and staff review of individual queries, to deter and detect misuse. OWASP's MCP08 describes what happens without telemetry: investigation and incident response are impeded.

This record also drives tuning. A high escalation rate in one cell suggests the band is too tight or a workflow needs a purpose-built tool. A cluster of blocked excessive queries from one identity deserves a closer look.

Ownership matters too. NIST SP 800-188 describes a data release board that decides access methods, acceptable re-identification risk and records of prior releases. A comparable body can own the thresholds, review approved exceptions and re-check permissions periodically to counter scope creep.

Trussed enforces policy in the execution path of MCP servers, with actions that include allow, redact, block, rate limit and escalate for human approval, scoped to individual interactions and tool calls. The enforcement generates audit-ready evidence that maps to frameworks including HIPAA, NIST and the EU AI Act. Enforcement is at runtime, not reviewed after the fact.