> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dedaluslabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# DAuth Architecture

> How DAuth protects credentials with sealed execution

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

```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
sequenceDiagram
    participant U as SDK
    participant P as Dedalus
    participant CP as DAuth
    participant M as MCP Server
    participant S as Sealed Enclave

    Note over U: 1) Encrypt credentials client-side
    U->>U: Encrypt credentials

    Note over U,P: 2) Send request with encrypted credentials
    U->>P: Request + encrypted credentials

    Note over P,CP: 3) Send scoped request
    P->>CP: Scoped request
    CP-->>P: Scoped token

    Note over P,M: 4) Call MCP server with scoped token
    P->>M: Tool call + scoped token
    M->>M: Validate token

    Note over M,S: 5) Execute in sealed boundary
    M->>S: Execute request
    S->>S: External API
    S-->>M: Result
    M-->>P: Tool result
    P-->>U: Response
```

## 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](/sdk/mcp/python/authorization) for implementation details:

* Enable DAuth with `AuthorizationConfig`
* Configure server-level and per-tool scopes
* Access authenticated user claims in your tools