Securing Creator Account Access: Who Holds Which Keys

An agency runs accounts it does not own. The logins, the inbox behind them, the audience and the money all belong to the creator, and the agency holds keys to all of it so that a team of chatters can work evenings and weekends without her.

That arrangement is normal and it is workable. What makes it fail is almost never a sophisticated attack. It is one shared password, several people who have left, and nobody who can say out loud who currently holds what.

What does an agency actually hold?

More than the platform login. Treating that login as the whole list is the mistake that shapes all the others. A working inventory covers everything that can move money, read messages, or take an account back.

• The platform account and any team seats issued under it.
• The email inbox the account was registered with, which is where password resets land.
• The second factor: the authenticator, the phone number, or the recovery codes.
• Payout details, which are a separate risk from everything else on this list.
• The content library, wherever the originals live.
• Agency tooling, including whatever the team uses to see revenue and conversations.

Sort those by consequence rather than by frequency of use. A chatter reading messages is an ordinary permission. Anyone able to change a payout destination is holding a different kind of key, and the two should never be the same key.

What goes in the access register?

One table, seven rows, five columns, kept current. If it is not current it is worse than nothing, because it produces confidence without accuracy.

Asset	Who needs it	How it is held	Who can revoke	Revoked when
Platform account (owner login)	Creator only	Her own password manager	Creator	Never handed out as a shared credential
Platform team seats	Each chatter, individually	Named seat per person	Agency lead	Same day the person leaves
Registration email inbox	Creator, plus one named agency contact	Password manager, individual access	Creator	On departure of that contact
Second factor and recovery codes	Creator	Offline, not in the account itself	Creator	Reissued after any incident
Payout details	Creator only	Never delegated	Creator	Not applicable; never shared
Content library	Manager and editors	Per-person accounts on shared storage	Agency lead	Same day the person leaves
Agency dashboard and tools	Whole team, scoped by role	Per-person accounts	Agency lead	Same day the person leaves

Two rules do most of the work in that table. Access is per person, never per role, so the activity log names a human. And the column that matters most is the last one, because a register that records grants but not revocations describes a team you had a year ago.

Why does one shared login fail first?

Because it removes the ability to remove anyone. Every problem downstream is a version of that sentence.

• Nobody can be identified. The log shows one account, so a message sent in the creator’s name at a strange hour cannot be attributed to a person. That also defeats the per-chatter review described in the chatter scorecard.
• Nobody can be removed. Taking access from one person means changing the password for everyone, on a live inbox, usually during a busy shift rotation.
• The credential spreads. Shared once in a group chat, it lives in message history on devices you will never see again.
• The second factor breaks. A code sent to one phone means one person has to be awake and available for anyone else to log in, so teams disable it, which is how a shared login becomes an unprotected one.

Use per-person seats wherever the platform offers them. Where it does not, a shared vault with individual access is second best, and the password changes when someone leaves.

What gets revoked when someone leaves?

Six steps, in this order, run before the news travels. The order is what matters: several teams change the password first and then discover the person is still logged in.

#	Step	Why this order
1	Remove the named seat or vault access	The clean cut, if you set up per-person access
2	End all active sessions on the account	A password change does not always kill a live session
3	Change any credential that was genuinely shared	Only now, once sessions are dead
4	Reissue the second factor and recovery codes	The codes may have been photographed at any point
5	Revoke storage, dashboard and tooling access	Where copies of content and revenue data actually sit
6	Reassign open threads with a written handover	Fans are mid-conversation and should not notice

Time it against the shift board rather than the calendar. Our data puts evenings as the window where conversion is highest and the small hours between 2am and 6am as the window where it collapses, so a revocation run that lands in the middle of the evening block costs you the best hours of the day. Do it before the block starts, with cover already named, and use a real handover note so the threads survive the change. The handover note examples cover what that note has to carry.

What do you prepare before an incident, not during one?

Four things, none of which can be arranged once something has gone wrong:

• The register above, current, with a date on it and one named owner.
• Per-person access everywhere it is available, because it is the difference between a revocation and a fire drill.
• Recovery codes stored outside the account they recover, on paper or in a separate vault. Codes kept inside the inbox you have lost access to are not recovery codes.
• One named person who acts without waiting for a meeting, plus the creator’s contact details somewhere other than the platform.

Then attach it to the paperwork. Access belongs in the agreement as a principle (the creator owns the accounts, the agency keeps the register, access ends when the arrangement ends), which is a line in the creator contract checklist. Issuing the seats belongs in onboarding, and the revocation sequence belongs in the offboarding step of hiring.

None of this is fancy security work. It is a list, kept current, by someone whose name is on it. What it protects is not abstract: an account nobody can take back is a creator’s whole income. Data-protection duties vary by country and this page is a description of common practice, not legal advice.