> ## 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.

# Administer MITHUNAI Chat

> Who can use MITHUNAI Chat, how sign-in and sign-out work, the two keys a Chat deployment needs, how your brand reaches it, and what is switched off.

MITHUNAI Chat needs almost no administration: everyone in your organisation can sign in with their
MITHUNAI account, there is no admin role inside Chat, and its settings are policy fixed by the
deployment. An Owner or Administrator looks after one thing -- the Member API key Chat reads your
knowledge with -- and your platform administrator looks after the Gateway key and which optional
capabilities are on.

## Who can use Chat

* **Every member of the organisation the Chat deployment serves**, in any role. Each Chat deployment
  serves exactly one organisation.
* **Nobody else.** An account from another organisation is refused at sign-in. There is no guest
  access and no Chat-only account.
* **Nobody is an administrator inside Chat.** Chat's own admin powers -- rewriting its endpoints and
  tool servers -- are deployment-level, so no customer account is given them, whatever its role in
  the console.

To give someone Chat, [invite them](https://docs.mithunai.com/administration/invitations.md) to your organisation. To take it away,
[remove them](https://docs.mithunai.com/administration/members.md) from your organisation.

## Sign-in and sign-out

Chat has no password of its own. **Sign in** goes to the MITHUNAI sign-in page; see
[Sign in once](https://docs.mithunai.com/platform/sign-in-once.md).

**Log out** in Chat ends your Chat session. Once single sign-out reaches your deployment, signing out
anywhere else ends your Chat session the next time Chat renews the sign-in, **within about fifteen
minutes**; until then, a Chat tab that is already open stays signed in. See
[How signing out works](https://docs.mithunai.com/platform/sign-in-once.md#how-signing-out-works). When someone must lose access
at once, tell your MITHUNAI contact.

## The two keys behind Chat

| Key | What it does | Who creates it |
| - | - | - |
| **Gateway key** | The only way Chat reaches a model. Usage and budget are counted on it, for your organisation | Your platform administrator, in the [Gateway](https://docs.mithunai.com/gateway/overview.md) |
| **Knowledge (API) key** | An `mithunai_sk_` key with the **Member** role. Chat uses it to read your knowledge and fetch your theme | An Owner or Administrator, under [API keys](https://docs.mithunai.com/administration/api-keys.md) in the console |

The knowledge key never reaches the model or the browser: it travels only between Chat's server and
MITHUNAI.

**To rotate the knowledge key**, create a new Member key in the console, give it to whoever runs your
Chat deployment, and revoke the old one once they confirm Chat restarted on the new key. Revoking the
old key first switches the **Knowledge** tool off for everyone until the new one is in place.

## Your brand in Chat

Chat takes its colours from your organisation's [branding](https://docs.mithunai.com/administration/branding.md) when it starts.
**A colour change reaches Chat at its next restart**, not at once. If the branding cannot be read
when Chat starts, it opens in its own default colours rather than failing.

Each person chooses light, dark or system mode, and **Increase contrast**, for themselves under
**Settings**.

## What is switched off, and why

Chat is built on LibreChat, an open-source chat workspace, and runs with far fewer capabilities than
it can. **Each capability left out is something that could run code, browse, or call a third party
that nobody reviewed.** None of these is reachable unless the operator of your deployment sets it
up deliberately.

| Capability | State | Why |
| - | - | - |
| **Web search** | Off | Needs a third-party search provider, which would receive your queries |
| **Code execution** | Off | Runs in a third-party paid sandbox |
| **File search** over uploads | Off | Needs a second retrieval system. MITHUNAI is the single knowledge source, through the **Knowledge** tool |
| **Adding your own MCP servers** | Off | A member could point the model at a host nobody reviewed |
| **Side-by-side artifacts** | Off | Uses a hosted code bundler |
| **Custom HTTP actions** for agents | Off | Arbitrary calls from the model to any address |
| **Public shared links** | Off | A shared thread opens only for people signed in to your Chat |
| **Your own provider keys** | Not offered | Every model call goes through the Gateway, so usage is counted and keys stay in one vault |
| **File types** beyond the list | Refused | Text, Markdown, CSV, PDF, PNG, JPEG and WebP only. SVG and HTML are refused because both can carry script |

These are **on** by default: saved prompts, bookmarks, temporary chats, side-by-side replies, shared
links inside your organisation, agents in Chat, skills and scheduled chats. An operator can switch
any of them off.

**On the hosted service**, MITHUNAI operates Chat and these settings are fixed. On a private-cloud or
on-premises deployment, the operator sets them; a capability whose service is missing is refused at
start-up rather than shown as a button that fails. Ask your MITHUNAI contact before relying on
anything in the first table.

## Data and isolation

* **One organisation per Chat.** A Chat deployment reads one organisation's knowledge, through a key
  that belongs to it. MITHUNAI decides the organisation from the key, never from anything Chat
  sends.
* **Threads stay in that Chat's own database**, and each person's threads are their own.
* **Every model call goes through the Gateway**, so Chat holds no provider credentials.
* **MITHUNAI does not train models on your conversations.** See [Security](https://docs.mithunai.com/security.md).

## Related

* [Troubleshooting](https://docs.mithunai.com/chat/troubleshooting.md)
* [Organisations and roles](https://docs.mithunai.com/concepts/organizations-and-roles.md)
* [One sign-in](https://docs.mithunai.com/administration/onelogin-and-staff.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.