Sharing logins with a VA without handing over everything
The problem with just sending the password
The fastest way to onboard a VA is to open a chat, type out a username and password, and hit send. It works. It also means that person now has everything that account has: your billing details, your other logged-in sessions, your recovery email trail, whatever else is sitting behind that login. If the relationship ends badly, or the VA's own device gets compromised, or they reuse that password somewhere insecure, you're not dealing with a scoped problem anymore. You're dealing with a full account compromise.
I run several brands with people I've never met in person, some of whom manage posting schedules, customer replies, or content queues on tools that touch money or customer data. The instinct to just share the login is understandable, it's the path of least resistance. But it's also the same mistake people make when they give an AI agent a blanket API key instead of a scoped one. The fix in both cases is the same: figure out what the task actually requires, then grant exactly that.
What a VA actually needs access to
Before touching any sharing tool, write down the actual task. "Manage the Instagram account" is not a task, it's a role. The tasks underneath it are things like "reply to comments," "schedule posts," "check DMs for order questions." Each of those needs a different level of access, and most platforms already let you split them out if you look past the default login screen.
Most social platforms have a business or creator account layer that supports adding a team member with a role, rather than sharing the primary login. Meta Business Suite, for instance, lets you assign someone as an editor or moderator on a Page without giving them your personal Facebook password. Google Workspace has the same idea for email and Drive: you can grant delegated access to a mailbox or share specific folders instead of handing over the account password. The access is real, the person can do the job, but it's tied to their own identity and can be pulled instantly from your side without touching your own login.
Password managers over pasted passwords
For the accounts that don't have a native "add a team member" option, a shared password manager is the next best thing, and it's a real step up from a spreadsheet or a chat message. Tools like Bitwarden and 1Password support organizations with collections: you put a set of logins into a collection, add the VA as a member with access to just that collection, and they can use the login to sign in without ever seeing the plaintext password. The password autofills or copies through the app, but it's never displayed as readable text.
The part that matters operationally is revocation. When the VA's contract ends, you remove them from the organization or that specific collection, and their access to every credential in it stops immediately, without you having to change a single password. Compare that to the spreadsheet approach, where offboarding means manually resetting every account you ever shared, hoping you remembered all of them.
Separate browser profiles keep sessions from bleeding together
Logins are only half the picture. Once someone is signed into an account, the browser holds a session: cookies, saved state, sometimes device fingerprint data the platform uses to decide whether a login looks trustworthy. If a VA logs into a client's ad account on their personal Chrome profile that already has three other client accounts signed in, you get cross-contamination that can trigger security flags on the platform's side, independent of any password issue.
The fix is a dedicated browser profile per account or per client. Chrome, Firefox, and Edge all support multiple profiles natively, each with its own cookie jar and session state, and switching between them takes a click. For people managing several client accounts on platforms that are sensitive to multi-account activity, this is also the reason antidetect browsers exist commercially, they give each profile its own isolated fingerprint rather than just isolated cookies. You don't need that tooling for a single VA managing a single client's accounts, but the underlying principle, keep sessions separated by identity, applies at every scale.
Email access without the inbox password
Email is where people get the sharing model most wrong, because it feels like there's no alternative to "here's the password." There usually is. Gmail has a "Grant access to your account" setting under Accounts and Import that lets another Gmail address read and send from your inbox without ever knowing your password. Google Workspace admins can grant delegated mailbox access the same way, scoped per user, revocable from the admin console in seconds. Outlook and Microsoft 365 support a similar delegate model through shared mailbox permissions.
The practical benefit isn't just security theater. It means the VA logs in with their own credentials, their own 2FA, their own device fingerprint, and your account's security settings never have to change to accommodate them. If you must fall back to a shared inbox password because a platform doesn't support delegation, route that through the password manager collection, not a message.
Two factor authentication is where shortcuts happen
This is the part people skip because it's the most annoying to solve properly. If an account has 2FA tied to your personal phone, a VA literally cannot log in without texting you a code every time, which defeats the point of delegating the task. The common workaround, turning off 2FA to make sharing easier, is the wrong direction; it removes protection instead of routing it correctly.
Better options exist depending on the platform. Some services let you register a second authenticator device or a second phone number as a valid 2FA method, so the VA has their own code generator instead of needing yours. Password manager organizations that support TOTP storage let the shared collection include the 2FA seed alongside the login, so the code generates inside the same access-controlled app the password lives in. Neither of these is a full workaround for every platform, some genuinely only support a single 2FA device, and in that case the honest answer is that account isn't a good candidate for VA delegation without you staying in the loop for logins.
The same problem shows up with AI agents
If you've wired an AI agent into any real tool, whether that's a coding assistant with shell access or an MCP server connected to email and calendar, this is the exact same design question wearing different clothes. A blanket API key or an agent with unscoped tool access is the digital equivalent of texting someone your master password. The better pattern, scoped permissions, read versus write separation, per-tool access that can be revoked without rotating every credential, is the same discipline whether the thing on the other end of the access grant is a person or a model. I've had to walk this back myself on automation that started with "just give it access to everything" and ended up needing tighter scoping once it was actually running unattended in production.
A working checklist
Before sharing anything, ask three questions. Does this platform support a team member role instead of a shared login. If not, can the credential live in a shared password manager collection instead of a message. And does the account's 2FA support a second registered device, or does it force you to stay the single point of login.
Handle those three, and most of the "just send them everything" instinct disappears. The VA still gets full functional access to do the job. You just get to keep the ability to turn it off with one click instead of a password reset tour across every service you use.
If you want more of this kind of breakdown on running real tools and real automation without the hype, check out the [home page](/).
Get new guides and videos first — join the Telegram channel.