Enterprise Browser Environments Explained: Isolation, Identity, and Governance

Technical Dive
Jul 27
by Idan Raman
Isolation, Identity, Governance

Every enterprise team piloting browser agents eventually asks the same three questions before they'll approve a production rollout: Is one agent's session isolated from another's? Can we control which identity the agent logs in as, and revoke it later? And can security sign off on where session data goes? Isolation, identity, and governance are not separate concerns bolted onto browser automation—they're the three properties that decide whether an agent is allowed anywhere near production traffic at all.

TL;DR:

  • Isolation means each browser session runs in its own disposable environment, not a shared browser process reused across tasks or tenants.
  • Identity means the agent authenticates as a specific, controllable account—not a hardcoded credential buried in a script.
  • Governance means every session is auditable, encrypted, and disposed of according to a policy your security team actually reviewed.
  • Skipping any one of the three turns a useful agent into a liability the moment it touches a regulated system.

Isolation: one session, one machine

The naive way to scale browser automation is to keep a browser process warm and route new tasks through it to save on cold-start time. It also means every task inherits whatever cookies, cache, and local storage the last task left behind—a quiet path to cross-tenant data leakage that's hard to catch in code review because nothing looks wrong until two customers' sessions collide.

In Anchor, every browser session runs in its own dedicated, ephemeral virtual machine that is provisioned for that session and permanently terminated and erased when the session ends. There's no shared browser process to reuse and no leftover state to inherit, so isolation is a property of the infrastructure rather than something each workflow has to enforce for itself.

Identity: profiles vs. managed authentication

Once sessions are isolated, the next question is who the agent is when it lands on a page. Anchor supports two models, and picking the right one matters for governance later.

Browser profiles capture cookies, local storage, and cache from a session so a future session can start already signed in. You create one by logging in manually once and persisting the result:

curl -X POST https://api.anchorbrowser.io/v1/sessions \
  -H "Content-Type: application/json" \
  -H "anchor-api-key: YOUR_API_KEY" \
  -d '{
    "browser": {
      "profile": { "name": "billing-portal", "persist": true }
    }
  }'

Profiles are simple, but they don't re-authenticate on their own—if the target site expires the session, someone has to log in manually again.

Identities, defined through Anchor's Applications + Identities model, go further: an identity stores credentials for a specific account against a specific application, and Anchor re-authenticates automatically when needed, including built-in handling for email OTP, TOTP, and other MFA flows. That's the model that scales to a fleet of agents each acting under a named, auditable account rather than a credential copy-pasted into a script.

Governance: compliance, audit, and control

Isolation and identity give you a system that behaves correctly. Governance is what lets a security team verify that, and revoke access when they need to. Anchor's infrastructure is SOC 2 Type II, ISO 27001, HIPAA, and GDPR aligned, with data encrypted at rest (AES-256) and in transit (TLS 1.2+), and session data delivered directly to the customer rather than retained on Anchor's infrastructure by default.

Day-to-day, governance shows up as smaller controls: session tags for organizing and tracking activity across a fleet of agents, Zero Data Retention mode for workflows where even video and log recording of a session is out of scope, and sensitive-data masking that automatically detects and redacts passwords, emails, and card numbers before they hit a log. None of these are exotic—they're the same controls a security review would ask for from any vendor touching production credentials, applied to browser sessions specifically.

Why all three have to hold at once

None of these properties substitutes for the others. Perfect isolation with a shared, un-auditable login is still a compliance gap. A clean identity model on infrastructure that keeps indefinite session recordings is still a data-retention problem. Enterprises adopting browser agents are learning to evaluate the environment underneath the agent as carefully as the agent's own logic—and that's exactly the layer Anchor is built to own, so your team can focus on what the agent does, not on whether the environment it runs in would survive a security review.

Ready to see it in production? Start a free Anchor Browser session and spin up an isolated, identity-aware environment in minutes.

Stay ahead in browser automation

We respect your inbox. Privacy policy

Welcome aboard! Thanks for signing up
Oops! Something went wrong while submitting the form.