Run client accounts as separate projects, not as shared logins

Every agency starts the same way. One shared password manager entry per client, one browser profile, and a rule that whoever is posting today logs in as the client. It works until the third client, and then it fails in five directions at once.

The fix is not a stricter password policy. It is a boundary: a project per client, with its own connections, its own people, its own approval chain and its own record of what happened.

• Offboarding is impossible to prove. When a contractor leaves, the honest answer to whether they can still post is a password rotation and a hope, not a revocation you can point at.
• The audit trail says nothing. Every action was taken by the client account, so the question of who scheduled the post that caused the complaint has no answer.
• Blast radius is the whole book of business. One compromised session reaches every client at once rather than one.
• Least privilege is unavailable. A junior who should be able to draft can also delete, because there is exactly one level of access and it is total.
• Client exit is a negotiation. Handing back an account tangled into a shared setup takes days, and the client remembers it.

Publishing through an official platform API does not use a password. The client authorizes an application, the application holds a scoped token for that account, and the client can revoke it from their own settings without changing anything else. That is a per client boundary handed to you by design.

It comes with obligations that reinforce the same structure. Meta documents a business verification step in the release process for applications requesting advanced access, and LinkedIn requires an access review before an application may act on behalf of an organization. Both processes ask who you are and what you will do with the access. Both are considerably easier to answer when each client is a distinct, describable relationship rather than a shared browser profile.

A project that only groups posts is a folder. A project that is a boundary owns everything a client relationship touches.

The list is worth reading as a checklist against whatever you use today. Anything on it that is currently agency wide is a boundary violation waiting to be discovered by a client rather than by you.

A boundary that exists only in the interface is a convention. A person who edits a URL, or a script written by a well meaning contractor, walks straight through it.

1. 01At the door: authentication proves who is asking.
2. 02In the service: authorization proves this person may act on this project, checked in the code path every surface shares rather than in each screen.
3. 03In the database: a row level rule makes a query for another project return nothing, so a bug in the layer above becomes an empty result rather than a leak.

Three checks sounds excessive until you consider that each of them fails differently. The first fails to a stolen session, the second to a missing check on one new endpoint, the third only to a deliberate change in the database itself. They are not redundant. They are independent.

The migration is unglamorous and takes about a week of attention spread over a month. It is worth doing before the next client rather than after the next incident.

1. 01Inventory. One row per client, per platform account, listing who currently has access and how.
2. 02Create one project per client and connect that client's accounts through the official authorization flow, with the client present. This is also the moment they see exactly what they are granting.
3. 03Assign people per project, at the lowest role that lets them do their job. Resist a single administrator role for the whole agency.
4. 04Move the calendar for one client only, run it in parallel for two weeks, and compare what published against what was planned.
5. 05Rotate the old shared credentials and remove them from the password manager. Not later. This step is the whole point.
6. 06Write the offboarding runbook while the detail is fresh, and test it on someone who has actually left.

Engagements end. When one does, a per client project turns a delicate conversation into an export and a revocation: here is everything that published, here is the media, and your accounts no longer authorize us. The client keeps their access the whole time, because it was always theirs.

That clean ending is also a sales argument, and it is one of the few that a prospect can verify before signing. Ask any agency how a client leaves. The answer describes the architecture more accurately than the pitch deck does.