How to Manage Client Amazon Accounts as an Agency (2026)

Every Amazon agency eventually learns the same lesson, and most learn it the expensive way: the biggest threat to your clients' accounts isn't a competitor, a hijacker, or a bad review. It's you. Specifically, it's the laptop your account manager uses to log into eleven different Seller Central accounts before lunch.

Amazon's systems don't know you're an agency. They see one device, one network, one browser fingerprint, touching a dozen supposedly unrelated selling accounts — and that pattern looks exactly like one operator running a ban-evasion ring. When one of those accounts trips a policy review, the association you created can drag the others into it. That's the core problem this guide solves.

Below is the full playbook for how to manage client Amazon accounts as an agency in 2026: the architecture that keeps accounts genuinely separate, the parts of Amazon's own tooling you should still use, the onboarding and offboarding procedures that protect both sides, and the team workflows that make it all survivable at scale.

Why agency account management is different from normal multi-accounting

Most multi-account guides are written for people quietly running several of their own accounts. Agencies are in a different position — a mostly legitimate one — but the detection systems can't tell the difference, and that's what makes the problem interesting.

Amazon's Seller Code of Conduct restricts sellers to one account per region unless they have a legitimate business need. Your clients each have their own legitimate account. You, the agency, are allowed to operate them. Nothing about the arrangement is against the rules. And yet the enforcement machinery that hunts for "related accounts" doesn't read contracts — it reads signals.

What Amazon actually sees when you log in

When anyone signs into Seller Central, Amazon collects far more than an email and password. It sees:

• The network: your IP address, its ASN, whether it's a datacenter range, and its geographic location.
• The device fingerprint: your browser's canvas rendering, WebGL renderer string, installed fonts, screen resolution, timezone, language headers, audio stack — dozens of signals that combine into a near-unique identifier. If this is new territory, our beginner's guide to browser fingerprinting walks through each signal, and the EFF's Cover Your Tracks tool will show you your own fingerprint in about ten seconds.
• Cookies and local storage: session tokens and identifiers that persist across visits — and, crucially, across accounts if you log into several from one browser profile.
• Behavioral patterns: login times, navigation habits, the rhythm of how an operator moves through the console.

When the same fingerprint, IP, and cookie jar shows up across multiple selling accounts, those accounts get linked internally. We've broken down the full mechanics in how websites detect multiple accounts on the same device — Amazon is simply one of the most sophisticated practitioners of it.

The cascade failure

Here's the scenario that keeps experienced agency owners disciplined. Client A gets suspended — maybe a genuine policy issue, maybe an erroneous "related account" flag from a past VA, maybe an IP complaint. Under Section 3 of Amazon's Business Solutions Agreement, Amazon may take action against accounts it believes are related to a non-compliant one.

If your agency has been logging into Clients A through K from the same machine on the same office IP, you have manufactured relatedness between eleven businesses that have nothing to do with each other. In the worst version of this story, one client's suspension becomes a multi-client incident, an emergency all-hands, and a very uncomfortable series of phone calls. Agencies have lost their entire book of business to exactly this cascade.

The fix isn't secrecy — it's hygiene. Each client's account should be operated from an environment that looks like that client's own office: consistent device, consistent location, no bleed-through from anyone else's account. That's the standard the rest of this guide builds toward.

The four ways agencies do this (and what each one costs)

Before prescribing an architecture, it's worth being honest about the alternatives, because every agency starts with one of the cheap ones.

Why the cheap options fail

The VPN-switching approach fails because a VPN changes exactly one signal — the IP — while your browser fingerprint, cookies, and cached identifiers scream continuity. Chrome profiles fail for the inverse reason: they separate cookies but present an identical fingerprint for every profile, because they're all the same Chrome on the same hardware. Amazon doesn't need cookies to recognize a device it has fingerprinted before.

The VPS approach genuinely works — each client gets a real, distinct machine — and some agencies still run it for their highest-value accounts. But it collapses under scale. Twenty clients means twenty Windows licenses, twenty RDP sessions your team fumbles between, twenty machines to patch, and (unless you pay extra) twenty datacenter IPs, which are themselves a soft flag. When a task takes ninety seconds of work and forty seconds of remote-desktop lag, your margins are being eaten by architecture.

What the working standard looks like

