> 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 that workspace's data. It cannot write, modify, or delete anything. It cannot reach any other customer's data. The connecting AI answers from governed views first and is instructed to label any answer that came from anywhere else. Customer-identifying fields are withheld from every result. The connection 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 Most AI tools connect through OAuth, per person. Each user authorizes under their own Daasity identity. There is no shared account, no shared password, and no credential copied into a configuration file. During authorization, Daasity displays exactly what is being granted before the user approves. For tools that don't support this sign-in flow, such as Gemini CLI, a user can generate a manual token from the Connect Your AI page instead. A manual token is shown once, when it is created, and Daasity stores it only in a form that can't be read back. It expires after 30 days without use and can be revoked instantly, like any other connection. Treat a manual token like a password: anyone who has it can query the workspace's data until it expires or is revoked, so never paste one into a support message, shared document, or code repository. 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 the workspace's data 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: first against your curated data models, and only if those can't answer, against the raw data your connectors extract (your Shopify, Amazon, or ad-platform extracts). The AI is instructed to label any fallback answer with the table it came from, so the reader knows it bypassed the curated definitions and should be reconciled against your dashboards. If you'd prefer the connection to answer from governed views only, Daasity can restrict your workspace to them. Contact your account manager or . ### Customer-identifying information Names, email addresses, phone numbers, street addresses, and IP addresses are withheld from every query, whichever table it reads. Daasity's servers withhold them before results are returned, so this protection does not depend on the AI following instructions. When a field is withheld, the response lists it. Order-level data such as order IDs, amounts, products, and city, state, and ZIP remains available for analysis. ### Isolation A connection only ever resolves to the workspace that authorized it. It cannot see another tenant's data. Everyone connected to a workspace queries the same dataset. Row-level restrictions set up for individual users in dashboards do not carry over to the connection. ### 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.