The security model at the boundary

A user’s credential takes one path through DioscHub, and DioscHub is wired to reach only a few places. Together, those two facts keep the trust boundary small.

Two mechanisms carry the credential: Bring Your Own Auth (DioscHub carries your credential but runs no auth system of its own) and Credential Blind (the credential never reaches the language model).

Where the credential enters, server-to-server

A user is already signed in to your application. When the chat connection needs to act as that user, the credential does not travel through the browser. The widget hands your backend a connection id; your backend, which already holds the user’s session, makes a server-to-server call to DioscHub, binding the user’s identity and the auth artifact your MCP servers expect (a bearer token, a header, whatever your systems accept) to that connection.

DioscHub holds the artifact against the live connection for the duration of the session. It does not parse it, validate it, or derive identity from its contents; to DioscHub it is an opaque string with one job: to be forwarded. Because the bind is server-to-server, the user’s real credential is never present in the page, so it is out of reach of the model and of the browser.

Where it is forwarded

When the assistant calls one of your MCP tools, DioscHub attaches the bound user’s auth to the outbound call to the MCP server that owns that tool, unchanged. Your MCP server authorizes the request against your own system, as that user, using your own rules. The assistant therefore acts as the signed-in user, within that user’s existing permissions. It cannot do anything the user could not do directly, because the same credential gates both.

The three places it never goes

The forwarded credential is excluded, by construction, from three destinations:

• It never enters the language model’s context. The model can request a tool call; the credential that authorizes the call is attached afterward, outside the model’s view. This is the Credential Blind guarantee. A prompt-injection payload cannot read the token, because the token was never in the text the model sees.
• It never lands in application logs. The auth artifact is not written to the log stream as part of normal request handling.
• It is never persisted as the user’s stored credential. DioscHub is a conduit. It does not keep a credential store for your users. There is nothing to exfiltrate from a database that does not hold it.

Because the credential is never in model context, the classic failure mode, “the AI was tricked into revealing or misusing a token”, has no surface to attack. The model is structurally unable to escalate privilege, because it was never given the means to.

The systems DioscHub cannot reach

The credential path is one half of the boundary. The other half is what DioscHub is not wired to, which bounds the damage of any compromise, including a prompt-injected model.

• No connection to your databases. DioscHub reaches your systems only through the MCP servers you write, which call your existing APIs. It holds no connection to your systems of record. So every read and write the assistant makes passes through your authorization, the same as any other caller. There is no second, unguarded door into your data.
• No general network egress. DioscHub’s only outbound paths are the ones you configure: your LLM provider and your MCP servers. There is no embedded browser and no arbitrary-fetch capability, so there is no open destination to send data to. Combined with Credential Blind, an injected model has nothing to send and nowhere to send it.

These are properties of absence, capabilities that were never added. They are also the reason DioscHub is self-hosted and single-tenant: it handles real user credentials, so it must run inside your own trust boundary, not a vendor’s.

Note

DioscHub keeps its own operational store, holding sessions, approval records, knowledge-base content, and chat history. That is separate from your systems of record, and it does mean the deployment holds some user data; data-lifecycle and retention are an operational concern you own, covered under Secure & Comply. “No connection to your databases” is about your systems, not a claim that DioscHub stores nothing.

What is recorded

Consent is recorded. When a state-changing tool is gated by an approval flow, each decision (approve, edit, or reject) is written to an approval audit log. That record is itself credential-blind: it captures the decision and the action, not the user’s auth artifact.

Provider credentials at rest

Separately from your users’ auth, you configure your LLM provider API key (and any MCP server credentials) in the admin portal. These are encrypted at rest.

Danger

Encryption of provider credentials depends on the credential master keys being set. Set CREDENTIALS_MASTER_KEY, LLM_API_KEY_MASTER_KEY, and MCP_AUTH_MASTER_KEY before production. Without them, provider credentials are stored without encryption. The production hardening checklist lists every required secret.

---

Next: A reference deployment, the whole model in motion, with named actors.