An antidetect browser gives each client a profile: an isolated browser environment with its own cookie jar, its own local storage, its own persistent data directory, and — this is the part Chrome profiles can't do — its own complete fingerprint. Canvas, WebGL, fonts, screen metrics, user agent, timezone, languages: all internally consistent, all different from every other profile, all stable across sessions.

In Dual Login specifically, the fingerprint is applied natively inside a custom Chromium engine rather than injected as JavaScript, which matters because injected spoofing is itself detectable — the WebGL spoofing deep-dive explains why the injection approach leaves seams that native spoofing doesn't. Each profile launches as a separate real browser process with its own data directory, so Client A's session physically cannot leak into Client B's.

To Amazon, each client's account is accessed from what appears to be one consistent, unremarkable device. Which is precisely the truth you want to represent: these are separate businesses.

Use Amazon's sanctioned tooling first — then fill the gaps

A guide like this would be negligent if it didn't say clearly: the front door exists, and you should use it whenever it's open.

User Permissions is your default

Seller Central has a built-in mechanism for exactly your situation. The client, as the account owner, goes to Settings → User Permissions and invites your agency email as a secondary user with scoped rights — advertising, inventory, pricing, reports, whatever the engagement covers. You log in with your own credentials, Amazon knows you're an authorized third party, and there's no identity ambiguity at all.

Do this wherever the engagement allows. It's cleaner legally, cleaner operationally, and it means a permission can be revoked in one click when the engagement ends. Amazon also maintains a directory of vetted service providers — being discoverable there is worth pursuing as your agency matures.

Where User Permissions falls short

So why does the isolation architecture matter at all? Because real engagements regularly exceed what secondary-user access covers:

• Primary-account tasks. Certain settings, verification flows, Brand Registry actions, and account-health responses require the primary login. When a client is mid-crisis at 2 a.m. their time, "log in yourself and click this" is not a viable instruction.
• Full-management clients. A large share of agency clients — especially overseas brand owners selling into the US or EU — hand over the entire operation, credentials included. They don't want to touch Seller Central. That's what they're paying you for.
• Your own accounts. Many agencies also operate house brands, wholesale accounts, or test accounts. Those are yours, fully, and need the same separation from each other and from client accounts.
• The multi-user fingerprint problem. Even as an invited user, if one employee's browser touches twelve accounts, you're still building an association graph. Lower stakes than shared primary logins, but not zero — particularly if any account in the graph has a troubled history.

The honest architecture is layered: sanctioned access where possible, isolated environments always, so that no matter which door you enter through, each client's account sees a consistent and separate device.

The reference architecture: one client, one environment

Here's the setup that holds up at 10, 50, or 200 client accounts.

One profile per client account

Create one browser profile per client Seller Central account — not per client company (a client with US and EU accounts gets two profiles), and not per employee (three team members serving one client share that client's one profile). The profile is the client's device. It should be the only place that account is ever opened.

Name profiles so nobody has to guess: something like ACME-US-SellerCentral beats Client 3. In Dual Login you can group profiles — by client, by pod, by marketplace — so an account manager opens their book of business as a folder rather than scrolling a flat list of eighty entries.

One dedicated proxy per client, geo-matched

Each profile gets its own proxy, and the choice matters more than most agencies realize:

• Type: residential or ISP proxies, never shared datacenter IPs. Amazon's risk models treat datacenter ranges with suspicion, and a shared proxy means inheriting the reputation of strangers. Static residential/ISP is the sweet spot for account management: clean reputation, stable IP. The residential proxy playbook covers selection and vetting in depth.
• Geography: match the client's business location. A Manchester-based client whose account suddenly logs in daily from Karachi — because that's where your VA team sits — is a verification trigger waiting to fire. Put that client's profile behind a UK IP and the geography stays boring forever.
• Stability: for account management you want the same IP every session, not a rotating pool. Rotation is for scraping. A seller account that hops cities every login looks compromised, and "your account may have been accessed by an unauthorized party" emails to your client are not a good look.
• Consistency with the fingerprint: the profile's timezone and language should agree with the proxy's location. Dual Login derives these from the proxy exit IP automatically; if you're assembling this by hand elsewhere, it's the most commonly missed step. Our guide to changing your browser fingerprint explains why internal consistency beats randomness — a fingerprint that contradicts itself is worse than no spoofing at all.

Persistent sessions, deliberately

A detail that separates account-management setups from scraping setups: you want long-lived sessions. Logging in fresh every day, from a cold cookie jar, is itself anomalous — real sellers stay logged in for weeks. A proper profile persists cookies and local storage across launches, so the session Amazon sees looks like a trusted, familiar device. It also means dramatically fewer OTP prompts, which matters because every OTP is a round-trip to a client's phone or a shared inbox.

Speaking of which: move each account's two-step verification onto a TOTP authenticator seeded into your password manager (with the client's consent, documented), rather than the client's personal phone number. Nothing degrades an engagement like needing the client to forward a text every time you work on their account.

