Giving a contractor access to your proxy lines

You’ve hired someone to run part of your operation. A virtual assistant, a freelance developer, someone to manage a set of accounts. They need to work through your proxy lines, and the fastest thing to do is paste them the host, port, username, and password in a chat message. That message will still exist in 2 years, on a device you’ve never seen, in an account you don’t control. Here’s what to do instead, and none of it is complicated.

I run mobile proxy hardware out of Singapore, real SingTel, M1, and StarHub SIMs sitting in physical modems. A decent share of what I deal with is customers who have people working for them, and the questions that come up are always the same three: how do I give them access, how do I take it back, and how do I tell what they actually did. This is the practical version of those answers.

The problem with sharing one credential

Pasting a shared credential isn’t wrong because it’s insecure in the abstract. It’s wrong because it fails on four specific things you’ll need later. You can’t revoke it without breaking everyone else using the same credential. You can’t tell whose traffic was whose. You can’t limit what they reach. And you have no idea how many copies of it now exist. Every one of those becomes a real problem eventually.

Three principles that fix it

The first principle is per-person credentials. Every human who touches your lines gets their own username and password, created for them, used by nobody else. This costs you 5 minutes at setup and it’s what makes everything else on this list possible. If your provider only issues one credential per line and won’t create more, that’s a genuine limitation worth raising with them, because it’s a normal requirement.

The second principle is least privilege: they get access to the lines they need and not the rest. If someone is managing 4 accounts, they need the exits those 4 accounts sit on. They don’t need the whole pool. This feels needlessly restrictive when you’re setting it up with someone you trust, and it’s the thing that limits the blast radius when a laptop gets stolen or a contract ends badly.

The third is that access has to be revocable in one action. You should be able to disable a person’s access completely without touching anyone else’s setup, without changing credentials that other people are using, and without a maintenance window. If revoking one contractor means rotating a password that 4 other people also use, you’ll delay doing it, and delayed revocation is how most of this actually goes wrong.

Username and password vs IP whitelisting

There are two ways to authenticate to a proxy, and the choice matters more for contractors than for your own jobs. Username and password auth travels with the person, so it works from wherever they are, which is convenient and is also exactly why it’s copyable. IP whitelisting ties access to a location, which is much harder to leak, and is a nuisance the moment your contractor’s connection changes.

That nuisance is worth understanding before you choose it. Most residential connections hand out a dynamic IP, and it changes on a router reboot, a line fault, or the provider’s own schedule. An IP-whitelisted contractor will lose access at some point, usually at an inconvenient hour, and you’ll be the one who has to update it. If you go this route, expect that and decide in advance who can make that change.

The arrangement that works well for a lot of people is both: username and password auth so the credential is per person and revocable, plus a whitelist restricting where that credential can be used from, if the contractor’s connection is stable enough to support it. You get attribution from one and location binding from the other, and losing either alone doesn’t hand over access.

What not to hand over

The modem admin interface is top of the list. A contractor needs an exit, not the ability to reboot hardware, change the APN, read the SIM details, or see every other line on the same box. That panel is infrastructure control and it belongs to whoever owns the infrastructure. The same goes for your provider account dashboard, where someone can change plans, see billing, and read every credential you have.

Rotation control is the subtler one. If your setup lets a user trigger an IP change, think about whether that person needs it. Someone running long-lived accounts on sticky sessions almost certainly shouldn’t be able to rotate the exit under those accounts, because a rotation at the wrong moment is exactly the event that gets an account challenged. Give it only to people whose work actually requires it.

Bandwidth limits and logging

Bandwidth limits per user are worth setting even when you trust everyone completely, because the reason to have them isn’t dishonesty. It’s the script that goes into a retry loop overnight, or the job that starts pulling video assets nobody intended it to pull. A cap comfortably above normal usage turns a surprise bill into an alert, and it costs nothing to configure.

Logging per user is the whole reason to bother with per-person credentials in the first place. You want to be able to answer, later, which credential was in use when something happened. Not the content of the traffic, which you neither need nor want, but the basic attribution: who was connected, from where, when, and how much. That’s enough to reconstruct almost anything you’ll actually need to reconstruct.

Keep one contractor on one set of exits

Hold one contractor to one set of exits and don’t overlap them with anyone else. Two people working through the same exit at the same time, from different countries, on different schedules, is a pattern that looks strange from the outside regardless of what they’re doing. Keeping the mapping clean is better for the accounts and it also makes your logs mean something.

