It is late in the evening and the overnight job is stuck on a sign-in page. The saved session expired, the agent was never given the password, and the person who knows it is asleep. Everything else in the run waits behind a form with empty fields.
Solari now signs agents in through 1Password. You connect a read-only service account once; when a browser session reaches a login page for a site you set up, Solari fills in the username, the password and the one-time code, and the agent carries on without ever holding the credential. This guide walks through how a sign-in is decided, the setup, and the cases that still go to a person.
How Auto-Login Decides What to Do
Before the setup, it helps to know what happens at a login page, because the vault is only the second thing Solari tries. It works through three options in order and stops at the first that succeeds.
First, a saved session. If the session is already signed in, for example because it carries a profile with the site's cookies, no credential is read. Second, the password manager: Solari reads that one login from 1Password, types the username and password, submits, and types the one-time code if the site asks for it.
Third, a person. If there is no matching item, no form to fill, or the site asks for something outside the vault, the session is handed to a human with a link and a plain reason. What the agent gets back from any of these paths comes next.
What the Agent Never Sees
The agent receives an outcome, never a secret. Solari reads the password at the moment it is typed, holds it in memory for that one fill, and never stores, logs or returns it through any API.
Recordings get special handling here. While Solari signs in, recording is paused, the same way it is during a human hand-off, so the replay holds nothing of what was typed. That matters because session recording otherwise captures input values by default.
Scope is narrow as well. Solari reads one item per sign-in, chosen by the site or by a Vault/Item you set, and the rest of the vault is never copied or listed. A service account limited to a separate vault for agent logins follows the principle of least privilege, and revoking its token in 1Password stops sign-ins. That scoping is decided in the first setup step.
Setting Up 1Password Once
The setup is split between 1Password and the Solari console. In 1Password, go to Developer → Infrastructure Secrets Management → Create a Service Account, give it read-only access to the vaults your agents should use, and copy the token, which starts with ops_.
Then create a Login item in one of those vaults with the login page's address in the Website field, plus the username and password; Solari finds the item by the site's host. For two-factor sign-in, add a one-time password field, and Solari computes the current time-based one-time password and types it.
In the console, open Settings → Connections → Password Manager → Connect 1Password and paste the token. Solari checks it against 1Password before saving and shows which vaults it can read, so a bad token fails at setup, not weeks later. Finally, under Sites, choose Add a site, enter the host and pick the connection; a site then needs a session that asks for it.
Enabling Auto-Login for a Session
Auto-login is switched on per session over the API, and it is on by default through the MCP server. Over the API, create the session with the flag set, then connect your usual client to the returned wsEndpoint or cdpEndpoint:
To sign in on demand, whatever page the session is on, send a POST to /sessions/$SESSION_ID/autologin. Each call returns one of these outcomes:
Through the MCP server, sessions made with solari_browser_create are signed in by the time a set-up page has loaded. When calling solari_browser_autologin_site, always pass the manager; leaving it out sets the site back to asking a person. That fallback is the outcome worth planning for.
When a Person Takes Over
Some sign-ins are meant for a person, and the auto-login guide is specific about which ones. One-time codes are TOTP, so SMS codes, email codes, passkeys and hardware keys go to a human, as do sites that block automated sign-in or show a CAPTCHA. Sign-in works by heuristics over the page's form fields, and when a form is ambiguous, Solari asks a person rather than guess.
The hand-off carries a handoffUrl and a reason that points to the fix, such as no matching item in a readable vault or a code request with no one-time password field in the item. The person opens the link, finishes in the live browser, and the agent carries on. Those reasons also show which setup each site needs.
Choosing the Right Setup
Auto-login comes down to three choices: what the session already carries, what the vault holds, and when a person steps in. A profile is enough when a login lasts, while 1Password, the password manager Solari connects to for now, covers logins that expire or ask for a fresh code. Keep agent logins in their own read-only vault, and leave sites that send SMS codes or require passkeys on Ask a human. Beyond sign-in, the same account also runs sandboxes and desktops, as the Solari introduction explains.
Get Started With Solari
Start with a read-only 1Password service account on a single vault of agent logins, then connect it in the console and add your first site. Solari is built to be the fastest and cheapest place to run signed-in agents: browsers are ready in 8 ms, they bill at $0.07 per hour on the Professional plan, and the Free plan is $0 a month with $3 of monthly credits. Follow the Sign in with 1Password guide and let your agents sign in on their own.
