Migrating from Browserbase to Naive

• The session lives behind a BROWSERBASE_API_KEY + project ID, its own console, and its own billing — disconnected from wherever the agent’s email, cards, secrets, and KYC live.
• The interesting workflows — sign this agent up for a SaaS, then log it back in later — are yours to build: you generate the password, you decide where to store it, and you own the risk of it leaking. Browserbase persists cookies via Contexts; it does not vault the credential itself.
• “Who let this agent create an account, and what else can it touch?” is answered in Browserbase for browser sessions, and in unrelated systems for everything else. The session has no shared accountability with the rest of the agent’s footprint.

• The tenant user that owns the session is the same user that owns its email inboxes, its cards, its vault secrets, and its KYC.
• Autonomous signup generates a strong password, fills the form, and vaults { email, password } server-side under that identity — the password never reaches your code or the model. A later login reads it back the same way.
• Whether an agent may browse at all — which domains, whether it can submit forms, whether creating an account freezes for human approval — is decided by that user’s Account Kit and the session’s allowlist at execution time.

​

Concept map

​

Before / after: the core path

import { Stagehand } from "@browserbasehq/stagehand";
import { z } from "zod";

// Browserbase account key + a separate LLM key for Stagehand
const stagehand = new Stagehand({
  env: "BROWSERBASE",
  apiKey: process.env.BROWSERBASE_API_KEY!,
  projectId: process.env.BROWSERBASE_PROJECT_ID!,
  model: "openai/gpt-4.1-mini", // your own model credential
});

await stagehand.init();                       // opens the cloud session
const page = stagehand.context.pages()[0];    // a Playwright page over CDP

await page.goto("https://news.ycombinator.com");
await stagehand.act("click the first story link");

const data = await stagehand.extract(
  "the article title and author",
  z.object({ title: z.string(), author: z.string() }),
);

await stagehand.close();
// → the session is an island behind your Browserbase project + a separate model key.

import { Naive } from "@usenaive-sdk/server";

const naive = new Naive({ apiKey: process.env.NAIVE_API_KEY! });
const client = naive.forUser("acme"); // same id space as your own users

// One call opens a domain-scoped, per-user session. No CDP, no model key.
const session = await client.browser.createSession({
  allowed_domains: ["news.ycombinator.com"],
});

await client.browser.navigate(session.session_id, "https://news.ycombinator.com");
await client.browser.act(session.session_id, "click the first story link");

const data = await client.browser.extract(
  session.session_id,
  "the article title and author",
);

await client.browser.closeSession(session.session_id);
// → the SAME `client` also owns this user's email, cards, vault, and KYC.

• One handle, no plumbing. Browserbase is create session → connect over CDP → wrap with Stagehand → bring your own model key. Naive’s createSession returns a session_id you drive directly — no Playwright, no CDP, no separate model credential.
• Sessions are allowlisted by default. Every Naive session must pass allowed_domains (default-deny); navigation also runs through an SSRF denylist. Pass ['*'] to browse unrestricted (not recommended).
• Writes are gated. A destructive/submit act is refused unless the session was opened with allow_writes: true. Reading and clicking links work without it.
• extract is instruction-only. Naive returns extracted data from a natural-language instruction; it does not take a Zod/JSON schema. Validate the shape in your own code — see gaps.
• The id is your identity, not a separate account. In Browserbase the API key scopes Browserbase. In Naive the same forUser(id) handle also owns the agent’s email, cards, vault, and KYC.

​

The workflow that actually changes: signup & login

import crypto from "node:crypto";

const email = "acme-agent@yourdomain.com";
const password = crypto.randomBytes(18).toString("base64url"); // you generate it

await page.goto("https://app.example.com/signup");
// `variables` keeps the value out of the LLM prompt — good — but it is still yours:
await stagehand.act("fill the email field with %email%",       { variables: { email } });
await stagehand.act("fill the password field with %password%", { variables: { password } });
await stagehand.act("submit the signup form");

// Now YOU must store { email, password } somewhere and protect it,
// and YOU must wire any human approval before the account is created.
await myOwnSecretsManager.put("login:app.example.com", { email, password });

// Naive generates a strong password, fills the form, and stores { email, password }
// in THIS user's encrypted Vault under `login:app.example.com`. The password is not
// returned to your code or sent to the model.
const res = await client.browser.signup({
  service: "app.example.com",
  url: "https://app.example.com/signup",
});

// signup is sensitive, so it is approval-gated by default:
if (isPendingApproval(res)) {
  // returns HTTP 202 / status "pending_approval" — a human approves, then it runs.
}

