Snowflake Masking Policies vs Runtime Enforcement for MCP Agent Queries on Account Numbers

What masking policies do well

A Snowflake masking policy is a column-level control. It returns a masked value for account numbers unless the querying role is entitled to see the clear value. The decision is made inside the database, close to the data, so it applies regardless of which client, notebook, BI tool or connector issued the query. That is a strong property, and no agent architecture should drop it.

Masking also preserves the shape of the data. NIST SP 800-188 describes masking tools as removing or replacing designated fields while maintaining relationships between tables. For account numbers, which NIST IR 8053 lists among identifier categories, that means analysts and applications can still join and count records without handling the real identifiers.

The same NIST publication adds a caution that applies by analogy. In the context of government dataset de-identification, it says masking tools should not be the sole mechanism for confidentiality in non-public data sharing without additional controls. That context is not AI agents, but the layering principle carries over.

Where MCP agent queries stretch the data-layer model

An MCP server typically queries Snowflake under a shared service identity or a delegated role. The masking policy sees that role. It does not see the agent's task, the specific tool call or the intent of the user who prompted it. Four gaps follow from this.

First, a service role that holds unmasking privileges returns clear account numbers to every agent request that reaches it, whether or not a given task needs them. Second, account numbers can reappear after the query. Free-text fields, derived or joined values, and tool outputs passed back to the model can all carry identifiers into the model's context, and users can paste them into prompts. Which of these paths a masking policy covers depends on how the data is modeled and tagged, so each should be tested rather than assumed.

Third, the data layer makes no per-tool-call decision. Two calls from the same role, one summarizing portfolio trends and one looking up a single customer's balance, are treated identically. Fourth, the evidence is thin. Query history shows which role ran which statement, but not what the agent was permitted to see, what was withheld, or who approved an exception.

None of these are defects in masking. They are consequences of enforcing at a point that has no view of the agent's request.

Side-by-side comparison

The table compares the two controls across the dimensions most relevant to account numbers in MCP agent queries. Runtime enforcement here means policy applied in the MCP execution path, between the agent and its tools.

• Enforcement point: Masking policies: inside the database, at query evaluation. Runtime enforcement: in the MCP execution path, on each request and response.
• Identity context: Masking policies: the role executing the query, often a shared service or delegated role. Runtime enforcement: can also use the requesting user, the agent and the task, if the layer receives them.
• Granularity: Masking policies: column and role. Runtime enforcement: individual tool calls, including arguments and returned content.
• Tool inputs and outputs: Masking policies: act on query results from the table. Runtime enforcement: inspect inputs, outputs and content bound for the model, including free text.
• Response actions: Masking policies: return a masked or clear value. Runtime enforcement: allow, redact, block, or escalate for human approval.
• Audit evidence: Masking policies: query history tied to a role. Runtime enforcement: a per-decision record of the call, the policy applied and the outcome.

How runtime enforcement complements masking

Runtime enforcement works on the request and response, not on the table. Before a tool call reaches Snowflake, a policy can check whether the call is expected for the agent's task, and block or escalate it if not. After the call returns, a policy can inspect the payload for account-number patterns and redact them before the content enters the model's context. If a call genuinely needs a clear value, it can be routed to a human approver, with the decision recorded.

NIST IR 8505 describes a comparable general pattern for cloud-native applications: policy enforcement at a proxy, where modules identify sensitive data patterns in payloads and then redact, mask or block them, giving centralized and consistent enforcement across distributed applications. That document is not about MCP or Snowflake. Applying it to an MCP execution path is an architectural analogy, not a statement about any specific product feature.

The tradeoffs are real. Pattern-based detection of account numbers produces false positives and misses, and escalation adds latency and operator workload. Those costs are acceptable where a call is consequential, and unnecessary where the masked value is sufficient.

Criteria for evaluating a runtime enforcement product

Evaluate any product against the questions below, whichever vendor you consider. Does it decide per tool call, using the agent's task and the requesting user's identity, rather than only the shared service role? Can it inspect and act on account numbers in both tool inputs and outputs, and which of allow, redact, block and escalate does it support? Can it route a call to human approval and record the decision? Can it run in your own cloud, with retention and data residency you control? And what evidence does it produce, and how does that map to your own control requirements under frameworks such as NIST AI RMF and NYDFS? Ask for the evidence format itself, not a description of it.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Its actions are allow, redact, block, rate limit and escalate for human approval, scoped to individual interactions and tool calls. It generates continuous audit-ready evidence mapped to NYDFS, NIST, HIPAA, NAIC and the EU AI Act, and deploys self-managed in the customer cloud with configurable retention and data residency. It has run for 18+ months in continuous production in a regulated enterprise, with 100+ models under one policy plane. It complements Snowflake masking policies and does not replace them.