Credential-Blind Architecture

Diosc Hub is credential-blind — it forwards authentication tokens without ever inspecting, decoding, or persisting them. This is a deliberate security design that complements BYOA.

What "Credential-Blind" Means

What Diosc Hub does	What Diosc Hub does NOT do
Receives auth headers from the client	Decode or parse JWT payloads
Holds them in memory during the request	Write tokens to disk, database, or logs
Forwards them verbatim to MCP servers	Validate signatures or expiration
Discards them when the request completes	Cache tokens between requests

Credentials are treated as opaque bytes — Diosc Hub has no knowledge of whether they are JWTs, session cookies, API keys, or anything else.

Why This Matters

Reduced Attack Surface

Because Diosc Hub never stores credentials:

• Database compromise — An attacker who gains access to the Diosc database finds conversation history but zero authentication material.
• Memory dump — Tokens exist in process memory only for the duration of a single request cycle, minimizing the window of exposure.
• Log leakage — Auth headers are excluded from application logs by design. There is nothing to accidentally leak.

No Key Rotation Burden

Diosc Hub has no token store to invalidate or rotate. When your identity provider rotates signing keys or a user's token is revoked, the change takes effect immediately — the next request simply carries the new (or rejected) token.

Compliance Simplification

For audits and compliance frameworks (SOC 2, ISO 27001, GDPR):

• Diosc Hub is not a credential store and does not need to be assessed as one.
• Token lifecycle management remains entirely within your existing identity provider.
• Data-at-rest encryption requirements for credentials do not apply to Diosc Hub because no credentials are at rest.

How It Works in Practice

At no point does Diosc Hub:

1. Open or decode the token
2. Write it to any persistent store
3. Include it in logs or telemetry

Extracting Non-Sensitive Identity

Diosc Hub does need to know who the user is for conversation routing and audit trails. This is handled separately from the credential itself:

• The client SDK provides a userId alongside the auth headers.
• Alternatively, User Resolution extracts the user identity at session start via a configurable resolver.
• The resolved userId and tenantId are stored — the raw token is not.

// The auth provider separates identity from credentials
diosc('auth', async () => ({
  headers: {
    'Authorization': `Bearer ${getAccessToken()}`  // opaque, never stored
  },
  userId: getCurrentUserId()  // identity, stored for routing
}));

Comparison with Traditional Approaches

Aspect	Traditional AI Integration	Diosc (Credential-Blind)
Credentials stored	Service account password in vault	None
Token in database	Often cached for reuse	Never persisted
Key rotation impact	Must update AI config	Zero — transparent
Breach exposure	Stored credentials at risk	No credentials to leak
Audit surface	AI credential store must be audited	Not a credential store

Relationship to BYOA

BYOA and credential-blind are complementary:

• BYOA decides whose credentials flow through the system — the end user's, not a service account's.
• Credential-blind decides how those credentials are handled — as opaque, ephemeral bytes that are never decoded or stored.

Together, they ensure that Diosc Hub acts as a pass-through proxy for authentication: it routes the user's credentials to the right destination without ever becoming a custodian of them.

Next Steps

• BYOA — Why the AI uses the user's credentials instead of its own
• Sessions — How conversations maintain context across requests
• MCP — How Diosc connects to your backend services