Integration2 min read

Naïve supports Browserbase for Agent Browser Automation

Naïve supports Browserbase for agent browser automation — cloud browser sessions via /browser on one governed identity, with signup, login, and vault-backed credentials.

Read the docs →

Integration
TL;DR
  • Naïve supports Browserbase for Agent Browser Automation `/browser` runs cloud sessions on Browserbase under Naïve's operator credentials
  • Agents navigate, act, extract, and screenshot plus autonomous signup and login with passwords vaulted server-side
  • Your agents never hold a Browserbase API key; Naïve scopes every session to a tenant user and Account Kit
  • Domain-allowlisted sessions, approval gates on sensitive flows, and a live dashboard stream for human takeover
  • Consolidate no-API workflows with cards, email, KYC, and vault on the same governed profile

Many products your agents need still have no API — only a signup form, a login page, and a dashboard built for humans. Naïve is the autonomous company infrastructure that closes that gap, and Naïve supports Browserbase for Agent Browser Automation through /browser: real cloud browser sessions your agents drive on the same governed identity that sends email and spends from a card.

What /browser gives you

Naïve runs browser workloads on Browserbase under operator credentials your agents never see:

  • Step-by-step control — navigate, act, extract, observe, and screenshot inside a scoped session.
  • Autonomous signup and login — the agent completes account creation or re-authentication; credentials are stored in /vault, not in prompts.
  • Per-user isolation — every session belongs to one tenant user via naive.forUser().
  • Execution-time permissions — Account Kits decide whether the agent may open a session, sign up, or write to a page at all.
  • Human in the loop — stream the session live and take over for CAPTCHAs or SSO when automation stalls.

This is the Company → Employee → Primitive model applied to the open web: the browser is a primitive on the profile, not a standalone Browserbase project with its own API key and billing silo.

Why consolidate on Naïve instead of a raw Browserbase key

A direct Browserbase integration scopes browser sessions only. Under Naïve, the same tenant user that browses also owns KYC status, virtual cards, inboxes, and secrets — with one audit log and one revoke path. Your SaaS agent becomes one product surface instead of stitching vendors by hand.

If you are migrating from a standalone Browserbase integration, the Browserbase migration guide shows the object map and honest gaps.

Where to go next

Frequently Asked Questions
What does it mean that Naïve supports Browserbase for agent browser automation?+
Naïve's `/browser` primitive provisions cloud browser sessions backed by Browserbase. Your agent drives the page step by step — or runs autonomous signup and login — while Naïve owns the upstream credentials, scopes the session to one tenant user, and logs every action on the same identity that owns cards and email.
Do I need my own Browserbase account?+
Not for the Naïve `/browser` path. Naïve configures Browserbase server-side and bills browser actions in platform credits. You integrate through Naïve's API, CLI, or MCP — not by embedding Browserbase keys in your agent runtime.
How is browser automation governed?+
Sessions are domain-allowlisted by default, gated by Account Kits, and can require approval for signup or other sensitive flows. Passwords from signup/login land in `/vault` — they never cross the model boundary. You can watch and take over a live session from the dashboard when a human step is needed.
What if I already integrate Browserbase directly?+
The Browserbase migration guide maps their session model to Naïve's `/browser` primitive and lists features that do not map one-to-one — read it before you cut over production traffic.
NT
Naïve Team

Building the autonomous company infrastructure.

Keep reading