Security & Credential Encryption

Security is a core design principle of McpMux. Every credential — API keys, OAuth tokens, passwords — is encrypted before it ever touches disk. McpMux never stores plaintext credentials.

The Problem with MCP Credentials Today

Without McpMux, MCP server credentials are stored in plaintext JSON configuration files:

{
  "mcpServers": {
    "github": {
      "env": {
        "GITHUB_TOKEN": "ghp_abc123_YOUR_REAL_TOKEN_HERE"
      }
    }
  }
}

These files sit in your home directory, readable by any process on your machine. If your machine is compromised, every MCP credential is immediately exposed.

How McpMux Protects Credentials

AES-256-GCM Encryption

Every credential stored by McpMux is encrypted using AES-256-GCM (Galois/Counter Mode) — the same standard used by banks and governments. Each credential gets its own encryption, so compromising one doesn't expose others.

OS Keychain Integration

Encryption keys are stored in the operating system's secure keychain:

The encryption keys never exist as plaintext files. They're protected by the OS and require your user session to access.

Per-Token Encryption

McpMux doesn't use a single master key for all credentials. Each stored token is encrypted with its own derived key, meaning:

• Compromising one credential doesn't expose others
• Rotating a credential doesn't require re-encrypting everything
• Deletion of a credential securely removes its encryption key

Memory Zeroization

Sensitive values in memory are securely wiped using the zeroize crate when they're no longer needed. This prevents credentials from lingering in memory after use, reducing the window for memory-based attacks.

Per-Space Credential Isolation

Credentials are scoped to individual Spaces. Your work GitHub token in the "Work" Space is completely separate from your personal GitHub token in the "Personal" Space. They use different encryption keys and are stored independently.

This means:

• Switching Spaces switches credentials — no cross-contamination
• Deleting a Space securely removes all its credentials
• Different team members can use different credentials for the same service

Before vs After

OAuth Security

For servers using OAuth 2.1, McpMux implements the full security specification:

• PKCE (Proof Key for Code Exchange) — prevents authorization code interception
• Short-lived tokens — access tokens expire after approximately 1 hour
• Automatic refresh — tokens are refreshed transparently before expiry
• Encrypted storage — both access and refresh tokens are encrypted at rest
• Consent UI — OAuth authorization requests show a consent dialog in the desktop app, ensuring the user explicitly approves each connection

Deep Link Security

When McpMux receives an OAuth authorization request via deep link (mcpmux://authorize?request_id=xxx):

• Only the request_id is passed in the URL — no client information or credentials
• The consent token is shared only via local IPC, never over HTTP
• The desktop app validates the request server-side before showing the consent dialog

Next Steps

• Get started with McpMux to see encryption in action
• Learn about Spaces for credential isolation
• Configure Servers with encrypted credential storage
• Download McpMux to protect your MCP credentials today