Who Controls Your ATProto Identity? Analyzing the Security of PDS Key Management

The rapid growth of the AT Protocol (ATProto) has introduced developers to a highly portable, decentralized identity system powered by Personal Data Servers (PDS). However, the architectural convenience of delegating key management to a third-party PDS operator introduces a significant, often overlooked security trade-off. Because the host operator holds both the signing and rotation keys by default, users do not fully control their cryptographic identity. Understanding this delegation risk is critical for developers building cross-app ecosystems where a single compromised key can compromise an entire digital footprint.

What happened

Recent technical deep dives into the AT Protocol's Personal Data Server (PDS) architecture have highlighted a critical centralization risk regarding how cryptographic keys are managed. By default, a user's PDS holds their signing key, which is used to sign every repository commit, post, follow, and interaction. More importantly, the PDS also manages the rotation key, which dictates the decentralized identifier (DID) document's state. Because of this setup, a PDS operator can technically alter signing keys or redirect accounts, making any unauthorized action cryptographically indistinguishable from legitimate user activity.

While the protocol supports enrolling a self-controlled rotation key with higher priority than the PDS's key, this is not the default behavior. Consequently, the vast majority of users—estimated to be over 99.9% hosting on default Bluesky infrastructure—rely entirely on their host's operational integrity. If an operator is compromised, coerced, or goes rogue, they possess the technical capability to not only post on a user's behalf but also permanently lock them out of their identity across all connected applications.

Why it matters

Unlike traditional federated or isolated social networks where a compromise is scoped to a single platform, ATProto is designed as an "everything account" identity layer. Applications like Tangled for git collaboration, Leaflet for publishing, and Grain for social interactions all write to the same repository signed by the same key. A single compromised PDS operator exposes a developer's identity across the entire ecosystem, opening the door to severe supply chain attacks, such as unauthorized repository commits or malicious package updates.

Conversely, if an operator decides to deplatform a user, they do not just lose access to a single application like Bluesky. Because the PDS controls the active identity state, a hostile operator can effectively destroy a user's ability to interact with any ATProto-compatible application. While the raw data remains public on the firehose, the cryptographic identity itself is rendered unusable without access to recovery keys.

How to think about it

Developers and builders must approach ATProto not as a fully trustless system out of the box, but as a framework that trades immediate sovereignty for user convenience. To mitigate these risks, high-value accounts—especially developers managing code repositories or critical infrastructure—should treat their PDS as a semi-trusted agent rather than an absolute authority. This requires actively enrolling a self-controlled, offline rotation key that sits above the PDS in the DID PLC document hierarchy, allowing for rapid recovery and key rotation if the host is compromised.

Furthermore, the ecosystem must mature to support hybrid models, such as local PDS proxies. Under this model, a local, secure environment holds the private keys (potentially backed by a hardware security module) to sign state updates, while a remote PDS proxy merely hosts and broadcasts the signed events to the network. Until these architectures and their corresponding user experiences are standardized, developers should exercise caution when linking sensitive workflows, like source control, to the same identity used for casual social media.

FAQ