Which browser automation API should you build an agent on?

On this page

1. The question changed this year
2. Credential handling: three different postures
3. Isolation and self-hosting: where the DIY option actually helps
4. The decision
5. Three tools in this list that aren’t answering this question

• This page as Markdown

The question changed this year

Until recently, picking a browser-automation API for an agent was a speed-and-reliability question: which one clicks through a form fastest, which one survives a redesigned checkout page. That’s no longer the whole question. In August 2026, security researchers at Zenity disclosed zero-click prompt-injection attacks against ChatGPT Atlas and the Claude for Chrome extension. A single planted comment on an X thread was enough to hijack an agent’s session across every site the user was logged into, and a crafted email could turn “summarize my inbox” into a full account takeover across Gmail, Slack, and X. Neither vulnerability had an easy patch, because both exploit the thing an agentic browser is built to do: read page content and act on it across authenticated tabs (SecurityWeek).

That’s a different product category from the ten tools in our directory. Atlas and Claude in Chrome are end-user agentic browsers, not developer APIs you build your own agent on. But the underlying risk is the same one anyone shipping a browser-driving agent now has to answer for: an agent that reads a poisoned page can be turned against the authenticated session it’s holding. It’s serious enough that browser security has become its own line item: LayerX built a dedicated “AI Browsers Protection” product around exactly this threat, and Akamai paid roughly $205 million to acquire the company in 2026 (SecurityWeek; LayerX).

So the buyer question for a browser automation API is no longer just “does it complete the task.” It’s “what happens to my credentials and my session when the page it’s reading turns out to be hostile.” Here’s where the vendors actually differ on that, not on marketing copy.

Credential handling: three different postures

Skyvern is the only one built API-first for stored-credential login: page.agent.login(credential_type, credential_id) hands the agent a reference to a vaulted credential, not the plaintext value, with 2FA/TOTP support and 1Password integration from the $149/mo Pro tier up, and Bitwarden plus Azure Key Vault reserved for Enterprise. On the two cheaper tiers (Free, $29/mo Hobby) it can store credentials but has no 2FA support at all, so the login-heavy use case this tool is built for is effectively gated behind the $149 tier (skyvern.com/pricing). It’s open source under AGPL-3.0 (GitHub), which matters practically in one specific way: self-hosting and running it unmodified inside your own company carries no AGPL obligation, but if you fork it to build a hosted product on top, the license requires you to publish your modifications.

Anchor is closest to Skyvern’s posture, with the login run by the platform rather than the agent. You pass credentials as secret values and Anchor types them into the page itself. Its docs say the real values are never logged and never shown to the model, and each secret can be limited to one domain so it can’t be typed into the wrong site (Anchor docs). For accounts that have to stay signed in, an identity holds the credentials and the MFA method (email codes, an authenticator app, 1Password or your own system), and Anchor logs in again when the saved session expires (Identities). If your product acts for its own users, they sign in on Anchor’s hosted page and your app gets back an identity ID, not a password (end-user sign-in). Every browser runs in its own virtual machine, erased when the session ends (Trust & Security). The trust portal lists SOC 2 Type 2, ISO 27001, HIPAA and GDPR. The SOC 2 report is shared on request and the auditor isn’t named publicly (trust.anchorbrowser.io). On its price list the compliance line starts at the $2,000/month Growth plan, and a HIPAA BAA, bring-your-own-cloud and on-premise deployment are Enterprise items.

Browser Use doesn’t sell credential vaulting as a feature; it sells an audited security program instead. It’s SOC 2 Type II compliant, with the auditor (Accorp Partners) and the exact observation window (July 17–October 17, 2025) published rather than just claimed, and Enterprise customers can turn on zero data retention (browser-use.com/security/soc2). It’s also MIT-licensed and the single most-starred repo in this category at 116,000+ stars, with commits landing the same day this was checked, which makes it the fastest-moving codebase here if a new prompt-injection vector needs a patch (GitHub).

Browserbase takes a third approach: instead of vaulting credentials or auditing its own practices, it tries to make the agent’s traffic indistinguishable from a legitimate one. Verified sessions use real (not synthetic) browser fingerprints that its bot-detection partners recognize, and it partners with Cloudflare’s Signed Agents program so an agent can cryptographically prove a human authorized it, rather than relying on browser behavior alone to pass as human (Browserbase docs). That’s a meaningfully different security model from “hide the agent”: it’s “identify the agent honestly and let the site decide.”

