Sub-Account

Anyone who signs up for an online service gets an account: an access with username, password, and its own data. A sub-account is a second account that hangs beneath this main account. For the user, it functions like a normal login, but legally and organizationally it belongs to the main account. The owner of the main account creates such sub-accounts themselves and can also delete them again. They also determine what is allowed in each sub-account and what is not. This principle can be found at banks, at crypto exchanges, at cloud providers, and at almost every software service that companies use.

Why companies don’t work with a single login

A company with fifty employees could theoretically use a single account. In practice, this would be a security problem. Everyone knows the same password, and no one can later trace who did what. If someone leaves, the password has to be changed for everyone. With sub-accounts, everyone gets their own access, and a single one can be deactivated without disturbing the others.

The second reason is control over permissions. An intern may need read access to reports, but certainly not the ability to transfer money. Sub-accounts make it possible to define exactly that. Experts call this principle least privilege: everyone gets only as many rights as they actually need for their task. This limits the damage if an access is stolen.

The third reason is billing. A company often wants to know which department consumed how much computing power. If each department gets its own sub-account, the invoice automatically delivers this breakdown. This is especially relevant for AI services, since they are billed based on usage and costs can fluctuate significantly.

Inherited permissions and separate balances

Technically, a sub-account is a separate entry in the user database that references the main account. This connection determines almost everything else. Settings and permissions are inherited downward from the main account, similar to how folders in a file system pass their properties on to subfolders. The sub-account can usually narrow these defaults further, but not expand them.

An important question is what is separated between sub-accounts and what is not. At crypto exchanges, sub-accounts often have separate balances: losses in one sub-account do not spill over into another. At cloud providers, on the other hand, often only the data is separated, while the billing is consolidated in the end. Anyone using sub-accounts needs to know the respective provider’s rules.

A related term is the API key. This is a long code that a program uses to log in instead of a human. Sub-accounts and API keys are often combined: each sub-account gets its own keys that only permit certain actions. A common misconception is that a sub-account is automatically secure. If the administrator grants it full permissions there, the advantage over a shared password is practically gone.

From the crypto exchange to the AI provider

Sub-accounts are most visible in the financial sector. Trading platforms like Binance or Bybit advertise them explicitly, because professional traders want to keep different strategies separate from one another. If an automated trading program runs in its own sub-account, it cannot touch the rest of the assets. Asset managers also use this to maintain a separate account for each client.

With AI services, this principle is usually encountered under different names. OpenAI and Anthropic speak of projects or organizations within a company account, while at Amazon Web Services they are called accounts within an organization. The idea remains the same: separate access, graduated permissions, traceable costs. The term comes up in reports about security incidents when attackers have taken over a poorly secured access and used it to reach other areas.