DAuth provides credential isolation through a sealed execution model. Your MCP server never sees raw credentials—only opaque handles that reference secrets stored and decrypted within a secure boundary.
The Flow
Step-by-Step
1. Client-Side Encryption
Credentials are encrypted on your device before transmission. Plaintext secrets never travel over the network.
2. Request with Encrypted Credentials
The SDK sends your request along with encrypted credentials to Dedalus.
3. Scoped Token Issuance
DAuth stores the encrypted credentials and issues a scoped token that:
- Is bound to specific MCP servers
- Is cryptographically bound to your client’s key (DPoP)
- Can only be used for authorized operations
4. MCP Server Receives Token
Your MCP server receives the scoped token and validates it against DAuth’s public keys. The server never sees raw credentials.
5. Sealed Execution
When the MCP server needs to call an external API (GitHub, Slack, etc.), it dispatches to a sealed enclave:
- Decrypts credentials using hardware-backed keys
- Calls the external API via TLS connection
- Returns only the response
- Scrubs credentials from memory immediately
The response flows back through the MCP server to your application. At no point did your code have access to raw secrets.
Security Properties
| Property | What It Means |
|---|
| Client-side encryption | Credentials encrypted before leaving your device |
| Scoped tokens | Tokens are limited to specific servers and connections |
| Sealed execution | Decryption happens in isolated hardware boundary |
| Sender-constrained (DPoP) | Stolen tokens are useless without the private key |
| No credential persistence | Secrets decrypted on-demand, scrubbed after use |
Why This Matters
Traditional architectures require your application to handle credentials directly:
User → App → [credentials in memory] → External API → User
With DAuth:
User → Encrypted Token → Scoped Request → Sealed Boundary (App or External API) → User
Your application code, logs, and error traces never contain raw secrets. Even if your MCP server is compromised, attackers cannot extract credentials—they exist only within the sealed execution boundary.
Using DAuth
See Authorization for implementation details:
- Enable DAuth with
AuthorizationConfig
- Configure server-level and per-tool scopes
- Access authenticated user claims in your tools
Last modified on January 27, 2026