What DioscHub is (and isn't)

The problem it exists for

MCP gives the model a way to call your tools. The hard part is the four things it leaves for you to solve:

• The call needs the right user’s authority. Your APIs are guarded by user auth, so each tool call has to carry that user’s own credential, the bearer token or header your API already accepts.
• The credential has to stay out of the model. If the token sits in the prompt, a prompt-injection can read it. It has to be attached to the outbound call, outside the text the model sees.
• A state-changing call needs an owner. When the model acts as the user, the user has to see the action and approve, edit, or reject it before it runs.
• The browser is half the system. The screen the user is looking at, and actions like navigation, live in the page, out of reach of a backend tool.

DioscHub handles those four, on top of MCP, not instead of it. Each resolves the same way: the AI works within what you already have, namely your APIs, your auth, and your app, so the system stays as predictable as you built it.

In concrete terms, DioscHub is an embeddable AI assistant that reaches your systems through the Model Context Protocol (MCP). You drop a chat widget into your frontend. The assistant answers questions and takes actions. It calls only the tools you expose, it acts as the user who is signed in, within that user’s permissions, and any state-changing action can be held for that user’s approval before it runs.

How each one is handled

Each property below maps to one of the four problems, and each is something you can check at the boundary.

• It calls your existing APIs, not your database. You wrap a system you already run as an MCP server, a thin adapter over the API that already enforces your rules. The assistant reaches your data only through those tools, so your authorization stays where it is.
• It forwards the signed-in user’s auth (Bring Your Own Auth). DioscHub attaches the user’s auth artifact (the token or header your MCP server expects) to each tool call, unmodified, and binds to no identity system of its own.
• The model never receives the credential (Credential Blind). The model requests a tool call; the credential that authorizes it is attached afterward, outside the model’s context. The token is never in the text the model reads, so a prompt-injection payload has nothing to read.
• State-changing tools pause for approval. The assistant proposes the action and its parameters in an approval dialog. The user approves it, edits the parameters first, or rejects it; only an approved call runs, and the decision is written to the approval log.

Together these bound the assistant to what the signed-in user could do directly, through your APIs, with your authorization, on the record.

The shape: a durable engine and a browser counterpart

A backend-only assistant cannot see what the user is looking at or act on the page, and a real integration needs both. So DioscHub runs as two parts: a durable backend engine that holds the conversation and calls your tools, and a short-lived browser counterpart that lives in the page, reads the context the user is in, and performs in-page actions such as navigation, or tools you define against client-side state. The backend part outlives any one page; the browser part lives and dies with it.

The three ways teams use it

The same engine serves three deployment shapes. Pick the one that matches your deployment:

• Authenticated / enterprise. A signed-in user, their real credentials forwarded to your tools, state-changing actions gated by approval. The assistant can do what the user can do, and no more.
• Public / anonymous. A storefront or support assistant with no login. Anonymous visitors get a limited, guarded surface; a visitor who later signs in is promoted in place, and the same conversation continues, now acting as the authenticated user.
• Client-side application. The assistant is embedded in an app whose data and logic live in the browser. You attach client-side tools that the assistant calls to operate on that in-page data directly, instead of routing every action through a backend.

What DioscHub is not

Four boundaries:

• Not an identity provider. It does not authenticate users or manage accounts. You keep your auth system; DioscHub forwards what it produces.
• Not a model host. You bring your own LLM provider and API key. DioscHub orchestrates the conversation and the tool calls; it does not run or resell the model.
• Not a SaaS. DioscHub is self-hosted and single-tenant. You run the published container image, and there is one tenant: you. It is self-hosted because it handles real user credentials, which must stay inside your trust boundary (see the security model).
• Not a no-code chatbot. The value is in connecting the assistant to your systems through MCP servers you control. With no system to connect and no actions to take, DioscHub is more than you need. See when it’s the wrong choice.

---

Next: DioscHub in your stack, where each piece sits and what crosses the lines between them.