Atlan MCP security
The Atlan MCP server is secure by design: it runs as a per-tenant hosted instance, reuses the exact authentication and authorization policies already configured in your Atlan workspace, and never exposes metadata that the connected user or service identity isn't already permitted to access. It doesn't send your data to any LLM and doesn't reimplement its own access control—every tool call is scoped to the requesting identity's existing Atlan permissions.
This page covers the security of the Atlan MCP server specifically. For platform-wide AI security (encryption standards, compliance certifications, data residency), see Atlan AI security.
Deployment and isolation
The Atlan MCP server runs as a dedicated, per-tenant hosted instance with no shared state between tenants—one tenant's requests, metadata, and tool calls are never visible to another.
How's Atlan MCP server deployed?
The Atlan MCP server is deployed as a hosted, per-tenant Remote MCP server at mcp.atlan.com/mcp. Each tenant has its own dedicated instance with no shared state, so one tenant's requests, metadata, and tool calls are never visible to another tenant. It runs on the same trust root as your Atlan instance rather than introducing a separate identity system.
Authentication
Authentication is required on every tool call and is anchored to Atlan's existing identity system—no new credentials or separate identity layer is introduced.
How does Atlan MCP server authenticate users?
The Atlan MCP server authenticates clients in one of two ways: OAuth per-user authentication, where every call runs as the signed-in user, or API token / service-account authentication, where the agent acts as a service identity for automation. Both modes use Atlan's existing identity controls, and authentication is required on every method except the initial initialize handshake.
Does Atlan MCP support OAuth?
Yes. The Atlan Remote MCP server supports OAuth per-user authentication, so each MCP tool call executes with the signed-in user's identity and Atlan permissions. OAuth uses the same trust root and signing keys as Atlan's REST API, so MCP doesn't widen your authentication surface.
How are OAuth tokens validated?
For OAuth tokens, the Atlan MCP server validates the token's signature, issuer, expiry, not-before, and issued-at claims using the Keycloak JWKS endpoint and your Atlan realm configuration. API token validation is delegated to Atlan's existing token validation.
Authorization and permissions
The MCP server doesn't reimplement access control. It forwards the authenticated identity to Atlan, where the same persona, role, and domain policies that govern the UI apply to every tool call.
How does Atlan MCP server enforce permissions?
The Atlan MCP server doesn't reimplement access control. It forwards the authenticated identity to downstream Atlan services, which enforce the same persona, role, and domain policies that govern the Atlan UI. Users can only search, view, or update the metadata they're already authorized to access, and a user must hold the relevant permission (such as edit metadata) for a tool to act on their behalf.
How are service account permissions scoped?
For service-account API tokens, the Atlan MCP server requires exactly one persona attached to the token, which is injected as the scope and filter for that identity. Tokens with multiple personas are rejected, ensuring service identities operate within a single, well-defined permission scope.
Tool controls
Tool exposure is managed per-tenant with fail-closed allowlisting, and an optional read-only mode is available for agents that only need to query and explore metadata.
Can I limit which MCP tools are available?
Yes. Tool exposure is controlled by per-tenant allowlisting, and the check is fail-closed—if the allowlist check fails, the tool isn't exposed. Tools also carry accurate readOnlyHint and destructiveHint annotations so clients and policies can reason about their effect.
Does Atlan MCP support read-only mode?
Yes. By default the Remote MCP server exposes both read and write tools. Customers can request read-only mode, which disables all write, admin, and lifecycle tools while keeping search and lineage tools available—useful for internal agents that only need to query and explore metadata without risking unintended changes.
To enable read-only mode:
- Submit a support ticket with your request.
- Once configured by Atlan, the following tools remain active:
- Search & discovery: query and filter assets
- Lineage & exploration: traverse metadata relationships
Who controls access to Atlan MCP capabilities?
Atlan admins control which users or groups can access MCP capabilities, including which MCP tools are available within conversational AI. Enablement follows the same admin-approval model as other Atlan AI capabilities.
Data handling
No customer data is sent to external LLMs. The MCP server processes only permission-scoped metadata, retrieved in real time from Atlan's REST APIs with no intermediate caching.
Does Atlan MCP send data to external LLMs?
No. The Atlan MCP server doesn't send your underlying data to any LLM. It processes only permission-scoped metadata—such as asset, schema, and glossary names and descriptions, and lineage relationships—and that metadata is always constrained by the requesting identity's Atlan permissions.
Does Atlan MCP cache metadata?
No. The Atlan MCP server acts as a bridge to Atlan's REST APIs—the same APIs powering the Atlan SDK and user interface. Metadata is retrieved in real time with no intermediate caching, so results always reflect the exact state of your catalog at that moment and stay consistent with what you see in the UI and SDK.
Does Atlan MCP usage train AI models?
No. Metadata, prompts, and outputs processed through the Atlan MCP server aren't used by Atlan or its AI providers to fine-tune or train foundation models.
Logging and audit
Every tool call is logged as a structured event. Arguments and responses are redacted before logging to prevent sensitive data from appearing in logs or metrics.
Does Atlan MCP server log tool calls?
Yes. The Atlan MCP server logs every tool call as a structured event including the tool name, MCP client name and version, model identifier (if supplied), tenant, request ID, duration, success or error status, optional rationale, and the originating user query when present. Authentication failures, persona-resolution errors, and tool-access denials are also logged with their reasons.
Are tool arguments and responses logged in full?
No. Tool arguments and responses aren't logged verbatim—they pass through a redactor that masks sensitive fields before any logging. The same redaction is applied to the Prometheus metrics and Braintrust traces the MCP server emits.
Where do metadata changes appear?
Metadata-changing operations performed through the Atlan MCP server appear in the affected asset's activity history, consistent with other changes made in Atlan. Log retention follows Atlan's central observability pipeline rather than a separate MCP retention setting.
Input validation
All tool inputs are validated server-side before execution. Malformed inputs are rejected with structured errors rather than exposing raw exceptions.
How does Atlan MCP server validate tool inputs?
The Atlan MCP server performs server-side input validation using typed annotations and Pydantic v2 before any tool executes. Malformed inputs are rejected with structured errors, and tool-boundary exceptions are caught and returned as structured failures rather than raw errors.
Can Atlan MCP server run arbitrary SQL?
No. Tools that execute SQL route untrusted SQL through a read-only validator that blocks DDL and DML statements and permits only SELECT-class queries, preventing MCP-driven SQL from modifying data.
Network security
All traffic is encrypted in transit with TLS 1.2 or higher, and tenant environments connect to Atlan's AI infrastructure over private network boundaries.
How's Atlan MCP traffic secured?
Traffic between tenant environments and Atlan's AI infrastructure uses PrivateLink and VPC peering to stay within private network boundaries, and all communication is encrypted in transit with TLS 1.2 or higher.
Can I restrict Atlan MCP access by source IP?
Yes, but source-IP restrictions are enforced at the Atlan Kong gateway or within your own egress/network layer, not inside the MCP server. The MCP server reads forwarded IP headers only to enrich logs and never to make access decisions.
Controls inherited from Atlan AI security
The following controls apply to the Atlan MCP server but are shared across all Atlan AI capabilities.
- Encryption: TLS 1.2+ in transit, AES-256 at rest, with Customer Managed Encryption Keys (CMEK) for tenant-level data.
- Data residency: Tenant data is processed and stored in the region closest to the tenant (United States, EU, or APAC), supporting GDPR, CCPA/CPRA, and other residency requirements.
- Compliance: Covered by Atlan's HIPAA, GDPR, and CCPA/CPRA programs. See the Atlan Trust Portal for certifications and audit reports.
- Gateway protections: Rate limits, concurrency controls, request/response size limits, and prompt-injection and PII guardrails are enforced at the Atlan AI gateway for defense in depth.
See also
- Atlan AI security: platform-wide AI security controls, encryption standards, compliance certifications, and data residency.
- What is Atlan AI?: overview of Atlan's AI capabilities and how the MCP server fits into the platform.