Credentials live in a vault, never in the profile notes

Use a real password manager with per-client vaults and per-employee access — 1Password, Bitwarden, whatever your team will actually use. The rule that matters: an employee can retrieve exactly the credentials for the clients they serve, retrieval is logged, and revoking one employee doesn't require rotating every password in the agency. Which brings us to people.

Team workflows that don't undo the architecture

The technical setup fails silently the first time a team member takes a shortcut. These are the operating rules that keep it intact.

The profile travels, the person doesn't matter

Because the client's identity lives in the profile — fingerprint, cookies, proxy — any authorized team member can open it and appear to Amazon as the same consistent device. This is the property that makes handovers clean: shift changes, holidays, and staff turnover don't produce new-device alerts, because the device never changed. With cloud sync, an account manager in one office and a specialist in another can work the same client profile on different days, sessions intact, without the account ever seeing a strange machine.

The corollary rule: one profile open in one place at a time. Two people driving the same session simultaneously is both operationally messy and behaviorally weird. Dual Login enforces this with a cross-device lock — a profile open on one PC shows as "in use" everywhere else — but if your tooling doesn't, make it a written rule.

Never cross the streams

Three prohibitions worth putting in the employee handbook verbatim:

1. No client account is ever opened outside its profile. Not "just quickly" in a personal Chrome to check one thing. That single login stamps the employee's real fingerprint and IP onto the client's account history.
2. No personal browsing inside client profiles. The profile is the client's workspace, full stop. Personal Gmail inside a client profile contaminates it in both directions.
3. Agency house accounts get the same isolation as client accounts. Your own seller accounts are where sloppiness usually starts, and links propagate.

Audit trails are for you, not just for disputes

At scale you want to know who opened which client's account and when — for internal accountability, for client reporting, and for reconstructing events when something goes sideways. Dual Login keeps a per-account activity log and audit trail; if you're on other tooling, at minimum keep launch logs. The day a client asks "who changed our pricing on Tuesday?", an answer beats a shrug.

Onboarding a new client account: the checklist

A concrete sequence, refined by agencies that have done this a few hundred times:

1. Paperwork first. Signed authorization to operate the account, scope of access, and a named client-side contact for verifications. This protects you if Amazon ever questions the arrangement — legitimate agency relationships are defensible; undocumented ones look like account sales.
2. Collect the state of the account. Account health history, past suspensions, previous agencies or VAs, and — importantly — where and how the account has been accessed recently. An account that's been logged into from four countries by a previous freelancer team needs a settling-in period, not another abrupt change.
3. Provision the environment. New profile, named to convention, dedicated geo-matched static residential proxy, timezone and language aligned. Generate the fingerprint once and never regenerate it — stability is the whole point.
4. First login, gently. Do the initial login during the client's normal business hours, complete whatever OTP dance is required with the client on standby, then stay logged in. Spend the first sessions on read-only work — reports, settings review, account-health audit — before making changes. New device + immediate aggressive changes is a classic compromise signature.
5. Move 2FA to the shared authenticator, store credentials in the vault, assign the profile to the serving team, and record everything in the client's runbook.
6. If migrating from User Permissions to full management (or vice versa), don't leave stale access behind. Old freelancer emails with live permissions are the most common unnoticed liability on aged accounts — audit Settings → User Permissions during onboarding and get the client to prune it.

When something goes wrong anyway

Good architecture reduces incidents; it doesn't eliminate them. Two scenarios worth pre-planning:

A verification challenge fires. Usually triggered by a genuinely new circumstance — a proxy IP change, a re-verification sweep, a KYC refresh. Respond from inside the client's profile (same device, same IP — don't compound the anomaly), loop in the client contact immediately for anything requiring identity documents, and afterwards write down what triggered it. If your proxy provider rotated an allegedly static IP, that's a provider conversation.

