Skip to main content
An assistant you put in front of customers has to be safe to put there. MITHUNAI isolates every organisation’s data from every other organisation’s, derives the organisation from the verified credential rather than from anything the client sends, treats everything you ingest as untrusted input, and records security-relevant events in an audit trail. MITHUNAI does not train models on your content. The controls behind each of those statements, and what they do not cover, are below.

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.

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.
  • 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.
These controls reduce prompt-injection risk. No system that gives a model untrusted text can eliminate it, so review the sources you connect as part of your security perimeter.

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.

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

Contact your MITHUNAI representative with the affected endpoint, the time and the behaviour you observed. Do not include credentials or another organisation’s data in the report.
Last modified on September 26, 2026