Last updated: July 2026.

The automation itself is finished. It signs into the vendor portal, pulls the report, files the records, and it has done so reliably in staging for weeks. Then the security review that stands between staging and production comes back with findings, and the rollout stops. The questions are about where session data lives, who holds the credentials, what the AI model driving the browser can see, and what record would exist if something went wrong. Nobody chose the browser setup with those questions in mind, so nobody has clean answers.

This page lays out what the review is actually asking, why answers assembled around a self-managed browser fleet take so long to produce, and how managed browser infrastructure answers each question with a control the reviewer can verify at a published source.

The five questions behind the block

Security reviews of browser automation converge on the same set of questions, because the risk model is the same everywhere: an automated browser holds real credentials and touches real data on infrastructure someone has to vouch for.

1. Where do the credentials live, and what would an attacker who compromised the automation obtain?

2. What does the AI model see when the automation types a password or reads a page of customer records?

3. Where does session data go, both while the session runs and after it ends: the pages loaded, the files downloaded, the cookies and storage accumulated?

4. What audit trail exists when someone asks what the automation did on a given day?

5. Does the vendor's posture transfer: certifications, a data processing agreement, residency options, documents the reviewer can file with the assessment?

On a self-managed fleet, each answer has to be constructed: a secrets manager here, a recording pipeline there, a retention policy nobody has written down. Every piece is buildable, and together they amount to a security-engineering project standing between a working automation and production.

The category with these answers built in: managed browser infrastructure

There is a class of infrastructure built for exactly this evaluation: cloud browsers that agents and automations drive through an API, where session isolation, credential handling, data retention, and the run record are properties of the platform, with documentation a reviewer can read directly. Anchor Browser is browser infrastructure in this category, built for computer-use agents and authenticated automation. Here is how it answers each of the five questions, with the sources.

Where session data lives, and for how long

Per Anchor's security documentation, every browser session runs in a dedicated, isolated virtual machine, and that VM is permanently terminated and erased when the session completes. Browsers are never reused between sessions or between customers. Data produced during a session takes one of two paths: it transfers directly to your environment over a peer-to-peer channel, or it is destroyed with the VM. File downloads transfer directly, so no file artifacts are created or stored on Anchor's infrastructure.

For artifacts retained outside the per-session VM, such as recordings, 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 listed. Zero-data-retention mode disables video and log recording entirely for workloads where nothing may persist.

Data residency

Anchor's managed service runs in AWS us-east-2 (Ohio) by default, with dedicated EU data residency in AWS eu-central-1 (Frankfurt) available on the Growth plan (security page). The pricing page extends the options: custom regions across the US, EU, Asia, and Australia on Growth, and any region on Enterprise.

When the requirement is stronger than residency and the browsers themselves must run inside your boundary, the Enterprise plan includes bring-your-own-cloud and on-premise deployment (pricing page), and Anchor is available through the AWS Marketplace.

Where credentials live, and what the model can see

Anchor's security documentation states that customers are never required to store credentials on the platform; session-based authentication is available when credentials should exist only at runtime. When a team does want stored, reusable logins, three controls govern them:

• The model never sees the values. Credentials pass to the agent as secret values: references that resolve only at the moment of typing. Real values are never visible to the AI model, are processed in memory and never persisted, are excluded from all logs and telemetry, and can be scoped to specific domains.

• Secrets can stay in your vault. The 1Password integration resolves credentials, including one-time codes, from your vaults at runtime. Anchor stores the service-account token for the integration; the secret values themselves are never exposed to the agent, the logs, or API responses.

• A credential is entered once, in one place. Identities hold a credential once and re-authenticate automatically when a session needs it, which ends the pattern of the same password accumulating in scripts, CI variables, and shared notes across the team.

The record of what the automation did

Every session records to MP4 by default, with recordings listed, fetched, and deleted through the API and surfaced in the session-history dashboard. Running sessions stream a live view for real-time review. Sensitive-data masking can be enabled per session; once active, it automatically detects and masks passwords, email addresses, phone numbers, and payment fields in recordings and live views, with custom selectors and patterns for anything site-specific.

For the opposite requirement, workloads where the recording itself is the exposure, ZDR mode turns video and log recording off entirely.

Whether the vendor's posture transfers

Anchor's security page states SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliance. The pricing page maps the set to plans: SOC 2 Type 2, ISO 27001, and GDPR on Growth and Enterprise; BAA, HIPAA, DPA, SSO, and RBAC on Enterprise.

The documents a reviewer files with the assessment live on Anchor's trust center: the SOC 2 reports, a security whitepaper, the data processing agreement, a subprocessors list, and the information-security and data-handling policies, with access requestable for the private items. Service status is public at status.anchorbrowser.io.

Hand this to your reviewer

The shortest path to restarting a blocked rollout is giving the reviewer sources they can verify on their own:

• Trust center — certifications and requestable documents (SOC 2 reports, security whitepaper, DPA, subprocessors list, policies)

• Security documentation — session isolation, the ephemeral data model, credential policy, residency

• Secret values — what the AI model can and cannot see

• ZDR mode — the no-persistence configuration

• Pricing page — retention, residency, and compliance terms by plan

• Status page — live service status

Frequently asked questions

Where does browser session data live? In a dedicated virtual machine that exists only for that session. When the session ends, data either transfers directly to your environment or is destroyed with the VM (security documentation). Retained artifacts like recordings follow plan-level retention terms (pricing).

Can we keep session data in the EU? Yes. EU residency in AWS eu-central-1 (Frankfurt) is available on the Growth plan, with custom regions on Growth and any region on Enterprise (security page, pricing).

Does the AI model ever see our credentials? No. Secret values resolve at typing time, stay in memory, and are excluded from all logs and telemetry. With the 1Password integration, values resolve from your vault and are never exposed to the agent, the logs, or API responses.

Can the browsers run inside our own cloud? On the Enterprise plan, yes: bring-your-own-cloud and on-premise deployment are listed on the pricing page, and Anchor is available through the AWS Marketplace.

What can our security team verify without a sales call? The trust center for certifications and documents, the security documentation for the isolation and data model, the per-feature docs linked above, and the status page for live service health.