Nov 2025
Authentication is the first wall most browser automation hits. If your target requires a login, you have to solve two problems: how to supply credentials without hardcoding them, and how to handle the login flow (which may include MFA, redirects, or rate limiting).
Hard-coding a login flow into your task ('click the login link, type the email field, type the password field, submit') makes it the most brittle step. If the site adds an extra verification, or changes the field names, or adds a captcha, the login fails and the whole run fails.
BrowserPilot keeps credentials in encrypted workspace secrets. You store a username and password (or an API key, or a token) as a workspace secret, encrypted at rest and only decrypted when a run actually needs it. You never see plaintext credentials in logs, and you never hardcode them in tasks.
When a task includes a 'log in' step, BrowserPilot decrypts your credential, navigates the browser to the login page, and hands it off to the agent. The agent drives the login, handling redirects and optional MFA. Once logged in, the agent continues with the rest of your task.
But logging in every run is slow and brittle. The agent has to drive a form, handle redirects, and deal with rate limiting. If you are running the same task 100 times, you do not want to log in 100 times.
That is where persistent browser profiles come in. A profile is a saved browser state with valid cookies, local storage, and sessions. You can attach a profile to a run, and the browser starts already logged in. Runs are faster, gentler on the target, and less flaky. When the run finishes, the updated state is saved back to the profile. Next run, you start fresh and logged in again.