Introducing /browser: give your agents a governed web session

Some of the work an agent needs to do has no API. It lives behind a login screen, a vendor portal, or a signup form built for a human with a mouse. Naïve is the autonomous company infrastructure that gives agents real-world capabilities, and /browser is the primitive for exactly this: a real, cloud-hosted browser your agents drive step by step, plus two autonomous actions — signup and login — that handle account creation and re-authentication end to end.

Every session belongs to one end-user, is scoped to an allowlist of domains, is metered per action, and is watchable live from the dashboard. It is the hand on the keyboard when there is no API to call.

What /browser does

A session gives the agent a set of governed actions:

• navigate — go to a URL (allowlist and SSRF checks enforced).
• act — a natural-language action: click, fill, scroll.
• extract — pull structured data from the page (read-only).
• observe — list candidate elements and actions (read-only).
• screenshot — capture the page as a short-lived signed image.

Sessions have a hard TTL (default 15 minutes, max 30) and a per-session credit ceiling, so a runaway loop can't spend without bound. Always close a session when done.

Drive a session

naive browser session create --allowed-domains example.com --timeout 15
naive browser navigate <session_id> https://example.com
naive browser act <session_id> "click the search button"
naive browser extract <session_id> "the list of product names and prices"
naive browser session close <session_id>

The agent reasons over observe and extract output and issues act steps in plain language — no brittle selectors baked into a prompt.

Autonomous signup and login

This is the capability most agent stacks are missing: an agent that needs an account on a third-party service can create one and reuse it later, without ever handling the password itself.

naive browser signup figma.com https://figma.com/signup
naive browser login  figma.com https://figma.com/login

• Signup opens a scoped, write-enabled session, fills the registration form with the user's identity and a strong generated password, submits, and stores the credentials in that user's encrypted Vault under a per-service key. The password is never returned to the agent or sent to the model.
• Login later reads the stored credential from the Vault and signs back in — again without the secret crossing the agent or model boundary.

Because signup creates a real account under the user's identity, it is approval-gated by default: the call returns a pending state and only runs after a human approves it. You toggle that per Account Kit.

Site terms. Autonomous signup and login must comply with each site's terms of service and automation rules. Naïve provides the browser runtime; you decide which domains are allowed and which flows require human approval.

Tip. Point signup at a provisioned /email inbox so verification emails can be received. Naïve uses the tenant user's profile email as the account email.

Saved logins for SSO and 2FA

Some services require a human to log in once — SSO, hardware 2FA, a CAPTCHA. For those, open a human-login session, complete the login in the dashboard live view, then save it as a reusable, encrypted context. Naïve stores only an opaque pointer, never the cookies or credentials. Later sessions reopen already-logged-in by name, gated by a human-created grant — an agent can use a saved login but never create or revoke the grant.

Governed by default

/browser is a per-tenant-user primitive, so its safety rails are structural, not optional:

• Domain allowlist (default-deny). Every session must pass allowed_domains. An SSRF denylist for private, loopback, and metadata hosts always applies.
• Writes are gated. Submit and destructive actions are rejected unless the session was opened with write access.
• No secrets in instructions. Passwords are handled server-side by the signup and login flow, never typed into an act instruction.
• Account Kit gating. browser must be enabled on the end-user's Account Kit, and autonomous signup can require human approval.

What you can build

Onboard agents onto the tools they need — Let a support or research agent sign up for the SaaS a job requires, with the account created under the right end-user and the credentials vaulted automatically.

Reach services that have no connector — Vendor portals, filing sites, and legacy admin panels that only exist as a web UI. Compose /browser with /email so a downloaded document or confirmation lands in the right inbox.

Give every tenant their own governed browser — In a multi-tenant app, each customer's agent gets its own domain-scoped sessions and its own vaulted logins — no shared state across tenants.

Keep a human on the exceptions — Watch a session live, take control to clear a CAPTCHA or finish an SSO login, then hand it back to the agent.

Complete SMS 2FA login loops — Pair governed browser sessions with a per-tenant /phone number so OTPs stay scoped to one customer.

Get started

Drop this starter prompt into any coding agent to wire up Naïve:

Read https://usenaive.ai/skill.md and use it to set up Naïve in my project.

• Read the docs: usenaive.ai/docs/getting-started/browser
• Quickstart: usenaive.ai/docs/getting-started/quickstart
• Pair it with /vault and /connections
• Join the community on Discord