> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mithunai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Control what MITHUNAI support can see

> Support cannot reach your organisation until you allow it. What a session can read, how long it lasts, and the record it leaves in your own audit history.

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](/api-reference/support-access/set-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:

| It can read                                                  | It cannot                                                |
| ------------------------------------------------------------ | -------------------------------------------------------- |
| Your organisation's own settings and branding                | Change anything at all                                   |
| Assistants, their settings and the model catalogue           | Read conversations, or the questions and answers in them |
| Knowledge collections, sources, ingestion jobs and documents | Create, update or delete a resource                      |
| Widget deployment metadata                                   | Create or revoke an API key or a widget embed            |
| Usage figures and the unanswered-questions report            | Open a second session, or reach another organisation     |

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.

<Warning>
  **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.
</Warning>

## A session is bounded four ways at once

| Bound        | Value                                                                       |
| ------------ | --------------------------------------------------------------------------- |
| **Reason**   | Required, 10 to 200 characters, and shown to you                            |
| **Duration** | 60 minutes by default; at least 5, at most 240                              |
| **Scope**    | Exactly one organisation, named when the session opens                      |
| **Verbs**    | `GET`, `HEAD` and `OPTIONS` only, refused at the transport before any route |

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](/api-reference/support-access/get-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](/api-reference/support-access/get-session-activity) 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](/api-reference/support-access/end-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.