The credential-blind guarantee
DioscHub runs on BYOA: your app already authenticates the user, and DioscHub forwards that user’s credentials to your MCP servers so tools act as the right person. The credential-blind guarantee is the other half of that: those credentials never enter the model’s context. The assistant acts on behalf of an authenticated user without ever seeing their authentication.
This matters because a model you cannot fully constrain should never hold a credential. If the token is never in the model’s context, no prompt — however adversarial — can make the model leak it, log it, or use it to escalate privilege. The guarantee is structural, not a matter of instructing the model to behave.
Credentials travel on the transport, context travels to the model
Section titled “Credentials travel on the transport, context travels to the model”When a tool runs, two separate things go to your MCP server, by two separate paths:
- The user’s credentials travel as HTTP request headers on the connection to your server — the
Authorizationheader, cookies, whatever your app handed DioscHub to forward. This is the transport, not the conversation. See Forward the user’s auth. - The tool call the model produced travels as data — the tool name and its arguments, plus a small envelope of non-identifying context: a user id, the session, the current page. No token, no cookie, no header is ever placed in that envelope.
The model composes the second path. It never composes, and never receives, the first. DioscHub attaches the credentials to the outgoing request itself, after the model has done its part.
What the model, the browser, and the audit each see
Section titled “What the model, the browser, and the audit each see”The guarantee holds at every place a credential might otherwise leak:
- The model receives tool results and the non-identifying context envelope — never the forwarded auth.
- The browser trace that shows a user what a tool was called with is redacted: arguments whose
names look like credentials (
password,token,authorization,cookie, and the like) are masked before the trace reaches the page. - The approval record written when a user reviews a gated tool captures the tool, the operation, and the decision — but the forwarded auth is recorded as empty. The audit trail is credential-blind by construction.
DioscHub treats the forwarded artifacts as opaque throughout: it does not parse them, does not validate them, and does not interpret their meaning. Their meaning is strictly between your app and your MCP servers.
What this does and does not claim
Section titled “What this does and does not claim”Credential-blind is a precise, structural claim: the user’s forwarded credentials do not enter the model’s context, the browser trace, or the approval record. It is not a claim about your MCP server — what your server does with the credential once it arrives is your design. And it does not remove your own obligations for the data DioscHub does persist to run a conversation; those are described in Data handling.