The platform at a glance
Accounts, organisations, members, sign-in and usage belong to the MITHUNAI platform, which every MITHUNAI product shares: RAG, Chat, the Gateway, Agents and Team all read the same account, the same organisation and the same role.Members
Invite colleagues, change what they can do, and remove them when they leave.
Invitations
Send a link to join your organisation; they choose their own password.
Sign in once
Beta One account for every product, and one sign-out that
ends every session.
Settings
Every section of console Settings, for you and for your organisation.
Audit log
Download who did what in your organisation, and whether it was allowed.
Usage and limits
Your monthly answer allowance, how much is used and when it resets.
Organisations
Your assistants, knowledge, conversations, API keys, widget embeds and branding all belong to one organisation, and nothing crosses between organisations. Isolation is enforced on every request, from the identity that made it. It never depends on a value the client sends. A resource that belongs to another organisation is reported as not found rather than forbidden, so nobody can discover what exists elsewhere by guessing identifiers. Organisations are created by whoever operates your MITHUNAI deployment, each with its first Owner. You cannot create one from the console.Accounts
An account is an email address and a password. There is no self-service sign-up: the console’s sign-up form explains this and does not create an account. An account is made in one of two ways:- An Owner or Administrator invites the person by email, and they choose their own password from the link. This needs your deployment to be able to send email.
- The operator of your MITHUNAI deployment creates it.
POST /members sends one too, whether or not the person already has an account.
The same account signs in to the console and to Chat, which serves one organisation and admits only its members. Agents and the Model Gateway stand differently: see One sign-in.
Roles
Every person and every API key holds one role in the organisation. The role decides what they can do.
Two rules apply to everyone:
- Nobody can grant a role above their own. An Administrator cannot create an Owner API key.
- Changes take effect immediately. Membership and permissions are checked on every request, so a removed member or a revoked API key is refused on its very next request.
People and machines
MITHUNAI recognises three kinds of caller. All three go through the same authorisation checks.
A widget visitor can only start a conversation with the one assistant the embed names, ask questions in it, and read their own conversation back. They cannot read your knowledge, your settings or anyone else’s conversation.
Administration boundaries
Your organisation’s Owners and Administrators control everything inside the organisation that the console and API expose: assistants, knowledge, API keys, widget embeds, analytics and branding. Platform-level concerns, such as creating organisations and configuring model providers, are handled by whoever operates your MITHUNAI deployment. MITHUNAI’s own support staff are outside this entirely, and reach nothing until you let them: see Control what MITHUNAI support can see. How isolation is enforced on each request, rather than merely intended, is in Security.Administer your organisation
- One sign-in: how accounts sign in to the console, Chat, Agents and the Model Gateway.
- Members: list the people in your organisation and add a colleague.
- Settings: every section of the console’s Settings screen.
- Branding: your name, logo, colours and links on the console and the widget.
- Support access: what MITHUNAI support may read, and only when you allow it.
- Deployment: where MITHUNAI runs, and the settings its operator controls.