What a Compromised Hub Can Reach¶

A Hub sits between operators and every registered site, and that network position is the purpose of the design. It allows central management without inbound firewall openings at each site, and no control inside QIE removes it. This page states exactly what an attacker who controls the Hub process, or who holds its signing keys, can reach at a site. How far that reaches depends on what each site has turned on.

The Hub reaches a site in three ways: through the proxy, through signed statements the site accepts, and through tunnel control commands.

Cleartext at the Hub¶

The Hub terminates TLS, so it handles cleartext. Browser to Hub (HTTPS) and Hub to site (the mutual TLS tunnel) are both encrypted on the wire. The Hub is a legitimate endpoint of both connections: it decrypts each request to route it, check the person's grant and rewrite headers, then encrypts it again onto the tunnel. This is the same exposure any TLS-terminating reverse proxy or load balancer carries.

An attacker who controls the Hub process therefore sees, in cleartext, everything that passes through it:

PHI carried by an operator's actions in a proxied console.
Site login credentials. Every login an operator submits to a site is cleartext in the Hub process before it is forwarded, so it can be captured and replayed.
The site's session cookie, on every proxied request, so an active session can be hijacked or have requests injected into it.
The results of AI calls through the Hub, including message content at a site whose MCP settings return it.

None of this is cleartext on a network link. It is cleartext at the Hub because the Hub is the endpoint that must decrypt to do its job.

A site decides for itself whether to act on the Hub's word. The switch is Use Hub, on the Hub Sign-In tab of the site's Remote Management Hub dialog in System Configuration (see Hub Sign-In), and it is off until the site's administrator turns it on. While it is off, the site refuses every statement the Hub signs.

At such a site the proxy grants no standing access. The site authenticates every proxied request with its own login (local users, LDAP or OIDC), the Hub injects no credentials, and an unauthenticated request gets the site's normal login page. A compromised Hub gains the network position to reach the site and the ability to capture or ride an operator's session as it is used. The mechanism is interception, not a master key. A site that nobody is actively managing through the Hub is not exposed to data theft this way, apart from the control commands below.

At a site with Use Hub on, the site acts on a statement the Hub signs. It acts as the Hub user the statement names, with the site role that its Role Map gives that person's Hub role. Whoever controls the Hub, or holds its statement-signing key or internal CA key, can sign a statement for any person and any Hub role. At such a site that reaches:

Job steps and AI calls: whatever the mapped site role can do. AI calls also need Accept MCP calls through the Hub, on the same tab as Use Hub. Neither path can change the site's administrator records: users, roles, permissions, system configuration (the Hub Sign-In settings included), Management API settings, MCP settings, licenses, the site's Hub registration, or its tunnel certificates and keys. A mapped role that can edit channels can still, for example, add a destination that copies every message elsewhere. That limit applies to the work the statement asks for, not to what it leaves running: a channel it imports or starts runs its scripts as any channel does, with whatever those scripts can reach at the site.

Console sign-in: a console session as the mapped role, when the site has also turned on Console in its Hub Sign-In settings. The session sees message content if that role can see messages. Where the site maps a Hub role to an administrator role, the session is a full site administrator and can change everything at the site, including the Hub Sign-In settings themselves.

A compromised identity provider affects the sites that use it. A compromised Hub affects every site that turned on Hub sign-in, to the extent each one allowed.

What Still Holds Against a Compromised Hub¶

Each site opts in. Use Hub, Console and Accept MCP calls through the Hub are off until the site's administrator turns them on, and a site with a switch off refuses the next statement that needs it.
Per-person limits at each site. Job steps, AI calls and console sign-ins for one person count against the per-person limits on the site's MCP page, so a burst from one Hub user is held back at the site. The count follows the person the statement names, so it holds back a working Hub's busy user, not a compromised Hub, which can name a different person on each statement.
The site's own record. Each site keeps every statement it receives, accepted or refused, for its MCP audit retention period, so it can show what the Hub asked for without relying on the Hub's records.
Alerts for statements that fail a check. A site raises an alert when it refuses a statement that looks forged, replayed or misdirected. That covers an unreadable statement, an untrusted signer, a bad signature, another site or Hub named, an expired or future time, a reused id, the wrong kind of action, and details that do not match. It raises at most one alert per reason every ten minutes on each node, and records every refusal. A refusal the site's own settings explain (a switch off, an unmapped role, a disabled user, a limit reached) is recorded without an alert.
Narrow statements. A statement is good for one site, one kind of action and one use, and expires 60 seconds after signing by default. A captured statement cannot be used at another site or later.

What Does Not Help Against a Compromised Hub¶

Second-person approval of jobs, the Console, Jobs and MCP grants, and ending a person's sessions when they lose access are all enforced by the Hub. A compromised Hub controls all three. They protect against a stolen operator password, a mistake, or a person who has left, not against a compromised Hub. A correctly signed statement from a stolen key passes every check a site makes.

Tunnel Control Commands¶

Independently of statements, a site acts on tunnel control commands from the Hub without a site login, because that is how the Hub manages the fleet's certificates and connections. The commands cover client certificate cycling and revocation, CA trust changes, graceful shutdown, and ending a Hub user's console sessions. A compromised Hub can abuse them to disrupt: shut sites down, force certificate churn, revoke a site's client certificate, or end console sessions. That is denial of service and PKI manipulation, not data access.

Other Concentrations of Authority¶

The internal CA's private key signs every site's client certificate and the statement-signing certificate. Its holder can impersonate a registered site to the tunnel listener, and can sign statements that every site with Hub sign-in turned on accepts. See Hub Key Custody.
A Hub operator who can open a site's console through the Hub can drive the interception described above at that site: anyone whose role holds the Console grant there, Hub administrators included. An operator whose role holds a grant acts, without any site credentials, at every site it reaches that turned on Hub sign-in. Give grants accordingly (see Site Access Grants).

You must accept this risk to deploy the Hub. The point of this page is to make sure you accept it deliberately, for exactly what it is, and harden accordingly.