Support access, and what we can see

You use Qorionix to watch your own attackers, which makes any ability of ours to read your security data the most dangerous capability in the product: an operator who can silently read your alerts is operationally indistinguishable from an intruder. This article says what we can see, under what conditions, what is written down, and how you check it. It is unflattering in one place — your consent is not currently required before an operator looks.

The obvious way to build vendor support is a flag that lets staff see any customer. We rejected it: once a master switch exists, every support question routes through it, the audit trail says only that an operator read your organisation, and you cannot tell a glance from an afternoon of reading. What exists instead is diagnosis without touching your data, access as an expiring dual-controlled grant rather than a held privilege, and disclosure that is not optional.

The two things an operator can request

That is the complete list. No operator route returns a log line, a mailbox rule, a credential, a session recording or the contents of an alert. Each count is fetched independently with a three-second limit; one that cannot be read is marked unavailable rather than failing the whole bundle.

Is your consent required? No — and here is why

The strongest model is prior approval by you for every access. We have not built it. Rather than describe the design we would like, here is what the module's own documentation says:

In plain terms: a Qorionix engineer can open your diagnostics view without asking you and without a colleague approving. Reading your alert metadata needs a second, different Qorionix operator to approve — but that person is one of ours, not one of yours. You are not asked and cannot pre-emptively refuse. What you always get is a record, in your own audit log, of what was looked at and why.

How a grant works, and how quickly it dies

Access is time-boxed, and the windows are short because the costs are asymmetric: re-requesting takes seconds; a forgotten live grant is unbounded.

• A reason of at least twelve characters is mandatory. One short enough to be typed thoughtlessly is not a reason — and this is the field you read in your own audit log. Refusal reads a reason is required and must be at least 12 characters.
• Data access needs two different operators. The database enforces that the approver is not the requester. The clock restarts at approval, so a request that sits waiting does not consume its window.
• A data grant satisfies a diagnostics requirement, never the reverse.
• Refusal is the default. Without a live, correctly-scoped grant the answer is no active support-access grant for this tenant and scope, with a 403. Expiry is tested by the database, so a wrong clock cannot keep a grant alive.
• Changing anything needs three things at once — an active data grant, a break-glass token and a reason. The refusal reads mutating support actions require a break-glass token and a reason. A break-glass token is signed, needs two operators, expires within an hour and is consumed on use.

What is written down, in your log and ours

Every grant event and every access writes twice, always: into our own hash-chained operator ledger, and into your organisation's audit log. There, an operator action is distinguishable in two ways: the action name begins with support., and the user field is empty, because the actor is not one of your members. The row carries the operator's identity, the grant, the scope, the reason they typed, and — on a data read — the number of records returned.

support.grant.requested
support.grant.approved
support.grant.activated
support.grant.revoked
support.grant.expired
support.access.diagnostics_read
support.access.data_read

Those rows also carry the literal user agent zentryq-control-plane. Filtering on support. is the check to run, occasionally rather than never. A sweeper expires due grants every minute and writes the closing record — which is why the control plane never scales to nothing: automatic expiry and its customer-visible closing disclosure are security properties.

What we can see without any grant at all

• A diagnostics grant is self-service. An operator wanting the counts-and-configuration view can have it in seconds, without you or a colleague approving. The control is the disclosure, not a gate — requiring a second person for a numbers-only view would train operators to treat approval as a formality, weakening the approval that guards real data.
• Notification records are read by support engineers, and copied into backups. That is why their content is filtered on the way in: an allowlist decides what is stored, and the alert's raw event, a command's arguments — where the secrets are — and Sentinel-Q's reasoning and evidence references are excluded. The detail stays behind the link, which requires authentication.
• Operational telemetry about your tenancy exists — cell health, replication lag, queue depth, error rates. It describes the infrastructure serving you rather than your data, and it is how we know your service is degraded before you tell us.

The console our own staff use

Qorionix operators do not manage tenants from the same console you sign in to. They use a separate internal application, reachable only to Qorionix staff, for tasks like the tenant roster, licensing and the grants described above. One concrete example of that separation: if an operator looks at your organisation's AI provider setup, they can see which provider and model you have configured, whether it is switched on, and the result of the data-residency check run against it — but never your API endpoint URL or any API key or credential value, which are left out of the query itself rather than merely hidden on screen. That is the same restriction your own non-admin roles already sit under: reading your AI provider configuration at all requires the admin role, precisely because a read also returns the endpoint hostname and the tail of the key, and "this organisation runs its security AI on their own resource in this location, and here is a fragment of the key" is reconnaissance rather than configuration. That reasoning applies with more force to somebody outside your organisation entirely, so the operator console withholds the two columns even from staff who can see everything else about the setup.

Why an operator cannot simply forge a token

Your users sign in to one system. Our operators use a completely separate one — a control plane behind mutual certificate authentication and an address allowlist, with its own signing key.

The separation matters because of what happened when it was absent. The control plane used to fall back to the key your users' sessions use. That key is symmetric, so anyone holding it could mint an operator token by adding one group claim to an ordinary user token — demonstrated, not theorised: such a token returned a successful response on the cross-tenant operator route.

The fix is structural. The control-plane program refuses to start if its operator signing key is missing, too short, or equal to your users' key. It exits with this:

cmd/controlplane refuses to start: the operator signing key must be a separate
secret from the tenant JWT_SECRET, or any holder of the tenant key can forge an
operator token

The check runs in the other direction too: an operator token carrying an organisation or a user identity is rejected as a replayed user credential. Operator tokens must name a real person and cannot live longer than twelve hours — an audit row with an empty actor is not an audit row. The address allowlist fails closed: an empty list denies everything.

What you can do about an access you disagree with

Be clear about the limits. There is no screen in your console for approving a grant in advance or revoking one — revocation is an operator action today, and tenant-side approval is the piece we have not built. You have visibility and escalation.

1. Filter your audit log on support. Every grant and every read is there, with the operator, scope, reason and record count. Do this after any support conversation in which you shared something sensitive.
2. Ask what will appear before you agree to it. Support reads the same disclosure list you do.
3. Ask for revocation, quoting the grant identifier from the audit row. Grants also expire on their own within hours at the outside, and within thirty minutes for data access.
4. Escalate anything that looks wrong — an access with a thin reason, or one you cannot connect to a conversation you had. Use the security route in How to get help. We would rather answer a question about a legitimate access than have you decide not to ask.

Your own staff's access is a separate subject: Who can see and do what. Nothing in your roles grants or restricts a Qorionix operator.