Data handling: what flows where
This page describes what data DioscHub moves and what it keeps, so you can map it against your own compliance obligations rather than take a claim on faith. Nothing here is an assurance about your MCP servers or your app — only about what DioscHub itself does with the data that passes through it.
The path a message takes
Section titled “The path a message takes”- The widget connects. The chat widget opens a connection and, until it is bound, has no identity.
- Your backend binds it. Your server calls DioscHub’s bind endpoint, server-to-server, asserting who the user is and handing over the auth artifacts to forward. This hop is authenticated with a scoped admin API key — the browser never asserts identity, and the public embed key cannot. DioscHub derives which assistant is in play from the connection, not from anything the caller supplies.
- The identity is stamped on the session. From bind onward, the connection’s session carries the user’s id and resolved Role, and holds the auth artifacts so they can be forwarded.
- A turn runs. When a tool fires, the user’s credentials go to your MCP server on the transport (HTTP request headers), while the model works only with tool results and a small envelope of non-identifying context. This split is the credential-blind guarantee.
The auth artifacts your backend hands over are held for the life of the session so DioscHub can forward them to your MCP servers, and are forwarded verbatim — DioscHub does not parse or interpret them, and does not write them into its logs (log lines record counts and ids, never credential values).
What DioscHub persists to run a conversation
Section titled “What DioscHub persists to run a conversation”Running a conversation and its history means keeping some data. The durable stores, and what each holds:
| Store | What it holds | Carries user content or identifiers |
|---|---|---|
| Message history | The conversation itself — the messages exchanged, so a session can be resumed and reviewed | Yes — message text |
| Conversation analytics | Aggregate signals about a conversation: topic, intent, counts, duration | Keyed to the user; no message text |
| Session records | The identity snapshot for the session — user id, name, resolved Role, the pages visited, a first-message preview | Yes — identifiers and a preview |
| Chat files | Files a user uploads inside a chat — private to that user | Yes — private user data |
| Knowledge-base files | Shared reference documents an operator uploads | Shared, not per-user |
| Approval records | A record of each reviewed tool call — the tool, the operation, the decision | Tool and decision; not the forwarded auth |
The line between a user’s private data and shared organizational data is drawn deliberately, and the admin portal stays on the shared side of it — see Privacy boundary. When you need to remove a person’s data, Data erasure & GDPR sets out exactly which of these stores are scrubbed and which are retained by design.
Where the boundaries sit
Section titled “Where the boundaries sit”DioscHub is self-hosted and single-tenant: it runs inside your environment, and everything above stays there. The data it moves crosses two boundaries you own — the server-to-server bind from your backend, and the transport to your MCP servers — and both carry only what you handed it to carry.