A client account gets suspended. First: because your environments are isolated, this is one client's crisis, not an agency-wide one — which is the entire return on the discipline this guide preaches. Handle the appeal through the account's own profile, keep other clients' operations completely untouched, and resist any temptation to research the suspension while logged into other accounts. Our Amazon suspension-avoidance playbook covers the prevention side in detail; the agency-specific addendum is simply that your isolation determines whether a suspension is a contained event or a contagion.

Offboarding: the part everyone improvises

Engagements end. A clean exit protects your reputation and the client's account:

• Hand back access formally. Rotate the password with the client on the call, transfer the 2FA seed or have them re-enroll their own device, and remove your agency users from User Permissions.
• Decide what happens to the environment. Best case: the client continues using an isolated profile (some agencies hand over the profile itself, or help the client set up their own Dual Login workspace, so the account keeps its familiar device identity). Worst case: the client returns to logging in from wherever, and the device change is at least a single, explainable transition.
• Purge your side. Archive the runbook, revoke vault access, delete the profile after an agreed retention window. Holding live credentials for ex-clients is pure liability.
• Leave a paper trail. A short offboarding document — access returned on date X, agency access removed, 2FA transferred — has settled more than one later dispute.

Scaling past twenty clients

A few things change as the book grows. Group structure starts to matter more than naming — pods of profiles per account-management team, with permissions so each team member sees only their own clients (Dual Login's team roles support exactly this scoping: a junior can open and work profiles without the ability to export cookies or touch billing). Proxy spend becomes a real line item, so consolidate onto one or two vetted providers with static residential inventory rather than accumulating a drawer of subscriptions. And bulk operations — health checks across all clients every morning, report pulls, repricing sweeps — become worth automating; the same profile isolation that protects logins also gives automation a safe, per-client lane to run in.

If your agency also touches other marketplaces, the same architecture transfers directly — the multiple eBay accounts guide covers the eBay-specific wrinkles, but the core discipline (one account, one environment, one IP) is identical everywhere.

FAQ

Is it against Amazon's rules for an agency to manage client accounts?

No. Amazon explicitly supports third-party service providers, and Seller Central's User Permissions feature exists for exactly this. What gets agencies in trouble isn't the relationship — it's the access pattern: many unrelated accounts touched from one device and IP, which mimics ban evasion. Documented authorization plus isolated environments keeps you on the right side of both the rules and the risk models.

Should we use User Permissions or full logins?

Use User Permissions whenever the engagement's scope fits within it — it's cleaner and instantly revocable. Take full credentials only when the work requires primary access or the client wants hands-off management, document the authorization, and operate the account exclusively from its dedicated isolated profile either way.

What kind of proxy should each client profile use?

A static residential or ISP proxy, dedicated to that client, located in the client's business region. Avoid shared datacenter IPs (poor reputation) and rotating pools (a seller account shouldn't change cities between logins). One clean, boring, stable IP per client is the goal.

Can multiple team members work on the same client account?

Yes — that's a strength of the profile model. The client's device identity lives in the profile, so any authorized team member who opens it appears as the same consistent device. Just enforce one-at-a-time access (Dual Login locks a profile while it's open elsewhere) and keep an audit trail of who worked which account.

Will one client's suspension affect our other clients?

If every client is operated from an isolated profile with its own fingerprint and IP, there is no technical link for Amazon to follow, and a suspension stays contained to that one account. If your team has been sharing browsers and IPs across clients, the accounts may already be associated — which is precisely the exposure this architecture removes.

Do Chrome profiles or a VPN solve this?

No. Chrome profiles separate cookies but share one identical device fingerprint across all of them; a VPN changes the IP while leaving fingerprint and cookies intact. Amazon links accounts on the signals those tools don't touch. You need separation at the fingerprint level, which is what an antidetect browser provides natively.

The bottom line

Managing client Amazon accounts as an agency is a discipline problem wearing a technical costume. The principles are short: use Amazon's sanctioned access where it fits, give every client account one isolated environment with its own fingerprint and its own clean local IP, let the profile — not the person — carry the device identity, and document every access decision from onboarding to offboarding. Do that, and account linking stops being an existential risk and becomes a solved infrastructure detail.

Dual Login was built for exactly this shape of work: per-profile native fingerprints, persistent isolated sessions, per-profile proxies with automatic timezone matching, team roles with scoped permissions, and cross-device sync with in-use locking so handovers are clean. If your agency is still juggling client accounts in Chrome profiles and a shared VPN, spin up a few isolated profiles in Dual Login and migrate one client this week — the setup takes an afternoon, and it's the difference between a contained incident and a cascade.