Sign in with 1Password

Let your agent sign in to the sites you own, without you handing it a password. Connect a read-only 1Password service account once; when a browser session reaches a login page, Solari fills in the username, the password and the one-time code, and the agent carries on.

How it works

When a session lands on a login page for a site you have set up, Solari tries three things in order and stops at the first that works:

1. A saved session. If the session is already signed in (for example it carries a profile), nothing else happens and no credential is read.
2. Your password manager. Solari reads that one login from 1Password, types the username and password, submits, and if the site then asks for a one-time code, types that too.
3. A person. If there is no matching item, the form can't be found, or the site wants something Solari can't give it (an SMS code, a passkey, a captcha), the session is handed to a human with a link and a plain reason. The person opens the link, finishes the sign-in in the live browser, and the agent carries on.

Your agent never sees the credential. The password is read at the moment it is typed, held in memory for that one fill, and is not stored, logged or returned by any API. What the agent gets back is the outcome.

Set it up

1. Create a read-only service account in 1Password

In 1Password go to Developer → Infrastructure Secrets Management → Create a Service Account. Give it read-only access to just the vaults your agents should use, and copy the token (it starts with ops_). A separate vault for agent logins keeps the blast radius small: the token can only reach the vaults you choose, and you can revoke it in one click.

2. Store the login in a vault the account can read

Create a Login item with:

• Website: the address of the login page. This is how Solari finds the item. It matches the site's host, and an item saved for example.com also serves login.example.com.
• username and password fields.
• Optionally a one-time password field. If the site asks for a 2FA code and the item has this field, Solari computes the current code and types it. Without it, a site that asks for a code is handed to a person.

3. Connect 1Password in the console

Open the console → Settings → Connections → Password Manager → Connect 1Password. Give it a name and paste the service account token.

Solari checks the token against 1Password before saving it, and shows Can read N vaults: … so you can confirm the token reaches exactly what you meant it to. A token that is invalid, or that can see no vaults, is rejected here rather than failing weeks later at a login. The token is stored encrypted, is never shown again and is never returned by the API; the console only shows a short fingerprint. To rotate it, connect again with the same name and a new token.

4. Tell Solari which sites to sign in to

Connecting a password manager does nothing on its own: a site has to point at it. Under Sites choose Add a site and fill in:

• Site: the host, for example github.com.
• Sign in using: the connection you just made. Leave it on Ask a human if you only want Solari to remember the session and ask you when a fresh login is needed.
• Vault item (optional): Vault/Item. Leave it blank and Solari finds the login by site. Set it when one site has several logins.

Each site shows its state: Not signed in yet, Signed in or Session expired. Remove a site to stop signing in to it; disconnecting the password manager leaves the sites in place and they fall back to asking a person.

Use it from a session

Over the API

Create the session with autoLogin: true. Solari then watches the session and signs in when it reaches a login page for a site you set up. Connect your client to the session as you normally would.

curl -s https://api.getsolari.com/sessions \
  -H "Authorization: Bearer $SOLARI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"autoLogin": true}'

Ask for it explicitly

To sign in right now, whatever page the session is on, call:

curl -s -X POST https://api.getsolari.com/sessions/$SESSION_ID/autologin \
  -H "Authorization: Bearer $SOLARI_API_KEY"
# {"outcome":"vault_login","sessionSaved":false}

The response is always a status, never a credential:

Through the MCP server

Sessions made with solari_browser_create have auto-login on by default, so an agent that navigates to a set-up site is signed in by the time the page has loaded. Two tools let the agent see and change the setup:

• solari_browser_autologin_status: which password managers are connected (name, provider, the vaults they can read), which sites are set up, and each site's state. It never returns a credential.
• solari_browser_autologin_site with domain and manager (the connection's name): set a site to sign in using that password manager.

What is and isn't exposed

• The password is never returned by the API, never in the MCP tool output, never in logs, and never in a session recording.
• Recordings. While Solari signs in, recording of the page is paused, the same way it is during a human hand-off, so the replay does not capture what was typed.
• The service account token is stored encrypted, never returned, and only ever read-only if you made it so. Revoke it in 1Password at any time and sign-ins stop.
• Scope. Solari reads one item per sign-in, chosen by the site (or the Vault/Item you set). It does not copy or list the contents of your vaults.

When it falls back to a person

The reason in a human_required response is specific. The common ones:

Limits

• 1Password service accounts only; no Bitwarden or other managers.
• One-time codes are TOTP (the standard authenticator codes). SMS, email codes, passkeys and hardware keys need a person.
• Sign-in is by heuristics over the page's form fields. When it can't be sure, it asks a person rather than guess.
• Sites that block automated sign-in, or that show a captcha, fall back to a person (see Captcha Solving).