BrowserAct: Browser Modes, Pricing, Privacy Risks, and Evaluation

Full Guide

Kingy verdict: BrowserAct combines a hosted workflow product with an agent-oriented browser CLI, isolated sessions, profiles, proxies, trace capture and human takeover. That is a credible toolkit for authorized browser work, but stealth features and reusable profiles make governance part of the product evaluation—not an afterthought. Start with read-only targets, separate credentials by workflow and require confirmation for consequential actions.

What BrowserAct actually offers

BrowserAct’s current documentation separates two surfaces. Agent CLI gives coding agents commands for browser control, sessions, profiles, screenshots and network evidence. The hosted Workflow product provides a visual automation path for repeatable web tasks. Documentation also describes local and remote browser modes, session isolation, managed proxy options, browser profiles, remote assistance and capture of network or HAR-style evidence.

The public BrowserAct skills repository packages instructions for compatible agents and is MIT licensed. That open repository should not be confused with the complete hosted service: managed browsers, proxies, stored workflow configurations and extracted results remain provider-operated services. Buyers should inventory which component runs locally, which data reaches BrowserAct and which credentials are persisted in a profile.

The security and policy boundary

Browser automation can cross from observation into transaction. BrowserAct’s repository describes confirmation gating for sensitive operations and a human-handoff path, both useful design signals. Its terms also put responsibility on customers to follow law, target-site terms and robots policies and restrict unauthorized handling of sensitive personal information. A successful browser action is not evidence that the action was authorized.

The privacy policy says the service can process account information, workflow configurations, extracted data and query logs, with retention depending on the plan and use. Before saving an authenticated browser profile, teams should confirm data region, encryption, deletion, employee access, incident response, sub-processors and whether session recordings or network traces contain secrets. Give separate service accounts to separate jobs; do not let an exploratory agent inherit an employee’s broad browser session.

Pricing and operating cost

BrowserAct meters work with credits and separately prices or meters some browser and proxy resources. The live pricing page is the authority because allowances and unit rates can change. Total cost depends on workflow steps, retries, page volume, browser mode, proxy traffic, profile persistence and the model driving the agent. Test a fixed task pack and record successful outcomes per dollar instead of comparing headline credits alone.

How Kingy would evaluate it

Use a sandbox account and three bounded tasks: collect public product fields, navigate an authenticated test application without changing state, and complete a reversible form only after explicit human approval. Score success, recovery from layout changes, evidence quality, request volume, proxy usage, time, cost and unwanted actions. Compare local and hosted modes under the same task pack.

Then test failure paths: a prompt-injection string on a page, a misleading download, an unexpected login challenge, a revoked credential, cross-session data leakage, proxy-region mismatch, takeover during a pending action and deletion of stored profiles and results. Reconcile logs with the target system. Kingy reviewed the official product, documentation, pricing, repository, terms and privacy policy; we did not run BrowserAct or authorize it against a live account.

Primary sources

• BrowserAct product site
• BrowserAct documentation
• BrowserAct pricing
• Official BrowserAct skills repository
• BrowserAct terms of service
• BrowserAct privacy policy