Skip to main content
When you open a ticket, MITHUNAI support often cannot help without seeing what you see. The usual answers to that are all worse than the problem: a shared administrator account, a database console, an impersonation button that reproduces your whole authority inside a second code path. MITHUNAI does none of them. Instead, support access is a separate principal, off by default, read-only, time-limited, and recorded in your audit history. It is off until an Owner or Administrator in your organisation turns it on.

​
It is off until you turn it on

Until you allow it, your organisation is not visible to support at all. An attempt to open a session against it is refused as though the organisation did not exist. Turn it on from Settings → Support access in the console, or with Allow or withdraw support access. Only an Owner or Administrator can. Consent is re-read on every request a session makes, not cached when the session opens. Withdrawing it therefore stops a live session on its next call, and withdrawing it also ends every live session immediately: turning this off is revoking access, not declining to renew it.

​
What a session can read

A support session holds one role, support_viewer, which grants exactly five read permissions and nothing else: Read-only is enforced twice over. The role grants no write permission, and the transport refuses every method but GET, HEAD and OPTIONS before a route is reached, so a write cannot arrive at the code that would decide about it.
Conversation content is excluded, and there is no switch that grants it. What your people asked an assistant, and what it told them, is the most sensitive content the platform holds and the least likely to be needed for a ticket about ingestion. There is deliberately no toggle, because a toggle is something that can be asked for while you are frustrated and want the ticket closed. If a transcript genuinely is needed, send it yourself.

​
A session is bounded four ways at once

The authority belongs to the session, not to the staff member. A second session is a second principal, ending one withdraws exactly that authority, and the staff member’s own console — where they are a member of nothing — is unaffected. Reaching your organisation also needs two credentials at once: the staff member’s own signed-in session and the session id in a header. A session id that turns up in a log line, a screenshot or a screen share grants nothing on its own.

​
You can see who was in, and what they did

Read support access lists the sessions live right now and the recent history, each with the staff member’s name and email, the reason they gave, and when the session started and expires. Read what a session did lists every request it made, newest first, with the method, path and status — refusals included, so an attempt at something the role does not permit shows as an attempt rather than as silence. It is read from your audit log rather than from the session, so it outlives the session. To stop one session while leaving support access on, use End a support session. To stop everything, set allowed to false. Session start, end, expiry and revocation, every consent change, and every request made under a session land in your organisation’s audit history, under the staff member’s account, not in a log somebody else holds.

​
Who counts as support

Support staff are named in deployment configuration, in a list kept separate from the platform administrator list. Support staff hold exactly one platform permission — the ability to open a support session — and cannot create or suspend an organisation, read platform configuration or change a feature flag. Removing an account from that list ends its access on the next request, not at the next expiry.
Last modified on September 26, 2026