Anchor Browser runs cloud-hosted browser sessions for AI agents and automation. Because those sessions log into real applications and handle real data, security is part of the evaluation from the first call. This page answers the questions a security reviewer or engineering buyer actually asks, with each answer linked to its source on Anchor's documentation.

Every claim below links to a published Anchor page. Tier-specific items name the plan they apply to. Where the public pages leave a question open, this page says so rather than guessing.

Compliance and attestations

Is Anchor Browser SOC 2 compliant?

Yes. Anchor's security documentation states that Anchor has achieved SOC 2 Type II compliance, covering security, availability, processing integrity, confidentiality, and privacy controls. The pricing page lists SOC 2 Type 2 as part of the compliance set included on the Growth and Enterprise plans.

What compliance attestations does Anchor hold, and which plan do they apply to?

Anchor's security page lists four attestations:

• SOC 2 Type II. Security, availability, processing integrity, confidentiality, and privacy controls.

• ISO 27001. The international standard for information security management systems.

• HIPAA. Protection of healthcare-related data.

• GDPR. Privacy and data rights for European Union residents.

The pricing page maps these to plans. SOC 2 Type 2, ISO 27001, and GDPR are included on the Growth plan ($2,000/month) and Enterprise. BAA, HIPAA, DPA, SSO, and RBAC are listed under the Enterprise plan. For a healthcare workload that needs a signed BAA, Enterprise is the tier to confirm with Anchor.

The data-processing agreement (DPA), business associate agreement (BAA), single sign-on (SSO), and role-based access control (RBAC) are part of the Enterprise envelope per the pricing page. The SSO here covers dashboard sign-on for the Anchor account.

Data handling and isolation

Where does Anchor store session data, and how long does it keep it?

Anchor's data model is ephemeral by architecture. Per the security documentation, each browser instance runs in its own dedicated, isolated virtual machine, and that VM is permanently terminated and erased upon session completion. Browsers are never reused between sessions or customers.

Data produced during a session has two paths, both described on the security page:

• Anything accessed, generated, or downloaded transfers directly to the customer's own environment over Anchor's secure peer-to-peer channel, or

• It is irretrievably deleted along with the virtual machine when the session ends.

File downloads go straight to the customer's environment, so no file artifacts are created or stored on Anchor's infrastructure (security page).

For stored data outside the per-session VM, the pricing page sets retention by plan: 45 days on the Free and Starter plans, custom retention on Growth, and customizable retention on Enterprise, where a zero-data-retention configuration is available.

How does Anchor isolate one session from another?

Each browser instance gets a dedicated, isolated virtual machine, and the VM is destroyed when the session completes (security page). One session's environment is never shared with or reused by another session or another customer. This VM-per-session model is the isolation approach the managed-browser category treats as table stakes; Anchor's specific commitment is that the VM is terminated and erased at session end.

Credentials and authentication

How does Anchor handle credentials? Do agents have to store passwords on the platform?

Anchor's security documentation states plainly that customers are never required to store credentials on the platform. Session-based authentication is available when the goal is for credentials to exist only at runtime and never be retained.

When a team does want stored, reusable logins, Anchor provides them through an identity layer rather than asking the codebase to hold secrets:

• Secret values. Credentials pass to an agent as references that resolve only at typing time. Per the secret values documentation, real values are never visible to the AI model, are processed in memory, are excluded from logs and telemetry, and can be scoped to specific domains.

• 1Password integration. Secrets, including TOTP and 2FA codes, resolve directly from 1Password vaults at session creation, so credentials live in the customer's vault. The values are never exposed to the agent, the logs, or the responses.

• Stored identities. With OmniConnect, a credential is stored once on an identity and Anchor re-authenticates automatically when a session needs it, so the credential is entered once rather than handled on every run.

Does the AI agent ever see stored passwords?

No. Per the secret values documentation, real credential values are never visible to the AI model: they are injected at typing time, held in memory only, and excluded from logs and telemetry. With the 1Password integration, secret values resolve from the vault at session creation and are never exposed to the agent or written into responses.

How do AI agents authenticate to SaaS apps, including logins behind MFA?

Anchor's identity layer manages the full login path so the automation stays signed in across separate agent runs.

• Stored identities and automatic re-authentication. OmniConnect stores a credential once on an identity; attach the identity when creating a session and the browser starts signed in, with Anchor re-authenticating automatically when the saved state expires.

• Multi-factor authentication. Identities support authenticator-style (TOTP) credential types (credential types). Email one-time passcodes route through a dedicated mailbox per identity, so forwarded login emails have their OTP consumed automatically during identity creation, re-authentication, and live agent sessions. For codes that must come from an external system mid-run, event coordination injects them without stopping the task.

• End-user sign-in for product builders. When a customer's own users need to connect their accounts, OmniConnect's hosted flow lets the user sign in on Anchor's UI and hands the application back an identity ID, so the application never touches the end user's credentials.

This is the path to give an auditor asking how automated workflows authenticate to SaaS applications: credentials are entered once and held in the identity layer (or resolved from a vault), the model never sees the real values, and re-authentication is handled by the platform rather than by long-lived credentials sitting in application code.

What controls limit what an agent can do with sensitive data?

Two controls layer on top of the credential handling above:

• Sensitive-data masking applies across session surfaces, keeping flagged values out of the material an agent and the logs would otherwise capture (referenced in the session-logs and secret-values documentation).

• Zero-data-retention (ZDR) mode disables session video and log recording entirely for workloads where nothing may persist (ZDR mode). The pricing page notes that zero data retention is available on Enterprise.

Custom CA certificates are supported for environments that route traffic through their own certificate authority (referenced in Anchor's documentation).

Data residency and deployment

Does Anchor offer EU data residency?

Yes, on the Growth plan and above. Anchor's managed service processes and stores data in the AWS us-east-2 (Ohio) region by default, and offers dedicated European data residency in AWS eu-central-1 (Frankfurt) on the Growth plan (security page). The pricing page adds that custom regions (US, EU, Asia, Australia) are available on Growth, and any region on Enterprise.

Can Anchor run inside our own cloud or on-premise?

Yes, on the Enterprise plan. The pricing page lists bring-your-own-cloud and on-premise deployment under Enterprise, and Anchor is available through the AWS Marketplace. For a security model that requires the browser fleet itself to run inside the customer's own boundary, the Enterprise tier is where that option lives. For teams that want a managed service with regional control short of full self-hosting, the EU residency option above covers the common data-locality requirement.

What a procurement team can verify directly

Everything on this page traces to one of these published sources:

• Compliance attestations and tier placement: Anchor's security page and pricing page.

• The VM-per-session isolation and ephemeral data model: Anchor's security page.

• Credential handling and the no-stored-credentials commitment: Anchor's security page, secret values documentation, and 1Password integration.

• Authentication, MFA, and identities: OmniConnect / authenticated applications, email OTP, and event coordination.

• Data residency and deployment options: Anchor's security page and pricing page.

Published pages change over time. The verification date for the facts on this page is June 2026.