Credential-Blind Architecture

Diosc Hub never inspects, decodes, or stores your authentication tokens. It forwards them as-is to your APIs. This is a core security guarantee that complements BYOA.

What This Means for You

Your tokens are...	Your tokens are NOT...
Forwarded to your MCP servers exactly as sent	Decoded, parsed, or validated by Diosc
Used only for the active request	Written to any database or log file
Discarded when the request completes	Cached or reused between requests

Diosc treats your tokens the same way regardless of format — JWTs, session cookies, API keys, or anything else.

Why This Matters

Your credentials stay under your control

If your Diosc Hub instance were compromised, an attacker would find conversation history but zero authentication tokens. There is nothing to steal because nothing is stored.

Key rotation just works

When your identity provider rotates signing keys or you revoke a user's token, the change takes effect immediately. Diosc has no token cache to invalidate — the next request simply carries the new token.

Simpler compliance

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

• Diosc Hub is not a credential store — it doesn't need to be assessed as one
• Token lifecycle management stays entirely within your existing identity provider
• Data-at-rest encryption requirements for credentials don't apply

How It Works

When a user sends a message, their auth header flows through to your API:

Your API validates the token as usual — Diosc is transparent in the chain.

User Identity Without Credentials

Diosc needs to know who the user is for conversation routing and audit trails, but this is separate from the credential itself:

• You provide a userId alongside the auth headers when pushing auth context
• Alternatively, your User Resolver webhook identifies the user at session start
• The userId and tenantId are stored for routing — the raw token is not

diosc('auth', {
  headers: {
    'Authorization': `Bearer ${accessToken}`  // Forwarded, never stored
  },
  userId: 'user-123'  // Stored for routing and audit
});

Comparison with Traditional Approaches

Aspect	Traditional AI Integration	Diosc
Credentials stored	Service account password in vault	None
Token in database	Often cached for reuse	Never persisted
Key rotation impact	Must update AI config	Transparent — no action needed
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 work together:

• BYOA means the AI uses the end user's credentials, not a service account
• Credential-blind means those credentials are forwarded without inspection or storage

Together, they ensure Diosc never becomes a gatekeeper for your authentication — it routes credentials to the right destination without holding onto 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