Keeping Client Accounts Apart: Isolation in Apple Cluster Control

The time cross-contamination cost them a client

An agency team told me about an incident last year.

Their accounts were grouped per client, but devices were shared — a job came in and a few devices were allocated to it. During one busy week an operator racing two clients’ schedules signed an account belonging to client A onto client B hardware.

Nothing was lost at the time and nobody thought much of it. Two weeks later client A produced the login records and asked why their account had signed in from that city. The team had no answer. The client did not renew.

The team lead put it well: I can explain low efficiency. I cannot explain cross-contamination.

Agency teams do focus on efficiency — how many clients one operator handles, how much a single process runs. But for an agency running Apple cluster control, the real risk is elsewhere.

The real risk is cross-contamination: a client account operated on another client’s hardware, or two clients landing in the same device group and behind the same network egress.

Why is that worse? Because low efficiency hits your margin, while cross-contamination hits trust. And it has three properties that make it distinctly unpleasant:

• Irreversible. An operation logged on the wrong device cannot be undone.
• Late to surface. The client usually notices the numbers before you notice the cause.
• Asymmetric. One client may notice nothing while another is already on the phone asking why their account signed in from another city at 3am.

Design isolation around what the worst case looks like, not around what it costs to avoid.

Layer one: physical isolation, devices and networks per client

This is the floor. It does not get skipped.

Two things:

Devices divided per client. Each client account runs on its own group. Do not mix clients within a group to save hardware. Mixing means an extra filtering step at every dispatch — and every extra filter is another chance to get it wrong.

Network egress divided per client. This gets overlooked more often than device splitting. If three clients share one broadband line, then as far as the platform is concerned those three clients are one source — one client has an incident and the other two may be dragged in. And that is a very hard thing to explain to a client.

You do not need one IP per device, but you do need different clients not sharing one egress. For the mechanics, there is a dedicated article: three ways to give bulk phone operations their own IP.

One practical habit: give each client devices a recognisable naming prefix. Client A becomes A-01, A-02; client B becomes B-01. This saves you repeatedly once you pass thirty devices — because “whose device is this” gets asked in the group chat far more often than you would expect.

Layer two: cloud control tenants, turning ownership into a rule

Physical separation is held up by people. System separation is held up by rules. The cloud control platform provides a tenant mechanism that maps directly onto agency work.

The idea: take “which device belongs to whom” out of your memory and put it in system configuration.

The key action is opening a tenant per client and fixing that tenant device range. Dispatch carries the tenant identifier, so that client tasks only execute within their own scope. Tenants can also copy existing scripts and tasks from the shared libraries — when one delivery process serves several clients, that saves a great deal of repeated configuration.

There is one step you have to get right: when allocating a tenant, set both the device quota and the validity period. This is among the most common causes of failed deployment — a tenant created without a device range, or a range without a validity period, will simply fail to dispatch, and the error message does not necessarily point at the cause.

There is also an entry point worth using in the permission area: user management allows per-account cloud control settings. If several operators each handle different clients, this layer prevents “everyone can see every client”.

Three layers together:

Layer	Defends against	Mechanism
Device split	Cross-operation	Physical grouping + naming prefix
Network egress	Association risk	Per-client lines
Cloud control tenant	Wrong dispatch, over-reach, mixed results	Tenant + device range + validity

Where the client data boundary sits

Isolation in cluster control is not only “do not cross-operate” — it is also “do not mix records”.

Before onboarding the first client, settle three things:

• Where operation records live. Screenshots, execution logs, results — separated per client, with paths or names that map directly to a client. Do not go looking for them when something happens.
• Who can see what. An operator handling two clients needs to see both; they should not see anything belonging to a third.
• Where delivery material is drawn from. If a client wants a monthly report, the underlying data should come from that client scope, not be picked by hand out of a shared pile.

None of this is noticeable with one or two clients, and retrofitting it later is expensive — because you have to re-sort historical records, and by then you may not even be able to say which records belonged to whom.

What to hand over, and what not to

Draw the agency boundary in advance. It protects you and reassures the client.

Hand over: results and the necessary records. Whether accounts are running properly, publishing activity, performance figures, incident records. What a client cares about is whether their accounts are being handled carefully.

Do not hand over: device state, full control access to accounts, internal task configuration and grouping. Those are your delivery capability, not the deliverable. Handing over the size and grouping logic of your device pool hands over your cost structure with it.

Put this in the contract or service description rather than leaving it implicit. Account ownership especially: the accounts should be lawfully held by the client, and you are only operating them.

Three places it goes wrong

One: onboarding a new client quickly. Accounts dropped into an existing group with a “get it running first” mindset. That is the most common origin of cross-contamination. Onboarding should be a fixed process: create the tenant, set the device range, set the validity, split the network.

Two: handovers that pass on half the picture. What gets handed over is which accounts someone manages, not which devices those accounts map to. The successor understands it by account, operates by device, and the layer in between is missing.

Three: urgent jobs routed around the process. A client needs content out now, so devices are specified manually. That is the step most likely to break the ownership rule. Urgent work can be allowed — but urgency must not exempt the ownership check. Making the ownership check a fixed step inside the urgent path is worth more than assigning blame afterwards.

All three share one cause: a step skipped to save time, where the skipped step was the isolation itself.

Finally

Back to that team. They split devices properly per client afterwards, added naming prefixes and set up the tenants. The lead said re-sorting the devices took two days — far cheaper than losing a client.

Agency work is a trust business. A client hands you their accounts because they believe you will not let anything go wrong with them. Isolation is what gives that belief a mechanism behind it, rather than depending on one person being careful.

Do both layers: physical separation of devices and networks per client, and tenants so that ownership becomes a rule. It does not take much extra time, and it decides whether you go from three clients to fifteen smoothly or by constant firefighting.

For fleet size and grouping, continue with how many phones one PC can actually control and scaling from 5 to 30 devices. For what the cloud control platform itself offers, start with what a phone cloud control system is.

One reminder: make sure the accounts you operate are lawfully held by the client, and that the operating method respects platform rules. The technology is neutral; the boundary lies in the usage.

---

About EasyClick: A phone automation AI-agent platform covering Android no-root, iOS no-jailbreak (proxy / Bluetooth HID / OTG HID) and HarmonyOS Next, offering script development, Apple cluster control, local central control & mirroring, and cloud control systems. → Explore all products