Who Actually Owns Your ATProto Identity?

Hint: It’s probably not you.

Date: March 1, 2026
Tags: #atproto #open-protocols #decentralization

Following my previous analysis regarding the risks of centralization within Bluesky, I decided to dig deeper into the technical inner workings of the Personal Data Server (PDS).

Initially, my concerns were centered on the possibility of Bluesky acting as a "bad actor"—locking accounts or creating vendor lock-in. However, I discovered that those scenarios are actually the least concerning things a PDS operator can do to a user.

The Root of the Problem: Key Control

The PDS doesn't just store your data; it manages your rotation key. This key is the master switch for your identity. Because the PDS operator controls this, they possess the power to:

Modify your signing key.
Redirect your account to a different PDS.
Effectively seize total ownership of your DID (Decentralized Identifier).

Mathematically, we can view the identity relationship as: $\text{Identity Control} = \text{Rotation Key} \rightarrow \text{Signing Key} \rightarrow \text{DID}$

If an operator has the rotation key, they have total authority. They can post, like, or follow others as you, and these actions would be cryptographically indistinguishable from your own.

The Critical Difference: While a Twitter database admin could theoretically alter a tweet in a database, an ATProto PDS operator can become you across the entire protocol.

The Ecosystem Ripple Effect

ATProto is designed to be more than just a social network. It is a foundation for various applications. Your PDS is the single point of failure for every app you use on the network:

Bluesky: Social networking.
Tangled: A git-based collaboration platform.
Grain: Social interactions.
Leaflet: Long-form writing.

Every one of these services writes to the same repository, uses the same signing key, and is managed by the same PDS operator.

The "Developer" Nightmare Scenario

Imagine a third-party PDS provider that attracts thousands of software engineers. The operator now holds the keys to a massive concentration of technical influence. They could:

Post inflammatory or fake statements from high-profile developer accounts.
Grant themselves push access to repositories on Tangled, facilitating massive ~~minor~~ supply chain attacks.

// Conceptual representation of a compromised PDS action
{
  "op": "rotate_key",
  "did": "did:plc:12345",
  "new_signing_key": "attacker_public_key",
  "authorized_by": "PDS_Operator_Rotation_Key"
}

Identity Death vs. Data Loss

There is a vital distinction between the data and the keys.

Feature	Relay Compromise	PDS Compromise
Data Access	Can read public data	Can read and write data
Identity Control	None	Full (via Rotation Keys)
Impact	Privacy leak of public info	Total impersonation/Lockout
Scope	The "Firehose" stream	The User's DID

The data itself is public and broadcast via the firehose (the real-time network stream). The real danger is that a rogue employee, a state actor with a warrant, or a hacker doesn't just get to read your history—they get the keys to create your future and lock you out of your own digital existence.

~~Getting banned from Twitter doesn't stop you from using GitHub.~~ In the ATProto world, if your PDS operator decides to "kill" your identity, you are locked out of every application in the ecosystem simultaneously.

The Path Forward

The system is currently brittle because it relies on blind trust in the PDS operator. However, a solution exists: Self-controlled rotation keys.

By enrolling a rotation key that you control (with a higher priority than the PDS key), you ensure that even if the PDS is malicious, they cannot steal your identity. You could simply rotate the signing key and move your DID to a new PDS.

Proposed Improvements

Default Enrollment: Backup rotation key setup should be mandatory during account creation.
Transparency: Users need a tool to audit every signature the PDS has generated on their behalf.
Education: The ATProto documentation must explicitly warn users that their PDS holds their keys.

Final Thought: ATProto achieves decentralization at the architectural level, but its key management is dangerously centralized. It asks users to consolidate their digital lives under one identity and then hand the keys to a stranger. It is a level of trust that would make even the most centralized platforms blush.