ATProto Identity Control: Your PDS Operator Holds the Keys to Your Digital Life

Who actually owns your ATProto identity? According to a deep dive published March 1 by Kevin Åberg Kultalahti, the answer is probably not you. Your Personal Data Server (PDS) operator holds both your signing key and rotation key, giving them the power to post, like, follow, and even lock you out of your identity across every application built on the protocol.

Kultalahti, a community builder and co-founder of Svelte Society, details that the PDS signs every commit to your repository, whether it is a post on Bluesky, a commit on Tangled, or writing on Leaflet. The signatures are cryptographically valid, meaning a compromised operator can impersonate users indistinguishably across all ATProto apps.

Single key, multi-app risk

Unlike a traditional platform where a database admin's reach is limited to that service, ATProto's design means one PDS operator controls a user's entire digital footprint across the ecosystem. Kultalahti warns that if a popular third-party PDS host signs up thousands of developers, the operator could post inflammatory content, push malicious commits to repositories, or publish fake blog posts. All of it would appear legitimate on the network.

• The PDS holds the signing key for every post, like, and follow an account makes.
• The rotation key lets the operator change signing keys or reassign the DID to a new PDS, effectively taking full identity control.
• Compromising a single PDS gives attackers or rogue employees the ability to act as every user hosted on it across all ATProto applications.
• Users banned by their PDS operator lose access to their identity across the entire ecosystem, not just one app.
• The data itself is public, but the keys allow creation of new, verified activity and lock users out.

Default security gap

ATProto offers a workaround: users can enroll a self-controlled rotation key with higher priority than the PDS key. This prevents the operator from locking them out while still allowing the PDS to sign activity. However, Kultalahti notes this is not the default, so most users never set it up. He argues that backup rotation key enrollment should be part of the standard account creation flow, built into clients rather than hidden in APIs. Users should also have tools to audit what their PDS has signed on their behalf. The protocol's documentation, he says, must clearly explain these trade-offs because the current system asks users to trust their PDS operator with a level of control that surpasses even centralized platforms. Without changes, the promise of decentralization stops at the architectural layer, while the key management layer remains deeply centralized.