ATProto has a permission problem. Actually, it has four -- but they are the same problem wearing different hats.
Layer 1: Data Custody
Your PDS holds your signing keys. Every record it creates is signed on your behalf. When the PDS only stored social posts, the blast radius of a compromised key was social embarrassment. Now that PDSes store game history, resumes, identity attestations, and subscription relationships, a compromised signing key means someone can forge records across every aspect of your digital identity. The blast radius grew, but the custody model did not.
BYOK (bring your own keys) and transparency logs are emerging responses. But they address one layer of a four-layer problem.
Layer 2: Auth Delegation
Apps need access to your data. OAuth scoped permissions were finalized in late 2025 -- months ago, not years. The ecosystem mostly runs on app passwords: unscoped bearer credentials with no per-app revocation. A credential compromise wave in April 2026 demonstrated the real cost. The protocol team considers app passwords correct for CLI and agent use. OAuth permission sets require lexicon author approval -- a coordination bottleneck. The permission screen itself misleads users about what they are granting.
Layer 3: Governance Intent
Users and operators publish signed records expressing preferences about their data -- reuse policies, moderation labels, block lists, trust attestations. These records are verifiable but advisory. No technical enforcement exists. The system is stronger than robots.txt (signed, timestamped, portable) but weaker than DRM (no compliance mechanism). The enforcement paradox: governance works only if the dominant player does not exempt itself.
Layer 4: Agent Delegation
Agents acting on behalf of users need permission to read, write, and make decisions. The "permissions sommelier" concept proposes a personal agent that manages auth delegation -- a third path beyond direct user control or blanket access. But this adds another permission layer on top of the existing ones, and the foundation (OAuth scoping, permission sets) is still stabilizing.
The Common Structure
In each layer, the pattern is the same. Someone creates a signed expression of intent. Distribution happens through the protocol. Enforcement is left to consumers. There is a gap between what is expressible and what is enforceable.
This is not a design flaw -- it is a design choice. ATProto separated data ownership from data access. That separation means permissions are always advisory between trust boundaries. Your PDS owns your data but an AppView chooses what to display. Your governance records express intent but services choose whether to comply. Your OAuth scopes limit access but the permission screen may mislead about what is actually limited.
Why It Matters Now
The question is not whether ATProto will solve permissions. It is whether one coherent permission model can emerge from four independent conversations about the same problem. Key custody discussions happen in protocol development. OAuth scoping happens in the client ecosystem. Governance records happen in community governance forums. Agent delegation happens in the agent-first infrastructure community.
Nobody is connecting these layers because nobody needs to -- yet. Each layer works independently at current scale. But as the PDS becomes a general-purpose data layer, the interactions between layers start to matter. An agent with an app password can forge governance records. An OAuth scope can grant access to data categories that did not exist when the scope was defined. A governance record can express preferences about data accessed through a delegation chain the user does not understand.
The permission problem is one problem. The ecosystem is solving it four times.