Hyperbrowser publishes a security-practices page that reads like a SOC 2 report’s outline (encryption at rest and in transit, quarterly access reviews, annual penetration testing) but says it is “aligned with” SOC 2 criteria and undergoes third-party assessments without naming an auditor or a certification date (hyperbrowser.ai/security). That’s a real gap next to Browser Use’s dated, named Type II report and Skyvern’s SOC-2 report at Enterprise tier: it’s the same list of good practices everyone claims, without the one thing that lets a buyer verify it happened.

Isolation and self-hosting: where the DIY option actually helps

Playwright MCP, Microsoft’s official MCP server for Playwright, ships no managed cloud, no stealth mode, and no hosted proxy. It’s Apache-2.0 and self-hosted only (GitHub). That sounds like a gap until you apply the session-hijacking framing: there’s no vendor-run browser fleet holding your cookies, because there’s no vendor infrastructure at all. The isolation model is whatever you build (separate browser contexts, your own proxy, your own credential store), which is more work but also the only option here with zero third-party attack surface on the browser layer itself.

TinyFish sits at the other end: one API key covers Search, Fetch, a web agent, and cloud browser sessions, with residential proxies and anti-bot handling built in and billed per step ($0.016) or per browser-minute ($0.002). There are no monthly tiers: it’s a prepaid-wallet model with Search and Fetch free at any balance, and ISO 27001 plus enterprise SSO arrive only at the Enterprise tier (tinyfish.ai/pricing).

The decision

• Building a compliance-sensitive agent you’ll self-host and want full control over the credential vault: Skyvern. It’s the only one here with 2FA/TOTP and password-manager integration built into the agent loop, not bolted on, and it’s the option where “self-hosted” actually means the credentials never leave your infrastructure. Budget for the $149/mo Pro tier (the free and $29 tiers don’t include 2FA at all) and read the AGPL terms before you build a product on top rather than just running it.
• Building on someone else’s audited infrastructure with the biggest community backing you if something breaks: Browser Use. The named, dated SOC 2 Type II report is the most concrete compliance artifact of any tool here, it’s MIT so there’s no copyleft complication, and at $0.02/browser-hour it’s also the cheapest hosted option at real volume.
• Sites that actively fight bots (bank portals, airline sites, anything behind Cloudflare or Akamai bot management): Browserbase. The Signed Agents partnership is a genuinely different answer to “how do I not get blocked” than fingerprint spoofing, and Stealth Mode plus HIPAA BAA support scale up through its paid tiers.
• Agents that log in as real users, where the password must never reach the model: Anchor. The platform types the credentials in and keeps them from the model, saved identities sign back in when a session expires, and each session gets its own disposable VM. Its Action Index lets an agent finish a known step on a supported site, such as a filtered search, in one call instead of clicking through the page (Anchor docs). Plans cap concurrent browsers from 5 on the free tier to 200 on Growth, with 500+ on Enterprise.
• You’d rather own the whole security boundary yourself: Playwright MCP. No managed layer means no managed-layer risk; you inherit all the isolation work but also all the control.
• A general-purpose cloud browser without a strong opinion on any of the above: Hyperbrowser and TinyFish are credible, but neither publishes a third-party audit report the way Browser Use and Skyvern’s Enterprise tier do (TinyFish’s trust center shows an ISO 27001:2022 certificate rather than a report); treat their security pages as a starting point for your own due diligence, not a substitute for it.

Three tools in this list that aren’t answering this question

Not everything filed under browser automation here is competing for the same job. BrowserAct is a no-code scraper builder: you describe the data you want and it builds a reusable “Bot,” which bundles stealth and proxy handling but isn’t an SDK a developer drops into their own agent loop the way the five above are. Manus AI is a consumer/team action-engine where browser control is one feature among slide decks and website builders, not a browser-automation API in its own right. And Hronaut is a local desktop browser that keeps a coding agent’s login sessions alive between tasks on your own machine. It’s useful for testing an app you’re building, but its own FAQ points you elsewhere for anything that needs to run without your desktop on, which is the whole premise of the other five. None of the three are worse tools; they’re just not the answer to “which API do I build a production agent on.”

If you’re evaluating any of these for a login-heavy workflow, the SecurityWeek and Zenity research is worth reading directly before you start: the attacks that mattered in 2026 didn’t come from a weak password or a missing WAF rule, they came from an agent trusting content on a page it was never supposed to trust that much.