// Later, from a brand-new session, re-authenticate without ever touching the password:
await client.browser.login({ service: "app.example.com", url: "https://app.example.com/login" });

• Credential custody flips. Browserbase substitutes the secret at fill-time but leaves you holding it. Naive generates and vaults it under the tenant user — the agent and the model never see the password.
• Verification emails land in the same identity. signup uses the user’s profile email as the account email. Point it at a provisioned inbox (client.profile.setEmail(...)) so confirmation links arrive in a mailbox the same user owns.
• Account creation is approval-gated. Because signup creates a real account under the user’s identity, it freezes for human approval by default — toggle per Account Kit.

​

Minimal viable migration

npm install @usenaive-sdk/server

​

Consolidate further once you’re on Naive

// One project (or key) per customer isolates browser sessions — and only those.
const stagehand = new Stagehand({
  env: "BROWSERBASE",
  apiKey: process.env.BROWSERBASE_API_KEY!,
  projectId: customerProjectId,
  model: "openai/gpt-4.1-mini",
});
await stagehand.init();
// ...drive the browser...

// The card, the vault secrets, the email inbox, and the KYC for this customer's
// agent live in entirely separate systems with their own tenancy — and the SaaS
// password the agent just created lives in whatever store you wired up.

// One tenant user per customer isolates *every* primitive.
const acme = await naive.users.create({
  external_id: dbCustomer.id,
  email: dbCustomer.email,
});

const client = naive.forUser(acme.id);

// Browse, then create + vault an account, all under one identity:
const session = await client.browser.createSession({ allowed_domains: ["app.example.com"] });
await client.browser.signup({ service: "app.example.com", url: "https://app.example.com/signup" });

// The SAME client owns this customer's email inbox, card, vault, and KYC —
// one identity, isolated end to end, and the SaaS credential lives in their vault.
await client.email.createInbox({ local_part: "agent" });
await client.cards.create({ spending_limit_cents: 25_000 });
const creds = await client.vault.reveal("login:app.example.com"); // server-side; not returned to the model

​

Gain #1 — one identity across primitives

• With Browserbase, the agent’s sessions are an island behind an API key, and any account it creates is a secret you store and protect yourself. With Naive, naive.forUser(acme.id) is a single handle to browser and email and cards and vault and KYC.
• The SaaS accounts the agent signs up for are not loose credentials — they are vaulted under the identity that owns everything else. Tear the customer down from one place; sibling tenants can never read each other’s sessions, logins, cards, or secrets.

​

Gain #2 — execution-time permission enforcement

• Whether an agent may browse at all, which domains it may reach, whether it may submit forms, and whether creating an account freezes for human review are all policy on the identity — not checks you hand-write and not API-key scopes you manage in a second console.

// A starter tier: browsing allowed, but new-account signup must be approved by a human.
const starter = await naive.accountKits.create({
  name: "Starter",
  primitives_config: {
    browser: { enabled: true, requiresApproval: true }, // signup freezes for approval
    cards: { enabled: false },                           // no card for this tier
  },
});
await naive.accountKits.assignUser(starter.id, acme.id);

• The agent’s code is identical for every tier — client.browser.act(...), client.browser.signup(...). Whether the call runs is decided at execution time:
  • A session must pass its allowed_domains allowlist (default-deny) and an SSRF denylist — no code change on your side.
  • A destructive act without allow_writes is refused.
  • With browser.requiresApproval: true, an autonomous signup returns pending_approval and runs only after a human approves it. Driving the page is a routine action and is not approval-gated.
  • Saved logins are human-granted. An agent can use a saved login but generally cannot create the grant or revoke a shared one — that lives in the dashboard.

​

Gain #3 — unified accountability

• Every session, navigation, action, and autonomous signup for a customer lands in one per-user activity log — alongside their email, card, vault, and KYC events, not in a separate Browserbase console:

const { events } = await naive.forUser(acme.id).logs.query({ limit: 50 });
// "what did this agent do, for whom?" — browser, email, cards, vault, one timeline

• That is the question that is hard to answer when browsing lives in Browserbase, the SaaS password lives in your secrets manager, cards live in Stripe, and email lives somewhere else. Under Naive it is a single query.

​

What does not map yet

​

Where to go next

• browser primitive — full session lifecycle, autonomous signup/login, saved logins, live view
• browser SDK sub-client — typed method signatures
• browser CLI — session create/navigate/act/extract, signup/login, context save/grant
• Vault — where autonomous signup stores login:<service> credentials
• Account Kits and Approvals — the policy model behind execution-time governance and signup approval
• Email and Profile — the inbox that receives the agent’s account-verification mail
• Tenant users — the identity that owns the browser, email, cards, and vault