What are MCP security best practices for giving agents warehouse access?
Scoped tokens, read-only roles, audience validation and audit trails for agents that query your warehouse
The most important MCP security rule for warehouse access is that an MCP server must only accept access tokens issued specifically for it, and must never forward a client's token to the warehouse: the MCP Security Best Practices document states that MCP servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server" and forbids token passthrough. Everything else (read-only roles, scope design, audit logs) builds on that boundary.
Key Takeaways
- •Bind every token to the MCP server with an RFC 8707 resource indicator, validate the audience on each request, and give the server its own separate credential for the warehouse. Never pass the client's token through.
- •Start agents on a read-only warehouse role with a minimal scope set, and elevate only when a privileged operation is first attempted. The MCP spec describes this progressive, least-privilege scope model.
- •Log every tool call with the acting identity and the warehouse query it produced. Snowflake's QUERY_HISTORY view keeps 365 days of queries, so the warehouse can corroborate your agent audit trail.
- •Treat the MCP client and server as attack surface too: block private IP ranges to prevent SSRF, sandbox local servers, and never use sessions for authentication.
Why agent access to a warehouse is a different risk
A human analyst reads a dashboard; an agent composes SQL, chains tools, and acts on whatever text comes back. That changes the threat model in three ways. First, the agent's credentials are long-lived and broad if you let them be. Second, the content the agent reads (table comments, column descriptions, query results) can carry instructions, so the agent can be steered by data it was only supposed to read. Third, the MCP server sits between the model and the warehouse and becomes a confused-deputy candidate: it holds privileges the end user may not have.
We build Data Workers as MCP servers, so we run into these decisions ourselves. The practices below are the ones we think any team should apply, whether you use our agents, a vendor MCP server, or one you wrote.
Practice 1: Bind tokens to the MCP server and refuse passthrough
The MCP authorization specification requires clients to send the OAuth resource parameter from RFC 8707 in both authorization and token requests, so the token is minted for one MCP server. The server must then validate that it is the intended audience and reject anything else. If the server calls a warehouse, it acts as a separate OAuth client with a separate token; the spec says it must not pass through the token it received from the MCP client.
The security document lists why passthrough is dangerous: it bypasses rate limiting and monitoring that depend on token audience, it makes audit logs show the wrong identity, and it lets a stolen token use the server as a data-exfiltration proxy. For a warehouse this matters directly. If the downstream log shows only a shared service account, you cannot answer who asked for a given query.
Practice 2: Give the agent a read-only warehouse role
On the warehouse side, use the platform's role model rather than application-level checks alone. Snowflake's access control overview describes privileges granted to roles, roles granted to users, and role hierarchies where higher roles inherit lower ones. It also notes that Snowflake has no super-role that bypasses authorization checks, and that ACCOUNTADMIN should go only to a limited number of users. An agent should never run under a role that sits near the top of that hierarchy.
In practice we create a dedicated role per agent purpose (for example, a role that can SELECT from a curated set of schemas and nothing else), attach it to a dedicated service user, and keep write grants out of the default path. Our open-source edition is read-only by default for the same reason: a mistaken or manipulated agent can then read the wrong table but cannot drop one. Writes should be a deliberate, separately approved capability.
Practice 3: Minimize scopes and elevate progressively
The security best practices page has a section on scope minimization. It warns against publishing every scope in scopes_supported, against wildcard scopes such as * or full-access, and against bundling unrelated privileges to avoid future prompts. Its recommended model is a minimal initial scope set containing only low-risk discovery and read operations, with incremental elevation through targeted WWW-Authenticate scope challenges when a privileged operation is first attempted.
For warehouse tools this maps to a simple split: schema and metadata lookups in the baseline scope, row-level reads in a second scope, and anything that mutates data or grants access in a third that triggers a human approval. Log each elevation event with the requested scope, the granted subset and a correlation ID, as the spec suggests, so you can see scope inflation over time.
Practice 4: Harden the MCP client and server surface
The same security document covers attacks that have nothing to do with SQL. Its SSRF section tells clients to require HTTPS for OAuth URLs and to block private and reserved ranges, including 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and the 169.254.0.0/16 link-local range that holds cloud metadata endpoints. It adds that you should not hand-roll IP validation, because encoding tricks defeat custom parsers. The OWASP SSRF Prevention Cheat Sheet covers allowlists and network-level controls in more depth.
Other items from the same document that matter for warehouse agents: use secure, non-deterministic session IDs and never treat a session as authentication; require explicit consent and sandboxing before running a local MCP server from a one-click configuration; and use the stdio transport or an authenticated, restricted channel for local servers. If you run a proxy that fronts a third-party API with a static client ID, implement per-client consent and exact redirect URI matching, and keep OAuth state values single-use with a short expiry (the document gives 10 minutes as an example).
Practice 5: Encrypt, isolate and keep data in your perimeter
The spec requires all authorization server endpoints to be served over HTTPS, and your warehouse connection should use TLS as well. Beyond transport, decide where the MCP server runs. Running it inside your own network or VPC means query results go to the model client you choose and no further. Our own posture is that data stays in the customer's infrastructure; whichever product you pick, ask where result sets travel and who can see them.
Also treat result content as untrusted input. Table and column comments, free-text fields and ticket descriptions can contain instructions aimed at the model. Keep tool permissions narrow enough that a hijacked agent cannot do much, because filtering prompts alone is not a reliable defense.
Practice 6: Log every call, and keep the warehouse as a second witness
An audit trail for an agent needs the human or system identity behind the request, the tool called, the arguments, the generated SQL and the result size. The warehouse is a useful second source: Snowflake's QUERY_HISTORY view covers the last 365 days, with latency of up to 45 minutes. Tag agent sessions with a query tag or a dedicated user so you can join the MCP log to warehouse history during an incident review.
Alerts should key on behavior that is unusual for an agent role: a spike in rows scanned, access to a schema outside the allowlist, repeated permission-denied errors, or a sudden scope elevation. Our Governance Agent handles PII detection, RBAC policy generation and audit trails for this kind of review, and the Usage Intelligence Agent reports who queried what, so cold or over-exposed tables show up before an agent finds them.
Where the common data tools fit
No single product covers the whole path from agent to warehouse. The table compares tools that teams commonly weigh when they add governance and monitoring around agent access. It describes what each does, not a ranking.
| Tool | Approach | Where it fits | Limits |
|---|---|---|---|
| Great Expectations | Open-source data validation with declarative expectations | Checking that data an agent reads or writes meets quality rules | Validates data; does not authenticate agents or control warehouse grants |
| Monte Carlo | Data observability that detects anomalies and incidents | Spotting unusual volume or freshness changes after agent activity | Detection and alerting; access control lives elsewhere |
| Datafold | Data diffing and CI checks for changes | Reviewing the effect of agent-proposed transformation changes before merge | Focused on change validation, not runtime access policy |
| OpenMetadata | Open-source metadata catalog with lineage and ownership | Documenting sensitive columns and owners that role design depends on | A catalog; it does not sit in the MCP request path by itself |
| Bigeye | Data quality monitoring with metrics and alerts | Monitoring quality SLAs on tables agents depend on | Monitoring focus; no OAuth or MCP token handling |
| MLflow | Experiment tracking and model lifecycle management | Logging agent and model runs for reproducibility | Tracks ML runs; not a warehouse access control layer |
| Warehouse-native roles (for example Snowflake RBAC) | Privileges granted to roles, roles granted to users | The enforcement point for what an agent can read or write | Per-platform; does not govern the MCP layer or multi-warehouse paths |
| Data Workers | MCP-native agent swarm; open-source edition is read-only by default; Pro adds writes with approval workflows and audit trails | Coordinating governance, quality and incident agents from Claude Code, Cursor or other MCP clients | Adds a system to operate; it complements warehouse roles and does not replace them |
A rollout order we recommend
Teams that try to do all six practices at once usually stall. We suggest this order: first, a read-only role on a service identity and an allowlist of schemas; second, token audience validation and a ban on passthrough in whatever MCP server you run; third, logging with correlation IDs; fourth, scope tiers and an approval step for writes; fifth, network controls such as an egress proxy; sixth, continuous review of access patterns. Each step is independently useful and reduces the blast radius if the next one slips.
Frequently Asked Questions
What is token passthrough and why does MCP forbid it?
Token passthrough is when an MCP server accepts a token from a client and forwards it to a downstream API without checking that the token was issued to the server. The MCP security document forbids it because it bypasses controls tied to token audience, muddies audit trails and lets an attacker with a stolen token use the server as a proxy.
Should agents have write access to the warehouse?
Should agents have write access to the warehouse by default?
No. Start with a read-only role and add write capability only for specific tasks, behind an approval step and with the elevation logged. The MCP scope-minimization guidance recommends a minimal initial scope with incremental elevation, and Snowflake's role model lets you keep write grants on a separate role.
How do I tie an agent's queries back to a person?
Carry the end user's identity through the MCP request, record it with the tool call, and set a query tag or dedicated service user in the warehouse. Then join your MCP log to the warehouse query history. This only works if the server does not pass the client's token through, since passthrough hides which identity made the call.
Does read-only access make an agent safe?
It removes destructive writes, but not exposure. A read-only agent can still read PII, and its results can be sent wherever the client sends them. Restrict schemas and columns, mask sensitive fields, and monitor access patterns in addition to removing write grants.
Do local MCP servers need extra care?
Yes. The MCP security document warns that local servers run with the privileges of the client and can be targeted through malicious startup commands or DNS rebinding. Show the exact command before running it, sandbox the process, and prefer stdio or an authenticated, restricted channel.