Threat model
Before mapping DioscHub to your controls, start from the model it is built for: self-hosted, single-tenant. You run DioscHub inside your own environment, and one deployment serves one organization. It is not a shared multi-customer service, and it does not try to be — there is no tenant isolation layer, because there are no other tenants to isolate from.
The trust boundary is your environment
Section titled “The trust boundary is your environment”Inside a deployment, DioscHub’s components trust each other as server-to-server peers within one environment. Identity carries context — a user id, a session — but that context is not a security partition between customers; it organizes one organization’s traffic, it does not wall off many. The security boundary is the environment itself: the network, the database, and the secrets you run it with.
Two boundaries cross out of that environment, and both are ones you control:
- The bind from your backend. Your server tells DioscHub who a user is over a server-to-server call authenticated with a scoped admin API key. The browser never asserts identity, and the public embed key cannot bind a user — so a hostile client cannot claim to be someone else. See Implement the bind endpoint.
- The transport to your MCP servers. The user’s forwarded credentials travel to your tools on the connection, never through the model. See The credential-blind guarantee.
Running more than one instance for scale does not change this. Horizontal scaling is a licensed capability in which peers share one environment over a common backplane; it is still a single tenant, not a multi-tenant fabric. See Deployment topologies.
What DioscHub defends in-band
Section titled “What DioscHub defends in-band”Within that environment, DioscHub provides three controls you can rely on by design:
- Credential blindness. The model never receives the user’s credentials, so no prompt can make it leak or misuse them. Read the guarantee.
- Consensus. Any state-changing tool can be gated so a human reviews and approves the call before it runs. Approval policies.
- Scoped access. A user’s private chat data is reachable only through owner-scoped lookups, and the admin surface never reaches it. Privacy boundary.
What you are responsible for
Section titled “What you are responsible for”Because DioscHub trusts its own environment, the environment is yours to secure. That means, at minimum:
- Run it on a private network and restrict who can reach the admin surface and the metrics endpoint.
- Protect the admin API keys — a bind key asserts identity, so treat it like the secret it is.
- Set the required secrets (the credential master key, the erasure pepper, the session secret) — DioscHub refuses to start in production without them.
- Keep the database and its backups protected to the standard the data they hold requires.
The production hardening checklist is the concrete, step-by-step version of this list. Work through it before you expose a deployment.