An agent that logs into sites on your behalf arrives from a datacenter, and the sites can tell. You can now hand it your own WireGuard, OpenVPN or residential proxy, for the whole workspace, or for one identity at a time.
The problem is the address, not the agent
An AI agent that works in a browser does everything a person does, opens a site, signs in, clicks, reads, replies. What it cannot do by itself is arrive from a plausible place. It arrives from a cloud provider’s address range, which any consumer site can look up in a public database, and which no ordinary customer of that site has ever used.
That single fact produces most of the friction people blame on automation being "detected". Extra verification on login. A sign-in that works from your laptop and fails from the agent. Two accounts that should have nothing to do with each other treated as one, because both were reached from the same address.
None of that is about how convincingly the agent behaves. It is about where it came from, and it is fixed in one place rather than by making the agent act more human.
Bring your own exit
A workspace can now leave the network in one of three ways: directly, through a residential proxy you supply, or through a VPN profile you upload, WireGuard or OpenVPN, whichever your provider gives you.
You paste the provider’s config as-is. It is encrypted with a key scoped to your workspace, and no endpoint returns it, the form is empty when you reopen it because there is genuinely nothing to show, including to you.
Configs are checked against an allowlist rather than trusted. WireGuard’s PostUp and PreUp, and their OpenVPN equivalents, run shell commands on the machine that loads them; a config carrying one is refused, naming the directive it tripped on. That is a deliberate refusal of a real capability, not a parser limitation.
[Interface]
PrivateKey = <from your provider>
Address = 10.66.66.2/32
DNS = 1.1.1.1
MTU = 1280
[Peer]
PublicKey = <from your provider>
AllowedIPs = 0.0.0.0/0
Endpoint = frankfurt.example-vpn.com:51820
# Paste the file as your provider shipped it.
# PostUp / PreUp lines are refused, not run: they
# execute shell, and nothing here needs them.
One exit per account, not one per company
The interesting setting is not the workspace default, it is the override on a single browser identity. Each identity can take its own VPN profile, so the account you keep in Frankfurt is reached from Frankfurt and the one in Amsterdam from Amsterdam, while everything else goes direct.
That is the difference between "our company uses a VPN" and "these two accounts have never shared an address". For anyone running more than one presence on the same platform, the second is the only version that means anything.
The resolution order is short, and its middle step is the one people get wrong: an identity with no setting inherits the workspace default. It does not mean direct.
the identity's own setting
↓ (unset, which means inherit, never "direct")
the workspace default
↓ (unset)
direct
# At every step, if the chosen exit cannot be produced,
# the request FAILS. It never quietly falls back to ours.
It covers the API calls too
A browser session is the visible half. The other half is every outbound call your workspace makes to a third-party API: OAuth token exchange and refresh, connection tests, API-spec discovery, the MCP transport an assistant speaks over, and the tool calls themselves.
Those requests reach the same provider the browser session does. Leaving them on a datacenter address would both expose the address you are paying to hide and break any provider that ties a session to the IP that created it, the token minted from one place, used from another.
One boundary is worth stating plainly, because it is the opposite of what people assume: an integration bound to a browser identity for its cookies still takes its network path from the workspace default. Cookies from the identity, IP from the workspace.
It fails closed
If the chosen exit cannot be produced, the tunnel will not come up, the proxy is switched off, the selected profile was deleted, the request fails. There is no quiet fallback to our address.
This is the part worth insisting on. A silent fallback is the worst possible behaviour: it puts the datacenter address on the wire for exactly the workspace that is paying not to be there, at exactly the moment nobody is watching, and you find out from the other end, from the account that got flagged.
So a broken exit is loud. The card says so while collapsed, the status pill in the header turns red at any screen width, and a test that has never run reads as unproven rather than green. Green means a live test went out through that exact tunnel and came back with an address.
What a tunnel costs you
Nothing while idle. A tunnel is started when something needs it and shut down after about fifteen minutes of quiet, so there is no permanent connection to pay for and no stale tunnel left holding a route. The first request after a gap waits for the tunnel to come up, measured at about four seconds.
A word on free VPNs, since it is the first thing people try: they work for confirming the feature does what it says, and they are a poor production exit. Every user shares one address, so the sites you care about have already rate-limited it, and you do not get to choose a country. A dedicated exit exists precisely to not be shared.
Questions and answers
Does this hide that an AI agent is doing the work?
No, and it is not meant to. It changes where the traffic comes from, not what the agent does or discloses. What it removes is a mismatch that has nothing to do with the work: a real account, operated on your behalf, arriving from an address no customer would ever use.
WireGuard or OpenVPN?
Both work; paste whichever your provider gives you. WireGuard connects faster and its config is a dozen lines, which is why most providers now lead with it.
Can I use a different country per account?
Yes, that is what the per-identity override is for. Upload one profile per exit, then point each browser identity at the one it should use. A workspace holds up to five profiles.
What happens to my running browser sessions when I switch?
They are rebuilt against the new exit rather than kept on the old one, the exit is part of what makes a pooled session reusable, so changing it retires the session instead of leaving it running on the address you just stopped using. Allow about a minute: the resolver caches the answer for that long, so a session already in flight can finish on the old exit before the new one takes over.
Who can change it?
Only a workspace owner. Members see the current state; the public viewer tier sees none of it. Changing where an entire workspace appears from is not a setting to leave open to everyone who can read the inbox.
Originally published at dialogbrain.com.
Top comments (0)