Organisational accounts are something that keeps coming up from time to time in the tangled discord. Way back when in the somewhat early days of tangled during and since September and November of 2025* I came up with what I think is the way forward for org accounts on atproto in general: Account delegation. Fast forward to today and I've managed to nerdsnipe the lovely Lewis into implementing my idea in Tranquil and I now co-maintain Tranquil with him! Not only that, we actually use account delegation for the tranquil.farm org account! So I want to take an opportunity to flesh out the idea in one place that people can reference, as well as try and get a few more eyes on this and, I hope, blaze the trail a bit more for this kind of account becoming a more generally supported feature.

What's even the problem here?

Before I start talking about account delegation in atproto I want to go over what motivated me to define the shape it has today. A good solution has to be rooted in a good understanding of the problem it's trying to solve. In this case: organisational accounts, which themselves are a solution to the issue of wanting to be able to do things (like own git repos on a git forge) under the name of an organisation, instead of just whatever random individual in the organisation happens to be trusted enough for that.

An organisational account is, essentially, an account for an organisation instead of an individual. What makes an org account an org account is thus the ability for other accounts to "act as" that account or otherwise use my credentials to have that account take actions. That's the practical difference between org accounts and normal accounts: Delegation. A GitHub org account is different from a normal account because I can make a repo under that account if I have the permissions to do so. So how do we implement account delegation in atproto?

Accounts are a PDS concern

In atproto accounts are a PDS concern. The PDS is what defines and almost always deals with authn, authz, and all other account management. Therefore, I would argue, the place to implement account delegation, and thus org accounts, is at the PDS and not in apps themselves. Another good reason to do it at the PDS level is that every atproto app thus gains org accounts without the app devs even needing to think about it. If they support normal accounts they also support org accounts.

Essentially what we need is a type of account where access to it can be delegated to other accounts. This is something we can achieve quite easily today in atproto using OAuth! When you try to log into a delegated account, your credentials to do so aren't a password but instead it's the ability to log in to another account that has been designated as a "controller". OAuth let's us do these crazy things with log in because it leaves the actual login part completely in the hands of PDSs (or their designated AS if that isn't the PDS itself). If the account used as controller is hosted on the same PDS then the PDS can of course just authenticate the controller, but otherwise it will need to start a second OAuth flow to have the controller log in to their own PDS which will prove that they are the controller and thus that they should be allowed delegated access to the org account. OAuth is a wonderfully flexible framework.

Permissions

Logging in as another account is great but we don't want the junior social media hire to be able to delete the whole account now do we? We need permissions! Luckily the introduction of OAuth has given atproto a fine way to describe granular access to accounts. We can just reuse that! The atproto permissions spec defines a series of resources and parameters to scope access to those resources and, crucially, permission sets as a way for apps to define bundles of permissions needed for certain levels of access.

So we restrict a controllers access to an account with the same permissions model as clients access to accounts are restricted during OAuth. This is useful because it's an existing set of permissions. It means that translation to "which permissions are this controller allowed to grant to this client" during OAuth login is trivial, and it means that apps defining permission sets for levels of access a client can have also automatically define levels of access to an app that a controller can have. Everything fits together cleanly!

Another set of permissions is of course access to managing the delegation settings, who has what level of access, who can add or remove controllers, etc. That can use whatever permission system wanted but perhaps fitting into the mold of atproto permissions is a good idea. A bit of an open question this one.

Beyond organisations

Account delegation as I've described here was originally conceived specifically for organisational accounts. But the concept has shown itself useful far beyond just that! You might want to have an alias (or in social media terms an alt account) in the vain of email aliases, account delegation makes that a far simpler ordeal. An alias or alt account is just a delegated account where you are the sole controller. No need to keep track of two logins. I am sure there are plenty other use cases I haven't thought of yet so we need to be a bit careful when changing this feature. Don't want to limit the usefulness by changing it in a bad way!

In practice

Like I mentioned in the start everything above exists and has been implemented in Tranquil! You can use it today. We use it every time we post on the Tranquil Bluesky. I considered giving you a screenshot by screenshot walk through of using it as it stands today but that would take up a lot of space in this post and a lot of time for me to do and I'm lazy! So go whip up a PDS running Tranquil and try it out for yourself. It's under the delegation tab in the PDS dashboard. A lot of the underlying details, especially around permissions, aren't quite fleshed out in the UI yet. But the core functionality is there! and the power is available under the hood.

In general there are a few things I want to improve on with the current implementation:

Importantly though, since these accounts are simply another way for you to log into an account, apps don't need to know anything at all about this! and thus this future feature list isn't actually necessary. It will allow apps to smooth out the use of delegated accounts massively but delegated accounts are here today, and work without any of this.

These features that deal more with communicating delegation to clients and API servers are also something I would be interested in seeing get codified in the spec itself. As a community we can settle on a set of APIs around it but many app devs won't know it's a thing without it being specced. Making these features part of the spec itself is also generally good for interoperability and wider adoption.

This design for account delegation in atproto is, honestly, one of the atproto concepts I'm most proud of so far. Not to toot my own horn too much but I think it's an incredibly clean solution to organisational accounts and an incredibly useful primitive for lots of other use cases and It fits very cleanly into the atproto model.