Most enterprise portals don't just check who's logged in—they check where the request came from. A bank's vendor portal, a hospital's referral system, or an internal SaaS admin console will often flag or block a login the moment it shows up from an unfamiliar IP range, even with valid credentials. That's a sensible control when the goal is stopping account takeover. It's also the first thing that breaks when a browser automation job runs from whatever IP its infrastructure happens to hand out that day.
Network Identity Is Part of Identity
Security teams build allowlists around the traffic they expect: a known office range, a corporate VPN exit node, a specific country or region tied to where an employee actually works. An automated session that authenticates correctly but originates from a rotating, unrelated IP looks exactly like the anomaly those controls exist to catch. For teams running agents against authenticated enterprise portals, network routing isn't a workaround for those controls—it's how automation traffic stays inside them.
Consistent Geography, Not Random Egress
Anchor's built-in proxy lets a session route through a specific country, region, and city instead of an arbitrary egress point, so traffic to a given portal consistently looks like it's coming from the same place every run:
const session = await anchorClient.sessions.create({
session: {
proxy: {
active: true,
type: 'anchor_proxy',
country_code: 'us',
region: 'ca',
city: 'san-francisco',
},
},
});That predictability matters more than raw IP diversity for enterprise work. A vendor portal that expects a regional office to log in from the Bay Area doesn't care how many other IPs exist in Anchor's network—it cares that this session looks like the same regional office it saw yesterday.
Routing Through Infrastructure Security Already Trusts
Some portals aren't looking for "a plausible location"—they're allowlisted down to a specific corporate proxy or VPN egress range, and nothing outside it gets through. For that case, Anchor's Bring Your Own Proxy lets a session route through infrastructure a security team has already approved, over HTTP, HTTPS, or SOCKS5:
const session = await anchorClient.sessions.create({
session: {
proxy: {
active: true,
type: 'custom',
server: 'https://proxy.company-internal.com:443',
username: process.env.CORP_PROXY_USER,
password: process.env.CORP_PROXY_PASS,
},
},
});The session's traffic exits through the same proxy a human employee's laptop would, which means the automation shows up on the allowlist a network team already maintains instead of asking for a new exception.
Network Routing Is One Layer, Not the Whole Control
Where a session's traffic originates is one piece of a larger governance picture that also includes per-portal identities for credentials and session recording for audit—network routing determines whether the request reaches the portal at all; identity and recording determine what a compliance review can verify once it does.
If your team is routing automation traffic through whatever egress an infrastructure vendor happens to assign, that's the gap a network layer built for enterprise portals is meant to close. Anchor gives each session a network identity a security team can recognize and approve in advance. Get an API key and route your next authenticated session the way your network policy already expects.
