How to give a VA system access without exposing the business
Give a VA the narrowest role that covers their actual job, enforce it on the backend rather than by hiding tabs, and rotate every credential when they leave.
Last reviewed 5 min readSupplyForge LLC
Limit a virtual assistant by giving them a role scoped to one job — research, purchasing, outreach or bookkeeping — and enforcing that scope on the server, not in the interface.
Most Amazon wholesale sellers hand a first VA the whole system because splitting it up looks like work, then never revisit the decision. The exposure that follows is rarely theft. It is a research assistant reading landed cost on every SKU, and an offboarding that is one password change, three weeks late.
Research VA versus purchasing VA: what each job needs
A research VA and a purchasing VA need close to opposite halves of the system. Research needs catalog rows and marketplace data with no financial history attached; purchasing needs costs, terms and documents with no reason to touch outreach or accounting. One shared role hands each of them a second job's worth of access.
| Role | Read and write | Read only | Should not reach |
|---|---|---|---|
| Research VA | Catalog rows, bulk scan, products | Organizations and account status | Purchase orders, profit and loss, integration settings |
| Outreach VA | Contacts, pipeline, sequence drafts, dialer queues | Organization and maturity research | Cost and margin fields, purchase orders, integration settings |
| Purchasing VA | Purchase orders, attachments, supplier documents | Inventory forecasts, wholesale costs | Profit and loss, bank connections, integration settings |
| Bookkeeper | Settlement imports, profit and loss, accounting | Purchase orders and landed cost | Email sending, dialer, catalog, integration settings |
| Investor | Nothing | Investor dashboard and pipeline | Everything else |
Forge Command ships two main roles, admin and staff/VA, plus a separate investor role that only sees an investor dashboard, with per-tab permissions enforced on the backend. The matrix above is the target you configure with those permissions, not a set of preset job titles. Write it down before the invite goes out, because the instinct at invite time is to grant everything and trim later, and nobody trims later.
Hiding a tab is not a permission
Hiding a tab in the interface is not a permission, because the interface is not the only way in. Forge Command serves the same API to five clients: the web app, a desktop app, an iOS app, the Forge Analyzer Chrome extension, and the fc command-line tool. A session that can read a row through one of those can read it through the others, and anyone who opens browser developer tools can call an endpoint the navigation bar does not show. That is why Forge Command enforces per-tab permissions on the backend rather than only hiding menu items.
Offline sync sharpens the point. Forge Command mirrors read paths into the browser with PowerSync so list views work from a local copy, which means data that reaches a client is data the assistant holds after you close the account.
Row-level security separates tenants, not teammates
Row-level security keeps your company's data away from another company's data, and it does nothing about your purchasing VA reading your profit and loss. Forge Command connects to PostgreSQL as an RLS-enforced database role rather than a superuser, so tenant isolation holds in the database itself. Inside one tenant, every staff member sits on the same side of that wall.
Sellers routinely conflate the two and assume a vendor's isolation architecture also governs their own staff. Tenant isolation is a vendor property; staff separation is a configuration you own. What multi-tenant data isolation means for your business data covers the first; this page covers the second.
The credentials behind the settings screen
Integration settings is the highest-value screen in the system and should stay admin-only, because the credentials stored there control accounts outside Forge Command entirely. Forge Command holds every tenant's own API keys encrypted at rest with Fernet, which protects them at the storage layer, not from a staff member with legitimate access to that screen.
The integration settings screen reaches the Amazon SP-API authorization for your selling account, a Keepa key whose lookups spend your own paid tokens, the Gmail accounts the email engine sends through, QuickBooks, and a Plaid bank connection. Deleting a Forge Command login undoes none of them. Why bring-your-own API keys matter in seller software explains why those keys are yours in the first place.
The offboarding checklist most sellers never run
Offboarding an assistant is a credential job, not an account job. Revoking the login is step one of eight, and the remaining seven get skipped because nothing visibly breaks.
- Revoke the login before the conversation, not after it.
- Rotate the Amazon SP-API credentials and the Keepa key if the assistant ever reached integration settings.
- Disconnect any Gmail account the assistant connected, and check the email engine's account list for an unfamiliar mailbox.
- Change supplier portal passwords, including any stored for a website-login supplier integration.
- Remove the assistant from the Slack or Discord workspace connected to Forge Command.
- Reassign open tasks and saved dialer queues, which persist in the database.
- Ask what was exported. Google Sheets exports, CSV downloads and S3 documents leave with the person.
- Review the last week of pipeline stage changes and organization edits.
Steps 2 and 7 matter most and are the ones nobody runs. A rotated key ends future access; an export already happened.
What a per-tab permission model cannot do
A per-tab model draws its lines around screens, so it cannot express "show this person the ROI verdict but not the cost behind it." Forge Command's documented model is role-based with per-tab permissions enforced on the backend, plus sub-user privacy controls. If your plan depends on hiding one field from one person inside a screen they may open, confirm it works before you rely on it.
Salesforce Sales Cloud is genuinely ahead here: field-level permissions, full sandboxes and audit trails govern one field at a time, a different class of control from one tab at a time. Forge Command publishes no SOC 2 or ISO certification and no formal SLA. Over-tight roles also carry a cost — an assistant who pings you twelve times a day is a worse outcome than one extra tab.
Frequently asked questions
Should each VA get their own login
Yes, always. Contact records hold the full history of every email, call, task and deal, and notes carry a visible source label — all of it meaningless when three people share one account.
Can a VA see my profit numbers
That depends on which tabs the role can open. Profit and loss, settlement imports and bank connections are separate modules from catalog rows, so a research VA can have catalog access without financial access. See how to delegate wholesale product research to a VA.
What about data already synced to a VA's browser
Data that reached a client is a copy the assistant holds. Forge Command mirrors read paths to the browser for offline list views, so revoking a login stops future reads without retrieving anything already downloaded.
Which tab should a VA never get
Integration settings. Every other screen exposes business data; that one exposes credentials to systems outside Forge Command, including your Amazon authorization and bank connection. Purchase orders rank second, because a purchasing role commits money — see how to manage wholesale purchase orders for FBA.