Dedalus Labs has announced the Dedalus Labs Authentication Layer, a multi-tenant authentication architecture for the Model Context Protocol (MCP) that let’s developers secure their MCP servers easily.
Addressing MCP’s authentication gap
Currently, implementing authentication on MCP is a chore for developers. While the MCP specification standardizes how to use OAuth, it does not offer guidance on how non‑OAuth credentials, such as API keys or other access tokens, should be stored or managed. That omission has left many developers to rely on ad hoc practices and single-tenant infrastructure, which requires users of an MCP server to re-authenticate permissions for each MCP server their agent uses.
Recent high-profile [security](https://www.docker.com/blog/mcp-horror-stories-the-supply-chain-attack/) [incidents](https://thehackernews.com/2025/09/first-malicious-mcp-server-found.html?m=1) have underscored the risk of unsolved MCP auth. A compromised host that stores raw credentials can expose secrets for many downstream tools at once, making MCP deployments a target for supply chain attacks.
Dedalus Labs’ approach is to separate credential handling from the host environment entirely and to provide a shared, multi-tenant trust layer that can be reused across MCP servers on our platform.
Zero-trust, host-blind architecture
At the core of the Authentication Layer is a multi-tenant, zero-trust, "host-blind" design that keeps plaintext credentials out of reach of the marketplace operator and application hosts.
The system works as follows:
1. Client-side encryption: The Dedalus SDK encrypts user credentials on the client device before they cross the network.
2. Open-source auth server: When the SDK requires privileges, it initiates a secure exchange with Dedalus Labs’ open-source auth server, using standard OAuth 2.1 flows to validate access.
3. Standard MCP integration: When a request reaches an MCP server, the server operates as an OAuth 2.1 Resource Server, verifying access without directly handling the underlying credential.
4. Network-less enclave execution: After a request is validated, it is forwarded to The Enclave, a network-less, hardware-secured environment written in Rust.
5. Ephemeral credential handling: Credentials are decrypted only inside The Enclave, for the brief period required to execute the request, then cleared from memory before the response is encrypted and sent downstream.
In this model, even a fully compromised host node would not provide attackers with access to user API keys or tokens. The Enclave effectively acts as an isolated execution environment for sensitive operations rather than a general-purpose compute layer.
Multi-tenant infrastructure for MCP marketplaces
The Authentication Layer is built as shared infrastructure rather than a one-off component for a single server. In a single-tenant model, each MCP server typically needs to provide its own standalone authentication service. DAuth allows multiple servers to rely on the same underlying authentication system.
Agents built with the Dedalus SDK can be authenticated once on the platform and then reuse that trust to access tools across a marketplace, subject to scoped permissions. This is intended to support a one-to-many marketplace model while maintaining a consistent standard for how credentials are handled.
The company is also using an intent-based approach, where developers define high-level intents (for example, `slack_read`) rather than wiring tool-specific flows for each integration. Under the hood, the Authentication Layer maps those intents to the appropriate permissions and infrastructure, preventing agents from accessing tools they don’t have permission to use.
Availability
The Dedalus Labs Authentication Layer is available through the Dedalus SDK. Developers can begin integrating it into MCP servers and agents immediately. Dedalus Labs is publishing documentation, example use cases, and reference implementations to show how the system can be incorporated into existing MCP deployments.