> ## Documentation Index > Fetch the complete documentation index at: https://docs.traversal.com/llms.txt > Use this file to discover all available pages before exploring further. # MCP Servers — Security, Data & Permissions > How Traversal connects to a Model Context Protocol (MCP) server for data sources without a native integration — the data that flows, how it's secured, the authentication options, and the controls that keep access read-only and least-privilege. ## 1. How the integration works * For any data source Traversal doesn't have a native integration for, the Customer can connect it through a **[Model Context Protocol (MCP)](https://modelcontextprotocol.io/) server**. Traversal acts as an **MCP client** that calls the tools that server exposes during an investigation. * The **MCP server is owned and operated by the Customer** (or a third party the Customer explicitly chooses) — Traversal does not host it. The server sits in front of the Customer's data source and exposes a set of **tools**: named operations Traversal can call, each performing a specific action against that data source (for example, a *search logs* tool or a *get incident details* tool). * The Customer chooses which of the server's tools Traversal is allowed to call — its **enabled tools**. Traversal only ever calls a tool the Customer has explicitly enabled. * **Read-only by design:** Traversal is read-only and cannot modify the Customer's systems or data. If a server exposes any tool that writes or mutates state, the Customer adds it to the server's **blocked-tools list** so Traversal never calls it — enforced on Traversal's side, per server. * Each MCP server is configured as its own integration, with its own URL and credentials. * **Transport:** Traversal connects to the server over HTTP, using the standard MCP remote transports (Streamable HTTP and SSE). **Flow of a single tool call:** During an investigation, Traversal's agent chooses one of the Customer's enabled tools and calls it on the Customer's MCP server, authenticating with the credentials the Customer configured. The server runs that tool against the Customer's data source and returns the result to Traversal, which uses it as evidence in the investigation. Traversal only reads data this way — it never calls a tool the Customer hasn't enabled, and never a blocked tool. ## 2. What data we capture via MCP Traversal's access is defined entirely by the **tools the Customer enables** and by **what those tools return**. Traversal only receives what the Customer's MCP server returns in response to a tool call — it cannot reach anything the server doesn't expose as an enabled tool. * **Tool outputs** — the data an enabled tool returns when Traversal calls it (for example logs, records, metrics, or configuration, depending on the data source behind the server). * **Tool metadata** — the name, description, and input schema the server advertises for each tool. * **Connection metadata** — the server URL, which tools are enabled, and the per-call timeout. Traversal does **not** crawl, sync, or bulk-export the underlying data source. It only receives responses to **individual, on-demand tool calls** the agent makes during an active investigation. Two limits bound what can be connected: | Limit | Value | | ----------------- | -------------------------------------------------------------------- | | Enabled tools | Up to **20** enabled tools across all connected MCP servers combined | | Tool call timeout | Default **30 seconds** per call (configurable per server) | ## 3. PII / user information & handling * **What user info is involved:** this depends entirely on the tools the Customer enables and on what the underlying data source contains. **The Customer controls the scope** — by choosing which tools to enable and by maintaining the blocked-tools list. * **Handling:** * **Strict tenant isolation** — data is scoped to the Customer's organization; cross-customer access is prevented by design. * **Read-only, least-privilege** — Traversal only calls the specific tools the Customer enables, and only ever reads; any tool that could write or change data can be blocked. * **Encrypted credentials** — the credentials the Customer provides for the MCP server are stored encrypted. * **In-context processing only** — data returned by MCP tools is used only in the Customer's own investigations. It is never shared across customers and never used to train models, improve models, or optimize the service. * **Third-party-hosted servers** — if the Customer connects a third-party-hosted MCP server, that provider receives the tool requests Traversal sends and returns the data. The Customer should evaluate it as an additional sub-processor. * **LLM processing** — running an investigation sends relevant context (including data returned by MCP tools) to Traversal's LLM sub-processors. This processing is in-context only and is not used to train or improve models. The current list of sub-processors is published in the [Traversal Trust Center](https://trust.traversal.com/). ## 4. Authentication & permissions Traversal supports three authentication methods for MCP servers — the Customer chooses the one their server uses when configuring the integration. **Traversal only holds the credentials the Customer provisions; the access those credentials grant is defined by the Customer's MCP server, not by Traversal.** | Method | How it works | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Bearer token** | A static token Traversal sends as `Authorization: Bearer ` on every request. Use for a long-lived API key or personal access token. | | **Client credentials** | OAuth 2.0 `client_credentials` grant. Traversal exchanges a service-account client ID and secret for a short-lived token before each session — **no long-lived bearer token is stored**, only the service-account credentials. | | **OAuth** | OAuth 2.0 authorization-code flow with **PKCE** (RFC 7636) and **Dynamic Client Registration** (RFC 7591). The Customer authorizes Traversal once, in a popup, at setup time. Access and refresh tokens are stored **encrypted** and refreshed automatically. | * **Least-privilege on the Customer's side:** scope the service account or token issued to Traversal to only what the enabled tools require. * **HTTPS required:** for the OAuth method, the authorization and token endpoints must use HTTPS. * **Private-network servers:** if the Customer's MCP server — or its OAuth token endpoint — isn't reachable from the public internet, Traversal routes requests through the Customer's **[Traversal Connector](/architecture/connector)**, the same relay used by other integrations. No inbound exposure of the server to the internet is required. ## 5. Security & compliance Traversal maintains a **SOC 2 Type II** attestation and aligns with **GDPR** and **HIPAA** requirements, and undergoes regular third-party penetration testing. Customer data is protected by strict tenant isolation and access controls. It is never shared across customers and never used to train models or improve the service — all processing is limited to the Customer's own investigations. Review Traversal's security documentation, request compliance reports (including the SOC 2 Type II report), and see the current list of sub-processors. For detailed security documentation or to discuss specific requirements, contact the Traversal security team at [security@traversal.com](mailto:security@traversal.com).