- Tenant IsolationENFORCED
Each Customer’s Data Is Kept Apart
The organisation is bound to the request, never an optional filter. It comes from the authenticated key or session, never from the request, and every query and vector lookup is filtered by it. A request without an authenticated scope fails closed.
- Secret ProtectionENFORCED
Automated Credential Redaction
Before a document is extracted, chunked or embedded, a pattern-based scanner redacts private keys, cloud and GitHub tokens, and other credentials, so those secrets are never stored or vectorized.
- Model DefenseENFORCED
Prompt Fencing & Injection Defense
Retrieved passages are wrapped in fences with a random nonce for each turn, and the model is told to treat what is inside as data, not instructions. This makes injected instructions in your documents harder to act on; no prompt defence is absolute, which is why grounding is also checked outside the model.
- Data CustodyENFORCED
Private Cloud & On-Premises Custody
Run the platform in your own cloud account or data centre. It sends no telemetry by default and calls a model provider only with the credentials your deployment configures, so your infosec team keeps operational custody.
Security
How MITHUNAI keeps your data apart, and what is planned
Every retrieval is filtered to one organisation, taken from the signed-in caller and never from the request. Secrets are redacted before content is stored, and ingested content is treated as untrusted. MITHUNAI holds no third-party security certification today, and the list of what is not built yet is on this page.
Last updated
Four pillars of enterprise data custody
Every stage of MITHUNAI has more than one control around it, and each one refuses rather than guesses when it cannot be sure.
What a security review will find
Stated plainly, including what is not in place yet.
Built to survive a security review
An assistant over your internal documentation is only as safe as the boundary around it. Everything you connect is treated as attacker-controlled input, every decision is recorded, and no organisation can read another one’s corpus.
Retrieval cannot cross an organisation
The corpus an assistant reads is bound to its organisation. Evidence from another tenant’s documents is not something the engine can be asked for.
Ingested content is fenced, not trusted
Retrieved evidence, the question and operator guidance each sit inside a separate fence carrying a per-request nonce. Control characters, bidirectional overrides and invisible Unicode tag characters are stripped before a model ever sees them.
Fetching is bounded by policy, and fails closed
Every outbound fetch to a URL you supply goes through one policy: HTTP and HTTPS only, no embedded credentials, a fixed port set, and a refusal for any host resolving to a private, loopback or link-local address, cloud metadata endpoints included. A host that does not resolve is refused rather than attempted.
Credentials are stripped before indexing
A key committed to a repository or pasted into a document is redacted on the way into the corpus, so it cannot be retrieved back out of an answer.
Denials are recorded as denials
A refused request emits a denial event, kept distinct from an operational failure, and the actor is read from the authorization decision itself, so a request that never gained an organisation context is still audited with a complete actor.
A failed audit fails the request
If the record cannot be written, the operation does not quietly proceed. The guarantee is either kept or the request fails.
Connection secrets are write-only
A saved connection’s token is sealed before it is stored, is never returned by any route or written to a log, and is sent only to the one host it belongs to. Every use is audited, and a connection a source still uses cannot be deleted.
Question analytics that name nobody
Top questions carries no identifier of who asked, and lists a question only once three different people have asked it. Opening it is itself an audited action.
Limit: The wording shown is what someone typed, cleaned; a name written inside a question is not always caught.
What to check before you trust an AI platform
Security review questions, answered as they stand today. Where something is still planned, this page says so. The roadmap is below, kept separate from what is delivered.
No outbound calls you did not configure
The default posture makes no telemetry or analytics call. Any host the platform talks to is configured and documented.
Secrets are encrypted at rest and never logged
Credentials do not appear in source, tests, fixtures or logs, and log-bound text is sanitised on the way out.
Parameterised queries, enforced by tooling
Query construction is checked by repository tooling rather than left to reviewer attention.
A monthly answer allowance per organisation
Every surface that answers counts against one monthly allowance per organisation, and the operator can set a different allowance for any organisation, by command or API.
Per-request ceilings and rate limiting
Request volume and per-request cost both have bounds, so one caller cannot consume the deployment.
Planned
These are being built and are not part of the platform today. They are listed so an evaluation can plan around what exists now.
Validation against a live provider
No model provider is bundled. The answer chain has been measured end to end against a local open-weight model, and a grounded answer from a hosted provider is not yet on record.
Agent actions and workflows
Assistants answer; they do not call tools or act in external systems. Agents and AI employees, which do, are surfaces of their own (Beta. Access on request.); an employee acts in a connected tool only after a person approves. Workflows are not built.
MCP client
The MCP server half is delivered as three read-only tools and a feedback tool. Consuming external MCP servers from inside MITHUNAI is deferred.
Spend caps and usage billing
Answers are capped per organisation each month. A monthly model-spend budget per organisation, with alerts and an optional hard stop, is built and switched off; a cap on ingestion and billing for usage are not built.
Answers that follow source permissions
Answering each person only from the documents they can read in the source is built inside retrieval and cannot be turned on yet: the storage it needs is not in place. Every source answers as it does today.
SSO, SCIM and fine-grained RBAC
Enterprise identity integration and finer permission granularity are later milestones.
Questions a security review asks
Grounded answers from your own knowledge, a chat workspace for your team and one model gateway, on one account.
A 30-minute walkthrough on your own use case: connect a source, ask it questions, check the citations and see what it does when the answer is not there. Or ask the public playground now, with no account.