Running client accounts you are authorised to manage without linking them

This is about accounts your agency is authorised to operate on a client's behalf, ad accounts, marketplace seller accounts, social pages, the kind of access a signed contract already grants you. Twenty of those, logged into from one browser on one office machine, share more with each other than most agencies realise, and the fix is not only about the browser.

Why one browser links twenty accounts

Every login from the same browser profile hands the destination site the same canvas hash, WebGL renderer, font list, and cookie jar. Even in separate browser profiles, if they run on the same machine, the underlying hardware fingerprint is identical across all of them. A platform that watches for accounts sharing a device signature does not need shared cookies to connect client A's account to client B's, the hardware signal alone is enough to cluster them.

Why the browser is usually not the real cause

Fixing the browser closes one channel. The linkage that gets accounts flagged together more often comes from signals no browser setting touches:

• Shared recovery email or phone. If your agency's own address is the recovery contact on several client accounts, the platform sees that shared identifier the moment any recovery flow runs.
• Shared payment method. An agency card on file across client ad accounts is a direct, queryable link between them, independent of any device signal.
• All accounts first touched from the same office IP. Creation and first login from one address, even once, is a timestamped fact the platform already logged before you started worrying about fingerprints.
• Identical creation patterns. Accounts created in a batch, named with the same convention, or set up in the same ten-minute window read as one operator running many accounts, which is exactly what a marketing agency is, but not what the client's account should look like to the platform.

None of this is solved by clean canvas hashes. It is solved by not creating the shared signal in the first place, which is a process question before it is a tooling question. Background on how these signals get read together is in Why accounts get flagged.

One identity per client, with a sticky proxy

The part a browser setup can fix: give each client account its own persistent profile, on its own residential exit IP that stays assigned to that client, so the account is not seen switching networks between sessions. That is one variable removed, not the whole picture. It only works alongside the process fixes above, recovery contacts and payment methods that belong to the client, not the agency, and account creation spread out instead of batched.

Client offboarding, the step everyone forgets

Contracts end. Access should end with them, and the part agencies skip is the browser profile itself, not just the platform-side permission revoke. When a client relationship ends:

• Remove the agency's access grant on the platform side, the obvious step.
• Hand back or destroy the local profile that held that client's session. A profile that still has valid cookies, saved passkeys, and a working proxy binding is standing access that outlives the contract, whether or not anyone remembers it exists.
• If the client wants continuity, export the profile to them as a portable archive rather than leaving it live on agency infrastructure.
• Confirm nothing in the agency's password manager or recovery contacts still points at that client's accounts.

A profile sitting unused on a former employee's laptop or an old agency machine is the same exposure as an active login nobody closed.

The data-protection question your client may ask

If client account sessions are synced to a vendor's cloud, that is a fact your client is entitled to ask about, who holds the data, where, and under what retention. Cloud sync is only useful for continuity across machines, and it is worth being able to answer plainly whether it is on. Profiles are directories on disk by default, cookies, local storage, and passkeys as local files, and cloud sync is opt-in per profile rather than automatic. For most agency work, keeping client profiles local-only and handling continuity through the offboarding handoff above is the more defensible answer to that question, because there is no vendor-held copy to explain.

Where a plain browser profile is the better answer

If the agency runs two or three client accounts total, not twenty, a Chromium profile per client on one machine may be entirely adequate, since most of the linkage risk above comes from process, recovery contacts, payment methods, and creation timing rather than the fingerprint. Buying a tool for a linkage problem that is really a shared-recovery-email problem does not fix the shared recovery email.

Check your own setup

List every client account your agency touches and check, for each: whose recovery email is on file, whose payment method, and whether the account was created from an IP shared with other client accounts. That audit costs an afternoon and finds most of the real risk before any browser change does. Details on the isolation model, and what stays local versus what syncs, are on the security page.