Qlik MCP Server - Security Architecture and Controls
Executive Summary
Qlik's MCP server enables third-party MCP clients — such as Claude Desktop/Cowork/Code, VS Code + GitHub Copilot, Cursor, or ChatGPT — to query Qlik Cloud data using the user's own credentials and permissions.
This document clarifies:
- Authentication is OAuth 2.0 — the MCP server never accepts unauthenticated connections; all requests are bound to a verified Qlik user identity.
- Data access is governed by Qlik's Section Access controls — applied at the account level, users can only retrieve data they are already authorized to see.
- Semantic search uses pre-built vector embeddings — generated via Amazon Bedrock; the same AWS security controls described in the parent document apply at embedding build time.
- At query time, the user's search term is sent to Bedrock to generate a query embedding — AWS cross-region security controls apply to this call; only the search term crosses regions, not the underlying app data.
- Data returned to the user's LLM client is governed by that client's policies — once data leaves the Qlik MCP server boundary, Qlik's controls no longer apply.
Key Insight: Qlik's MCP server functions as a governed data access layer, not an AI inference layer. Qlik controls identity, entitlements, and what data is made accessible. The user's choice of LLM client determines what happens to that data thereafter.
Architecture Overview: MCP Data Flow
How MCP Differs from Qlik Answers
Qlik Answers is a closed-loop AI pipeline: data flows from Qlik Cloud to Amazon Bedrock for inference and back, entirely within AWS infrastructure.
Qlik MCP is an open interface: Qlik Cloud exposes governed data access to an external MCP client chosen by the user. Qlik controls the right side of this architecture; the user's LLM provider controls the left.
Qlik's Trust Boundary
| 🔵 MCP Client (User's LLM) | 🟢 Qlik MCP Server |
|---|---|
| ChatGPT, Claude, Copilot, etc. | ✅ Identity verification |
| ⚠️ Governed by LLM provider's policies | ✅ Section Access enforced |
| Receives data scoped to entitlements | ✅ Data scoped to user |
All connections authenticated via OAuth 2.0. Data is returned to the MCP client scoped to the user's existing entitlements — nothing more.
Outside Qlik's Control
Once data is returned to the MCP client, it enters the LLM provider's environment — including ChatGPT (OpenAI), Claude (Anthropic), Gemini (Google), Cursor, or others. Data handling at this stage is governed entirely by that provider's policies. No contractual relationship exists between Qlik and the LLM provider.
Semantic Search: Embedding Generation vs. Query Time
Qlik's semantic search capability relies on vector embeddings. Understanding when Bedrock is involved is important for a complete security assessment.
Embedding Build Time — Offline, not triggered by MCP queries
Qlik Cloud ——► [AWS Private Network]——► Amazon Bedrock
- Bedrock generates vector embeddings from app content
- AWS cross-region security controls apply (see parent document)
- Ephemeral, in-memory processing; no content logging
- Embeddings stored in Qlik Cloud (home tenant region)
Query Time — Triggered by MCP client request
MCP Client → [OAuth] → Qlik MCP Server → Bedrock (query embedding) → Vector Index
- The user's search term is sent to Bedrock to generate a query embedding using the same model that built the index
- AWS cross-region security controls apply to this call (see parent document)
- Only the search term crosses regions — not the underlying app data
- The query embedding is matched against the pre-built index; results are scoped to the user's Section Access entitlements
- Results are returned to the MCP client (external LLM)
Common Misconceptions vs. Reality
| Misconception | Reality |
|---|---|
Anyone can query Qlik data via MCP |
❌ False. All MCP connections require OAuth 2.0 authentication. Unauthenticated requests are rejected. |
MCP bypasses Qlik's data access controls |
❌ False. Section Access is enforced at the account level. Users retrieve only data they are authorized to see — identical to their Qlik Cloud access. |
MCP sends app data to Bedrock during queries |
⚠️ Partial. Bedrock is called at query time to generate an embedding of the user's search term. The same AWS security controls apply. However, underlying app data is never sent to Bedrock during a query; only the search term crosses regions. |
Qlik controls what the external LLM does with the data |
❌ False. Once data is sent to the user's MCP client, it is governed by the user's chosen LLM provider's policies — it is equivalent to a data export. |
The same AWS security guarantee applies end-to-end |
⚠️ Partial. AWS security controls apply to embedding generation and data at rest in Qlik Cloud. They do not extend to the external LLM client or its infrastructure. |
Security Controls Deep Dive
1. Authentication — OAuth 2.0
All MCP connections require OAuth 2.0 authorization:
- User-bound tokens — access tokens are tied to a specific Qlik user identity; no service account or shared credentials
- Scoped permissions — OAuth scopes restrict what operations the MCP client can perform
- Token expiry and rotation — short-lived tokens reduce the window for credential misuse
- No static API keys — eliminates long-lived credential risks associated with API key models
Implication: A compromised or malicious MCP client can only access data that the authenticated user is authorized to see. There is no privilege escalation path via MCP.
2. Data Entitlements — Section Access
Section Access is Qlik's row- and field-level security framework, enforced at the user account level:
- Applied before data is returned — MCP queries are subject to the same Section Access rules as any other Qlik interaction; no bypass mechanism exists
- Account-level enforcement — not a client-side filter; enforcement occurs server-side within Qlik Cloud before data leaves the platform
- Consistent with existing Qlik access — a user accessing Qlik via MCP sees exactly the same data they would see in the Qlik Cloud browser interface; nothing more
Implication: The MCP server cannot expose data beyond what the user is already entitled to access within Qlik Cloud.
3. Semantic Search — Embedding Security
Bedrock is involved at two stages of semantic search: embedding build time and query time. The full set of AWS security controls described in the parent document applies to both.
- AWS private backbone — traffic never traverses the public internet at either stage
- TLS 1.3 encryption in transit; AES-256 at rest
- Ephemeral in-memory processing — neither source data nor search terms are persisted in the inference region
- No content logging — Bedrock logs metadata (timestamps, token counts) only; app data content and search terms are never logged
- No model training — contractually guaranteed via AWS Data Processing Agreement
At query time, the user's prompt is sent through the MCP server to the Qlik semantic search APIs, and the search term is sent to Bedrock to generate a query embedding using the same model that built the index.
4. The External LLM Boundary
This is the architectural difference that distinguishes MCP from Qlik Answers and warrants explicit acknowledgment in any security assessment.
What Qlik Controls
| Control | Coverage |
|---|---|
| User authentication | ✅ OAuth 2.0 — all requests |
| Data access entitlements | ✅ Section Access — enforced server-side |
| Data in transit (Qlik → MCP client) | ✅ TLS encryption |
| Embedding generation security | ✅ AWS / Bedrock controls |
| Content logging within Qlik | ✅ No content logged |
What Qlik Does Not Control
| Factor | Responsibility |
|---|---|
| LLM provider's data handling policies | User's chosen LLM provider |
| Whether the LLM provider logs request content | User's chosen LLM provider |
| Whether the LLM provider uses data for model training | User's chosen LLM provider |
| Data sovereignty once data reaches the LLM provider | User's chosen LLM provider |
Analogy: This is equivalent to a user exporting a data extract from Qlik Cloud and uploading it to an external AI tool. Qlik governs what data they are permitted to export (Section Access); the user and their chosen tool's provider govern what happens next.
Enterprises wishing to control which LLM clients their users may connect to Qlik via MCP should address this through internal AI usage policies, LLM provider vetting, and endpoint controls — in the same way they would govern other data export or third-party AI tool usage.
What Gets Stored Where
| Data Type | Qlik Cloud (Home Region) | MCP Client / External LLM | Persistence |
|---|---|---|---|
| Raw application data | ✅ Stored in Qlik Cloud | ❌ Not stored by Qlik | Permanent in home region |
| Vector embeddings | ✅ Stored for semantic search | ❌ Not stored by Qlik | Permanent in home region |
| MCP query results (data values, measures) | ✅ Transient during API response | ⚠️ Governed by LLM provider policy | Qlik: session-based only |
| Embedding generation data (Bedrock) | ✅ Source in home region | N/A | Ephemeral in Bedrock |
| OAuth tokens | ✅ Managed per session | ⚠️ Stored in MCP client | Token lifetime only |
| Metadata logs (timestamps, token counts) | ✅ Standard audit logs | ⚠️ LLM provider policy | Per Qlik retention policy |
| Content logs | ❌ Not logged by Qlik | ⚠️ LLM provider policy | N/A for Qlik |
Risk Comparison: Qlik Answers vs. Qlik MCP
| Risk Factor | Qlik Answers | Qlik MCP |
|---|---|---|
| Data stays within AWS | ✅ Yes — end-to-end | ⚠️ Partial — Qlik-side only; external LLM is outside AWS |
| Single compliance framework | ✅ AWS throughout | ⚠️ AWS for Qlik-side; LLM provider's framework applies thereafter |
| No model training on data | ✅ Bedrock guarantee | ✅ Bedrock guarantee for embeddings; ⚠️ LLM provider governs query-time data |
| Content logging | ✅ Bedrock: metadata only | ✅ Qlik: metadata only; ⚠️ LLM provider policy applies for query content |
| User authentication | ✅ Qlik session | ✅ OAuth 2.0 |
| Data access entitlements | ✅ Section Access | ✅ Section Access |
| Live cross-region inference | ✅ AWS private backbone | ✅ AWS private backbone (search term only at query time) |
| Audit trail | ✅ AWS CloudTrail + Qlik logs | ✅ Qlik logs; ⚠️ LLM provider audit trail separate |
Summary and Recommendations
Key Takeaways
Strong access controls at the boundary. OAuth 2.0 authentication and Section Access enforcement ensure that the Qlik MCP server cannot expose data beyond a user's existing entitlements.
Bedrock involvement is limited and controlled. MCP semantic search generates a query embedding at query time using the same AWS security controls that apply at embedding build time. Only the search term is sent to Bedrock — not underlying app data.
Honest boundary acknowledgment. Once data is returned to the user's LLM client, Qlik's controls end. This is architecturally equivalent to data export and should be treated as such in risk assessments.
Organizational controls are the appropriate mitigation. Qlik cannot — and should not — restrict which LLM providers users may connect to via MCP. Enterprises should address external LLM risk through internal AI usage policies and approved provider lists.
For Security Assessments
| Disposition | Conditions |
|---|---|
| ✅ Accept this risk if... | Your organization permits users to access Qlik data via API or export mechanisms. You trust users to operate within acceptable LLM provider boundaries. Internal AI usage policies govern which LLM providers are approved for use with business data. |
| ⚠️ Mitigate this risk by... | Establishing and communicating an approved LLM provider list. Ensuring Section Access rules are correctly configured. Reviewing the data handling and training policies of likely LLM providers. Enabling audit logging within Qlik Cloud to monitor MCP tool usage patterns. |
| ❌ Reject this risk if... | Data sovereignty laws prohibit any transfer of data to non-approved infrastructure. Regulatory requirements mandate all AI processing occur within a specific compliance boundary. Your threat model cannot accept data leaving Qlik's AWS environment under any circumstances. |
Configuration option: Organizations may restrict or disable MCP server access at the tenant level. This prevents any external LLM connectivity while retaining full Qlik Answers and native AI functionality.
For background on the Model Context Protocol standard referenced in this document, see What is the Model Context Protocol (MCP)? and the MCP Architecture Overview.