> For the complete documentation index, see [llms.txt](https://help.daasity.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.daasity.com/core-concepts/ai-analyst/connect-your-ai-mcp/mcp-connection-security.md). # MCP Connection Security This page explains how the Daasity MCP connection works from a security standpoint. It is written to be shared directly with an IT or security reviewer. {% hint style="info" %} **Summary.** The connection is read-only, scoped to a single Daasity workspace, and limited to two operations: listing the governed data views available to that workspace, and running a read query against them. It cannot write, modify, or delete anything. It cannot reach any other customer's data. The connecting AI is directed to the governed views and curated data models, and is required to label any answer that came from anywhere else. It can be revoked instantly by anyone with access to the Daasity workspace, and no software has to be installed on a managed device for it to work. {% endhint %} ### Two separate decisions These are often reviewed as one thing, and separating them usually shortens the review: 1. **Whether to allow the Daasity connection.** This is what the rest of this page describes — a read-only query interface into data your business already owns and already accesses through Daasity. 2. **Whether to allow a particular AI tool on a managed device.** This is a separate policy question about endpoint software. The connection works through the browser — Claude on the web supports custom connectors with nothing installed locally — so approving the connection does not require approving a desktop or terminal install. ### Authentication Connections are established through OAuth, per person. Each user authorizes under their own Daasity identity. There is no shared account, no shared password, and no long-lived credential pasted into a configuration file. During authorization, Daasity displays exactly what is being granted before the user approves. Access to the feature is enabled per user by Daasity rather than being self-service, so a user cannot grant themselves a connection. Where your organization uses SSO, your identity provider governs the Daasity login underneath. On AI platforms that offer team or enterprise plans, an account owner typically adds the connector at the organization level before any individual can use it, which places the decision with an administrator rather than with each employee. ### What the connection can do The interface exposes two operations and nothing else: * List the governed views available to the workspace * Run a read query against them There is no write, update, delete, schema-change, or administrative capability. It was not built with one. Statements other than read queries are rejected before execution. ### What it is directed to Queries resolve against **governed views** — a curated layer carrying your organization's own order-validity logic, timezone handling, and metric definitions. Where a question cannot be answered from a view, the connecting AI may fall back to SQL. It is given an explicit list of your curated data models and instructed to stay within it. Raw third-party connector data (your Shopify, Amazon, or ad-platform extracts), warehouse system schemas, and raw landing areas are outside that list. When a fallback answer is returned, the AI is required to label it so the reader knows it bypassed the curated definitions. ### Isolation A connection only ever resolves to the workspace that authorized it. It cannot see another tenant's data. Everyone on a connection queries the same modeled, permissioned dataset the workspace already governs — connecting an AI tool does not create a path around existing Daasity permissions. ### Lifetime, limits, and revocation A connection expires after 30 days without use. Each connection is capped on request rate, daily query volume, rows returned, and total data scanned, so automated or runaway usage is capped rather than open-ended. Every connection is listed in Daasity with its status, when it was added, when it was last used, and when it expires. Disconnecting revokes access immediately, without involving Daasity support. ### Where query results go Stating this plainly, because it is usually the real question: query results are returned into the conversation inside the AI tool your organization has chosen. What happens to them after that is governed by your own agreement with that vendor — its retention terms, its policy on using business data for model training, and whatever administrative controls you have configured on your plan. Daasity provides the read-only connection and the governed views behind it. The AI vendor's terms govern what happens downstream. Those terms are published by the vendor and should be reviewed directly rather than taken second-hand from us. In practice, most organizations resolve this by pointing the connector at a business or enterprise plan they administer rather than at personal accounts, which puts retention and training settings under their own control. ### What your organization controls * **Who has access** — through Daasity provisioning and your SSO * **Which AI tool**, and which workspace it runs in * **Immediate revocation** of any connection, at any time, without involving Daasity ### Requesting additional documentation For security questionnaires, compliance documentation, or a review with our team, contact your Daasity account manager or . We respond to these directly rather than publishing infrastructure detail here.