Tenant isolation
Every organisation’s assistants, knowledge, conversations, keys and settings are isolated from every other organisation’s.- The organisation a request acts in comes from the verified credential, never from a value the client sends.
- Retrieval searches only the asking assistant’s knowledge, inside your organisation. No question, parameter or identifier can retrieve another organisation’s content.
- A resource in another organisation is reported as not found, not forbidden, so nobody can probe for what exists elsewhere.
- Uploaded files are keyed per organisation, and the ownership of a key is checked on read, write and delete. A stored reference to an object can name only the organisation it belongs to, and each of the three paths that touch one re-checks that rather than trusting the stored row.
Authentication and access control
- Three credentials, each fit for purpose. Console sessions for people, API keys for integrations, and public widget keys for anonymous website visitors. See Organisations and roles.
- Checked on every request. Membership, role, key revocation and key expiry are re-checked on each request, with no cache, so removing access takes effect immediately.
- Least privilege. Roles are graduated, nobody can grant a role above their own, and API keys cannot manage API keys.
- Secrets stored as hashes. An API key’s secret is shown once at creation and stored only as a hash. An invitation link and a password-reset link are stored only as digests too, work once, and expire: seven days for an invitation, 30 minutes for a reset.
- People are managed only from a signed-in session. Inviting, changing a role and removing a member refuse every API key, so a leaked key cannot add or change people. Removing a member signs them out, stops the API keys they created in that organisation and withdraws their open invitations. Completing a password reset signs the account out of the console on every device.
- Password reset reveals nothing. The reset screen and its API answer the same for every address, so they cannot be used to find out who has an account, and one address receives at most three reset emails an hour.
- Bounded public access. A widget key can only start conversations with one assistant, from origins you allow, within its own rate limit. Each visitor can only read their own conversation.
Untrusted content
MITHUNAI treats every ingested page, file and repository as untrusted input.- Bounded fetching. Crawls and downloads are limited in depth, page count, size and time.
- Network protection. Fetches are restricted so that a URL or redirect cannot reach private or internal network addresses.
- Secret redaction. Credentials detected in extracted content are redacted before indexing.
- Content separated from instructions. Retrieved passages are presented to the model as content, so text such as “ignore your instructions” is not followed as an instruction.
- Grounding enforced. Answers are checked against the retrieved evidence, and an unsupported answer is withheld rather than invented.
Saved connections
A Confluence, Notion or GitHub token your organisation saves as a connection is handled as a secret, not as a setting.- Encrypted at rest, in your organisation’s own records, and never returned: no screen, list or API response shows a token after it is saved, and MITHUNAI support cannot read one.
- Sent to one service only. A Confluence token goes only to the site it was saved with, which cannot be changed afterwards; a Notion token only to Notion; a GitHub token only to GitHub. Confluence and Notion are read through the same network protections as every other fetch, and a redirect to any other host is refused before anything is sent to it.
- Never replaced quietly. A source that uses your connection never falls back to the deployment’s own access, so a broken token stops the sync rather than reading another way.
- Audited. Saving, replacing, deleting and every use by a sync are recorded in your audit trail.
Controls that are checked automatically
A control that depends on someone remembering to apply it holds only until the next change. Where it can, MITHUNAI derives the list of places that need a control from the code itself and fails its build if one of them lacks it, so new code cannot skip a control by being overlooked.- Every API route must authorise its caller. The exceptions are the few endpoints that answer before a credential can exist: the health checks, a browser’s CORS preflight for the widget, the requests that establish a session, the published sign-in metadata, and the sign-in page’s own theme.
- Every place that reads, writes or deletes an uploaded file must check which organisation owns it. In October 2026 this check found one path, reading a file during ingestion, that relied on an earlier validation instead of re-checking. It was fixed the same day, and was not exploitable, because the only code that could store such a reference already validated it.
Your data
- Your content stays in your organisation. It is used to answer your organisation’s questions and nothing else.
- MITHUNAI does not train models on your content. To answer a question, the relevant passages are sent to the model provider your deployment is configured with, under that provider’s terms. This and the other questions an evaluator asks first are collected in the frequently asked questions.
- Answers are only as current as your last sync. Deleting a source removes its documents from retrieval immediately.
Errors and logging
Error responses contain only a stable code and a generic message. Stack traces, internal paths and configuration never reach a client. Diagnostic detail is kept in server logs for your MITHUNAI operator.Rate limiting
Every endpoint except the liveness check is rate limited, before and after authentication, so the sign-in and authentication paths are protected too. Public widget traffic has its own budget and is refused rather than served without limits if the rate-limiting service is unavailable. See Rate limits.Audit
Authorisation decisions, both allowed and refused, are recorded in the audit trail, as are security-relevant actions such as creating and revoking API keys and widget embeds. An Owner’s or Administrator’s read of a conversation they did not take part in is recorded too, as is every read of Coverage gaps and Top questions; reading your own conversation records nothing. So are invitations sent, re-sent, revoked and accepted, role changes and removals, completed password resets, and every save, replacement, deletion and use of a saved connection.Not yet available
MITHUNAI support
MITHUNAI support cannot reach your organisation until an Owner or Administrator allows it, and a session it then opens is read-only, expires on its own, excludes every conversation, and writes each request it makes into your own audit history. See Control what MITHUNAI support can see.Report a security issue
Tell your MITHUNAI contact, giving the affected endpoint, the time and the behaviour you observed. Do not include credentials or another organisation’s data in the report.Related pages
- Compliance: what MITHUNAI can and cannot claim today.
- Shared responsibility, Subprocessors, Data handling and the Security questionnaire: what a security review asks for.
- Accounts and roles: who may do what inside an organisation.
- Support access: what MITHUNAI support can read, and only when you allow it.
- Architecture: how the layers are built and where your data lives.
- Product status, Troubleshooting, the FAQ and the Changelog.