That same logic extends to hours. If your contractor works in a different timezone from the accounts they manage, that’s a mismatch worth thinking about rather than ignoring. Sticky sessions on the right geography help, but they don’t change when the activity happens, and consistency of behaviour over time is what most platforms are actually watching.

Profiles and remote machines

There’s a layer above the proxy that’s often the better answer: the antidetect browser. If the contractor works inside a profile you created, with the proxy already configured in it, then what you’ve handed over is a profile rather than a credential, and the proxy details never appear on their screen at all. Team features in those tools exist precisely for this, and they revoke cleanly.

A step further is not giving them access to your network at all, and instead giving them a machine. A remote desktop or a small VPS that already has the profile and the proxy configured, which they log into and work inside. Nothing leaves that machine, offboarding is a single account disable, and you can see the state of the environment yourself. It costs more, and for higher-value work it’s usually worth it.

What this can’t do

A person with legitimate access to a working session can copy what’s on their screen, and no technical control prevents that. What these controls actually do is make access specific, attributable, and revocable, so that ordinary risks like a lost laptop, a reused password, or a contract ending are contained. They’re not a substitute for hiring carefully.

Which means the real controls are the boring ones: a written scope of what the person is meant to do and with what, an agreement that says what happens to access and data at the end, and a relationship where asking for something outside the scope is a normal conversation rather than a confrontation. I’d rather have a clear contract and modest technical controls than the reverse.

Offboarding, step by step

Offboarding deserves an actual checklist rather than good intentions, because it’s the step that gets skipped when someone leaves on good terms. Disable their proxy credential. Remove their IP from any whitelist. Revoke their access in the browser or profile tool. Rotate any account credentials they held, which is a different job from the proxy side. Note the date in your records, so you know when their access ended if a question comes up later.

Then decide what happens to the exits they were using. If the work is continuing with someone else, the accounts should generally stay on the same exits, because moving them is a change the platform notices. If the work is stopping, retire the assignment in your records rather than reassigning those lines to something unrelated the next day. Continuity is worth more than tidiness here.

What to watch for

What to actually watch, day to day, is less than people expect. Usage per credential against its normal baseline. Connections from unexpected locations if you’re not whitelisting. And any credential still active for someone who’s no longer working with you, which is the most common finding in any access review anyone has ever done. A quarterly look at who has access to what catches nearly everything.

Buying separate access, and the handover moment

A question that comes up often enough to answer directly is whether to just buy the contractor their own proxy access rather than sharing yours. Sometimes that’s genuinely the right call, particularly for work that doesn’t touch your existing accounts. But if the accounts are yours and they’ve been running on a particular exit for months, moving them onto a new provider’s IP because it’s administratively simpler is trading a small convenience for the exact change those accounts are most sensitive to. The exit should follow the account, not the person.

Related to that, be careful about the handover moment itself. The highest-risk window in this whole arrangement isn’t the months of steady work, it’s the day the account changes hands, because that’s when the login pattern, the device, the working hours, and sometimes the exit all shift at once. Stagger those changes if you can. Let the new person work from the same exit and the same profile for a while before anything else moves, and keep the old access active but unused for a few days rather than cutting it the same hour.

Document it, and never paste credentials in chat

There’s a documentation angle worth mentioning too, because it saves a lot of pain. Write down, for each person, what they have access to and when it was granted, and keep it with your line records rather than in your head. It takes a minute per person and it turns your quarterly access review from an investigation into a read. It also means that if you’re ever the one who has left, or is unavailable, someone else can actually work out what needs to be shut off.

And one on communication, since this is where the leaks actually happen. Credentials don’t go in chat messages, email, or a shared document, because all three persist and none of them are under your control. Use a password manager that supports sharing, or a one-time secret link, and send the connection details separately from whatever they need to actually log in. It’s a 30-second habit and it removes the single most common way this stuff ends up somewhere it shouldn’t.

If you want lines that make this straightforward, we run real SG mobile IPs out of physical hardware, with sticky sessions that hold a profile to one exit instead of rotating out from under it, and DNS that routes through the tunnel so you’re not leaking a resolver that contradicts the exit you’re presenting. Take a look at Singapore Mobile Proxy to see how the setup works.

Get new guides and videos first — join the Telegram channel.