Skip to main content
Mindset AI has zero direct access to your Snowflake instance. Every interaction goes through MCP servers — either custom servers your team builds and hosts, or Snowflake’s own managed MCP server. Mindset AI never stores Snowflake credentials; for custom MCP servers, credentials stay in your infrastructure; for Snowflake-native MCP, credential management is handled by a dedicated integration partner. Your existing Snowflake governance (RBAC, column masking) applies unchanged. Tenant isolation is enforced at the request level on every call. Mindset AI is SOC 2 Type II certified, GDPR and EU AI Act compliant, with regional deployment options.

​
The fundamental security boundary

The single most important thing to understand: Mindset AI never connects to Snowflake. There is no Snowflake connection string in the Mindset AI platform. No Snowflake credentials. No JDBC/ODBC drivers. No direct queries. For custom MCP servers: the Mindset AI platform calls your MCP servers over JSON-RPC, and your MCP servers call Snowflake. These are two completely separate connections with a security boundary between them. For Snowflake-native MCP: Mindset AI calls Snowflake’s managed MCP server, with authentication handled by a dedicated integration partner. Mindset AI never holds Snowflake credentials — the integration partner manages the OAuth token lifecycle. This means:
  • Mindset AI cannot query tables it doesn’t know about. It can only call the MCP tools you’ve registered with the parameters you’ve defined.
  • Mindset AI cannot access data beyond what your MCP server returns. If your MCP server filters results to 10 rows, Mindset AI sees 10 rows.
  • Mindset AI cannot run arbitrary SQL. It sends structured parameters and either your code or Snowflake’s managed server translates those into queries.
  • If your MCP server goes down, Mindset AI has no fallback access to your data. The agent reports that the tool is unavailable.

​
What Mindset AI sees vs what stays in your infrastructure

​
Stays in your infrastructure (Mindset AI never sees this)

  • Snowflake connection strings and credentials
  • Raw SQL queries executed against your warehouse
  • Snowflake table schemas, column names, and database structure
  • Unfiltered query results before your MCP server applies scoping
  • Snowflake RBAC configuration, role definitions, and security policies
  • Your MCP server source code and internal API logic
  • Data that your MCP server filters out before returning results

​
Passes through Mindset AI

  • Structured parameters sent to your MCP tools (e.g. { region: "EMEA", min_revenue: 50000 })
  • Structured JSON results returned by your MCP servers (the filtered, scoped data your code decides to expose)
  • Tenant ID and user context passed via the Context API
  • Tool definitions (what each MCP tool does, its parameters, its response shape)
  • Conversational context (what the user asked, session history)

​
Mindset AI stores

  • Session transcripts (conversation history per user, per tenant)
  • Tool call logs (which tools were called, with what parameters, response times)
  • Agent configuration (system prompts, tool descriptions, guardrails)
  • Usage and cost metrics (per tenant, per agent, per tool call)
All stored data is subject to regional deployment constraints (EU or US), retention policies, and compliance requirements (GDPR, EU AI Act, CCPA).

​
How your Snowflake security controls apply

​
Role-based access control (RBAC)

Your MCP servers connect to Snowflake using roles you define. You control which Snowflake role each MCP server uses, which tables and views that role can access, and what operations it can perform. Mindset AI has no influence over this — it’s entirely within your Snowflake configuration.
RBAC operates at the role level, not the user level. For Snowflake-native MCP, all requests authenticate as the same Snowflake role. For custom MCP servers, the server connects using a role you configure. See Access control: roles vs users for how to handle per-user scoping.

​
Row-level security

If you’ve configured Snowflake row-level security policies, they apply based on the role the connection authenticates as. For custom MCP servers, your code can also set session variables that RLS policies reference, giving you per-tenant or per-user filtering within a single role. For Snowflake-native MCP, RLS applies to the authenticated role only — there is no custom code layer to set session context.

​
Column masking

Dynamic data masking policies in Snowflake apply at query time. If you’ve masked sensitive columns (SSNs, email addresses, financial data), the masked values are what your MCP server receives, which means masked values are what Mindset AI sees. There’s no way for Mindset AI to access unmasked data.

​
Network policies

Your Snowflake instance’s network policies (IP allowlisting, private connectivity via AWS PrivateLink or Azure Private Link) apply to the connection from your MCP servers to Snowflake. Since Mindset AI never connects to Snowflake directly, your network policies don’t need to account for Mindset AI infrastructure at all.

​
Tenant isolation in detail

​
At the Mindset AI platform layer

  • Every request from a user carries a tenant ID attached via the Context API. This is not optional, not inferred, and not stored globally.
  • Agent sessions are isolated per tenant. Conversation history, memory, tool call logs, and context are partitioned. One tenant’s session cannot access another tenant’s data or conversation state.
  • The LLM context window for a given session only contains data from that tenant’s interactions.

​
At the MCP server layer

Custom MCP servers (Path B): Your MCP server receives the tenant ID as a header on every call. Options include:
  • Application-level WHERE clauses: Your MCP server adds WHERE tenant_id = :tenant_id to every query.
  • Session variables for RLS: Your MCP server sets a Snowflake session variable, and row-level security policies reference it.
  • Separate schemas per tenant: Your MCP server routes to the correct schema based on the tenant ID.
  • Both: Most teams use application-level scoping for fine-grained control, with Snowflake row-level security as a safety net.
Snowflake-native MCP (Path A): There is no custom code layer to read headers or set session variables. Tenant scoping is determined entirely by the Snowflake role the connection authenticates as.

​
At the Snowflake layer

Whatever tenant isolation you’ve already configured in Snowflake applies unchanged. Mindset AI does not bypass, override, or replicate your security policies.

​
Data in transit and at rest

In transit: All communication between Mindset AI and your MCP servers is encrypted via TLS 1.2+. User-facing communication is encrypted via HTTPS. At rest: Data stored in the Mindset AI platform is encrypted at rest using AES-256. No Snowflake data is cached in the Mindset AI platform beyond what’s needed for the active session.

​
Compliance and certifications

ISO 27001 certified. Independently audited controls covering security, availability, processing integrity, confidentiality, and privacy. GDPR. Data processing agreements available. Right to erasure supported — session data and tool call logs can be deleted per tenant on request. Regional deployment ensures data stays in the EU when required. EU AI Act. Transparency requirements met. Agent behaviour is auditable — every tool call, every parameter, every response is logged and traceable. CCPA. Consumer data rights supported. Data portability and deletion requests can be fulfilled at the tenant level. Regional deployment. EU or US deployment available. When you choose EU deployment, all Mindset AI platform data stays in EU infrastructure.

​
Common security questions

No. Mindset AI can only call the MCP tools you’ve registered. It has no connection to Snowflake and no mechanism to discover or access data beyond what your MCP servers return.
This is a bug in your code, not in Mindset AI. Defence in depth is recommended: use Snowflake row-level security as a safety net in addition to application-level scoping in your MCP servers.
No. Mindset AI communicates with MCP servers over JSON-RPC. It sends structured parameters and receives structured results. It has no access to your server’s environment variables, configuration files, or source code.
Session transcripts, tool call logs, and usage metrics. Raw Snowflake query results are not retained beyond the active session.
Yes. Every tool call is logged with full parameters, tenant context, timestamps, and response metadata. You can also audit from the Snowflake side — all queries appear in your Snowflake audit trail under the roles your MCP servers use.
Deregister the MCP tool from the agent configuration and the agent can no longer call it. For custom MCP servers, shut down the server. Rotate Snowflake credentials and your MCP server reconnects with new credentials — Mindset AI is unaffected because it never had the credentials.