MCP Server Security Guidance¶
This page is security guidance for organizations that turn on the QIE MCP server. The MCP server lets an AI client act in QIE on a person's behalf, so it adds a new way to read and change the engine. Treat what follows as the minimum baseline.
The Inherent Risk¶
An AI client acts as the person who approved it. It has that person's zone permissions, limited to the access chosen on the approval page: read only, manage, or full. Anything the client does, that person could also do in the console.
Text that QIE returns to a client is data, but a model may treat it as instructions. A message, a log line, a script or an object name can carry such text. QIE labels every result as data and asks the person to confirm actions that cannot be undone, but neither control can stop a model that has been misled from asking for an ordinary change. A session with full access can change configuration, and a configuration change can send data anywhere a person with edit rights could, for example from a script that calls a web service. The guards against that are the client's own approval prompt, the MCP audit log and the revision history.
A compromised AI client is a compromised user. It holds the person's tokens and can answer confirmation questions itself. Install AI clients only from trusted sources, and revoke a client on the Model Context Protocol (MCP) page as soon as it is in doubt.
Supported Clients¶
QIE supports AI clients that run on the person's own computer, such as Claude Code or Codex. See Connecting an AI Assistant to QIE.
Cloud-hosted clients cannot sign in. These include the claude.ai and Claude Desktop custom connectors, MCP tunnels, and Cursor's web app and Cloud Agents. QIE returns a sign-in only to an address on the person's own computer, and these clients need an address on the vendor's own site. QIE refuses them for two reasons: the client's tokens would be held on the vendor's servers, and the connection into QIE would come from the vendor's cloud through a firewall opening or a tunnel.
Supporting only clients on the person's computer does not keep message content away from the AI vendor. A client on a workstation sends tool results to its model provider too.
Message Content¶
Return message content on the Model Context Protocol (MCP) page is off by default. While it is off, the MCP server returns no message bodies, log text, cache values or sample messages, and a message search can use only the queue, the date range and message ids. While it is on, a user sees through the MCP what they could see in the console, and every body, log text and cache value read is written to the MCP audit log. See Message Content and the MCP.
An AI client keeps the tool results it receives, message content included, in its own session files on the person's computer. Treat a workstation that runs an AI client against QIE as a computer that may hold patient data, and protect it accordingly.
Reports to Qvera¶
A person can send a report about an MCP session to Qvera support through the send_report tool, to help Qvera improve how AI clients work with QIE. The report holds the model's account of the session, the person's comment, name and reply email if they give them, this engine's name, version and build, and the session's MCP audit entries with message content left out, as the audit log export leaves it out. The model is asked to replace patient details with placeholders, and QIE cannot check that it did; a client that can show a form shows the person the exact text before anything is sent. QIE sends a report to qvera.com over HTTPS only, never over plain HTTP, so a report is not sent when no HTTPS address can be reached. Turn Allow reports to Qvera off on the Model Context Protocol (MCP) page if your organization does not allow diagnostics to leave the engine. Every report sent is recorded in the MCP audit log. See Sending a report to Qvera.
Access and Sign-In¶
The approval page offers read-only access by default. Grant the narrowest access the work needs, and full access only for changing configuration.
An access token lasts one hour by default (Access Token Lifetime (seconds)). A refresh token keeps a client signed in for up to 30 days for a user whose password QIE checks, and up to one day for a user checked by LDAP or an OIDC provider, because QIE cannot check the directory again when a client renews its token. A refresh token renews access without two-factor authentication for as long as it lasts. Turn Issue refresh tokens off, or choose Do not keep me signed in on the approval page, to require a new sign-in each time the access token expires.
A sign-in returns only to an address on the person's own computer, and the client must prove it started the sign-in, so an authorization code caught by another program is useless. QIE refuses to authorize MCP access through the QIE Hub or from the QIE server itself (see MCP Client Sign-In). An AI assistant can work at an engine through the Hub only by signing in at the Hub's own MCP server (see Calls Through the Remote Management Hub).
Disabling, deleting or locking out a user, or changing their password, revokes all of that user's MCP tokens. An administrator can revoke one sign-in, one client or every sign-in on the Model Context Protocol (MCP) page. Click Revoke All after restoring the database from a backup, because a restore brings back tokens that were revoked after the backup was taken.
QIE stores only a hash of each token. Access tokens start with qma_ and refresh tokens with qmr_, so a secret scanner can find one that leaked into a file or a repository.
Calls Through the Remote Management Hub¶
An engine can also take MCP calls from AI assistants signed in at its Remote Management Hub (see MCP Calls Through the Hub). This is a second way into the engine, beside its own MCP server. It stays off until an administrator turns on both Use Hub and Accept MCP calls through the Hub, on the Hub Sign-In tab of the Remote Management Hub dialog in System Configuration. It does not need the engine's own MCP server. Turn it on only where the engine is meant to be worked on from the Hub.
- Trust in the Hub: The engine runs a call because the Hub signed a statement for it. Whoever controls the Hub, or holds its signing key, can sign a statement that names any person and any Hub role, and so gets whatever the engine's Role Map gives the Hub roles it maps. Protect the Hub as Hub Host Security Guidance describes, and map each Hub role to the narrowest engine role the work needs.
- What a call cannot change: No call through the Hub itself changes users, roles, permissions or other administrator settings, whatever role the person maps to (see What Is Refused Through the Hub). That covers the call's own work, not the scripts of a channel it starts or changes, which run as any channel's scripts do.
- Message content: While Return message content is on, the content a tool returns passes through the Hub on its way to the AI assistant.
- No sign-in at the engine: The person approves their AI assistant at the Hub, so the engine holds no token for it. The engine refuses to authorize MCP access for a Hub user, and refuses any token one holds. Revoking sign-ins on the engine's MCP page does not stop calls through the Hub; turn the switch off, or disable the person's Hub user.
- Records at both ends: The engine records each call in its MCP audit log with the statement's id, and keeps the statement itself. The Hub records the same call in its own MCP audit log (see The MCP Server on a Hub).
Confirmations¶
Actions that cannot be undone ask the person to confirm in their AI client: deleting or purging, discarding errors, importing configuration, resubmitting edited or many messages, creating a user, changing a password, permissions or the administrator flag, and the others listed in MCP Tool Results and Errors. While Require client confirmation is on, which is the default, QIE refuses these actions to a client that cannot ask its user. Leave it on.
Network Segmentation¶
The MCP server uses two ports. Clients sign in through the console port and call tools on the MCP port, both over HTTPS only.
| Port | Who connects | Over | What for |
|---|---|---|---|
| MCP Port | MCP clients | HTTPS | Tool calls, and the protected resource document |
| Console port | The person's browser | HTTPS | Sign-in and approval |
| Console port | MCP clients | HTTPS | Registration, tokens and revocation |
| 443, or the port a Metadata Document Hosts entry names, outbound from the engine | Hosts on Metadata Document Hosts | HTTPS | Client metadata documents, only while that list holds a host |
- Open the MCP port only to the workstations that need it, not to the whole network.
- Use a certificate issued by your organization's certificate authority. The Model Context Protocol (MCP) page warns when the certificate is self-signed, does not chain to a trusted authority, is not valid now, or does not name the Resource URL's host.
- Turn on Client Auth to accept only clients that present a certificate from an authority you trust.
- The MCP listener answers only requests addressed to the Resource URL's host name and port, and refuses a browser page from another site. Individual nodes in a cluster cannot be reached by their own names.
- Leave Metadata Document Hosts empty unless a client needs it, so the engine fetches nothing from the internet.
The limits before and after sign-in on the Model Context Protocol (MCP) page protect the listener and the console from floods and repeated guessing (see MCP Listener).
Audit and Monitoring¶
The MCP audit log records every client registration, sign-in, consent and token, every tool call, every confirmation and every message body or log text read. Writes and content reads do not run until their audit entry is written, so an action cannot happen without a record. See MCP Audit Log.
The entries also go to mcp-audit.log in the logs folder of the QIE home directory, one JSON object per line, and in a container to standard output. Send them to your SIEM.
QIE raises administrator alerts for a reused refresh token or authorization code, for abuse from one address, and for a failure to write the audit log (see Alerts).
Recommended Client Configuration¶
Let the AI client run QIE's read tools without asking, and have it ask before every tool that changes QIE. QIE cannot protect a session whose client approves changes without asking. The setup pages show how: Connecting Claude Code and Connecting Codex.
Use a separate name for each engine in the client, such as qie-prod and qie-test, and set the Environment Label on each engine, so a person can always tell which engine a session is working on.
Threat Model Summary¶
| Threat | Control |
|---|---|
| An attacker on the network floods the listener or guesses passwords | Limits per address before sign-in, request size limits, registration limits, HTTPS only |
| A stolen access token | One-hour lifetime by default, valid for the Resource URL only, stored as a hash |
| A stolen refresh token or laptop | Rotation on every use, revocation of the whole sign-in when one is reused, lifetimes on the Model Context Protocol (MCP) page, revocation by the person or an administrator, Return message content off by default |
| A person tricked into approving an attacker's client | Sign-ins return only to the person's own computer; the approval page names the client and its return address |
| Text in a message that steers the model | Results framed as data, read-only access by default, confirmation of irreversible actions, the client's approval prompt |
| A malicious or compromised client | Not preventable by the server: the approval page names the client, an administrator can revoke it, the audit log records it by client |
| A read-only insider | No bulk message export, audited content reads, rate limits, secrets masked in every result |
| An AI client widening its own access | The MCP settings, System Configuration and Management API settings are read only through the MCP |
| Changes to the wrong engine | The environment label in every session, and the target named in each confirmation |
| A database restored from a backup | Revoke All |
| A technician working through the QIE Hub | Sign-in through the Hub is refused |
| A compromised Hub, or a stolen Hub signing key | Calls through the Hub off by default, limited to the roles the Role Map maps, no user, role or administrator changes made by the calls themselves (a channel a call starts still runs its own scripts), every statement kept at the engine. The per-person limits follow the person a statement names, so they do not hold back a Hub that names a different person each time |
| A cloud-hosted AI client | Sign-ins return only to the person's own computer |
| The audit store unavailable | Writes and content reads are refused, and an alert is raised |