Stopping One AI Agent from Joining Customer Data Across Snowflake and Postgres MCP Servers

How the join happens

Model Context Protocol gives AI agents a consistent, structured way to discover and use external tools, data sources, and services. When one agent is connected to both a Snowflake MCP server and a Postgres MCP server, it sees the tools from each as part of the same toolset.

A typical sequence looks like this. The agent calls a Snowflake tool and receives customer records. It then calls a Postgres tool, perhaps using an email address or customer ID from the first result as an argument, and receives a second set of records. Both results now sit in the agent's context, and the model can merge them into one profile. No database executed a join. The aggregation happened in the agent, across two separate tool calls.

This is an agent-behavior problem. Each call can be individually valid, yet the combined output is something neither system's permissions were designed to produce. Agents that extract data from several sources and act on it are an expected pattern in multi-agent designs, so the exposure should be planned for rather than treated as an edge case.

Where server-level and identity-level controls fall short

Native database controls such as roles, row-level restrictions, and column masking evaluate a request against one system. Snowflake does not know what the agent already retrieved from Postgres, and Postgres does not know what came from Snowflake. Each server can enforce its rules correctly and the combined result can still be too much.

Identity-level controls have a similar gap. If the agent holds valid credentials for both servers, each request is authorized on its own terms. A service account scoped correctly for each system does not express the rule that matters here: this agent should not hold both datasets in one context.

Zero trust guidance points the right way. Access decisions should rely on least privilege, be evaluated per request, and use context about the requester. A per-request check on an individual tool call is still not enough on its own. Unless policy also considers the agent's identity, target data source, and session history, it can approve each call in isolation while the aggregate stays unchecked.

What runtime policy on tool calls can and cannot do

Attribute-based policy is a useful model. Authorization is decided by evaluating attributes of the subject, the object, the requested operation, and environment conditions against rules. For MCP, the subject is the agent identity, the object is the data source or tool, the operation is the tool call with its arguments, and the environment can include session context.

With those attributes, policy can reject a call to a second customer data source from an agent scoped to the first. It can redact identifiers in a result so they cannot be used as arguments in the next call. It can send requests for bulk or sensitive records to a person for approval. Redacting join keys is often the most direct way to break the chain, because the second call has nothing to match on.

The limits matter. Enforcement on individual calls does not, by itself, reconstruct what the agent has combined across a session, and it does not replace the structural controls above. Policy that tracks session history can narrow the gap, but design on the assumption that the allowlist and credential scoping do the primary work.

Trussed enforces policy in the execution path across agents, tools, and MCP servers, with allow, redact, block, rate limit, and escalate for human approval outcomes. Its scope is individual interactions and tool calls. It does not provide transaction-level governance or end-to-end tracing of agentic workflows, so those needs call for separate design.

Governance and audit considerations

The NIST AI RMF describes a secure AI system as one whose protection mechanisms prevent unauthorized access and use. Per-agent allowlists, scoped credentials, and per-call decisions give you concrete mechanisms to point to under that characteristic. Agent telemetry also matters, since guidance on agentic security says agents should not run without it and that unexpected tool use should be monitored.

Versioned policy supports the same goal. Data access policy is the starting point for authorizing access to a resource, so keeping policy documented and versioned lets you show what an agent was permitted to reach at a given time. Treat HIPAA and GDPR obligations as questions for your compliance and legal teams. The technical record should give them the facts they need.

Trussed generates audit-ready evidence as a product of enforcement, mapped to HIPAA, NAIC, NYDFS, EU AI Act, and NIST, so the record comes from the decision itself and not from a separate reconstruction. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.