Authentication in browser agents

Authentication is where most browser automation becomes insecure, usually by taking the simplest path: store the password, type it in. There are better options and they are not much harder.

The ordering is by how much you hold. What you never store cannot be stolen from you, so prefer approaches that keep the secret out of your system entirely.

There is a fourth option worth checking first: whether authentication is needed at all. Many application flows work without an account, and a design that only authenticates where the portal actually requires it removes the problem for most of the traffic.

• Session handoff — the user signs in; you receive only a session, never a password
• Secret injection — a password in a vault, injected at use, never in the model’s context
• Stored credentials — last resort, encrypted per user, with explicit consent

The user signs in themselves — in a browser you control, or in an extension running in theirs — and what your system keeps is a session cookie rather than a credential. The password never exists in your infrastructure.

This also handles multi-factor authentication naturally, because the human is present exactly when the second factor is required. Sessions expire, which is a genuine cost, but the security difference is large enough to justify a periodic re-authentication prompt.

Treat the session with the care a credential deserves, because for the duration of its life that is what it is. Encrypted at rest, scoped to one user, never in a log or a trace, and deleted when the user disconnects the account.

Isolate the browser context per candidate without exception. A reused profile carrying one person’s session into another’s run is a straightforward data breach, and it is easy to introduce by accident while optimising away browser startup time.

Keep it in a proper secrets manager, fetch it at the moment of use, type it into the page, and discard it. It should never appear in a prompt, a tool argument the model can see, a log line, or an error report.

The practical failure here is error handling: a login that fails and logs the attempted values, or a monitoring service that captures the request body. Audit those paths specifically, because they leak far more often than the intended storage does.

Screenshots are the browser-specific version of the same leak. A failure capture taken on a login page may contain a password field that was not masked, and an automatic screenshot-on-error policy quietly writes credentials into an artefact store nobody scoped.

Make revocation something the user can reach in one action. They should be able to disconnect an account without contacting support, and that same path is what you will use during an incident to invalidate everything at once.

An agent cannot complete a second factor that requires a device or a human. Attempts to route one-time codes through the automation are a bad idea: you end up storing or forwarding the factor that exists precisely to require a person.

Design for the pause instead. When MFA appears, the agent should stop, notify the user, and resume once a session exists. Treating this as a supported state rather than an error makes the whole system more honest and considerably easier to operate.

Make the pause cheap to recover from. A saved run state, a clear notification naming the site, and a resume that picks up at the exact step it stopped turns the interruption into a minute of the candidate’s time rather than a lost application.

Expect it more often than the first sign-in. Portals challenge on a new device, a new location or after a period of inactivity, so MFA is a recurring state in normal operation rather than a one-time setup step.

A logged-out agent rarely sees an error. It sees a login page, and if it is not looking for one it will happily interpret it as the page it wanted and start filling fields into it.

Check for an authenticated marker before every consequential action — an element that only appears when signed in. If it is missing, stop and re-authenticate rather than proceeding. Without this check, session expiry presents as mysterious silent failures rather than as the simple cause it is.

Detect by symptom rather than by a timer. A redirect to sign-in, a step that resets, or a form rejecting everything are all expiry, and a countdown based on an assumed session lifetime will be wrong for most of the portals you meet.

Never let the agent type credentials into a page it did not expect. A login form appearing mid-flow is a stop condition, because the one scenario where it is not an expired session is the one where something has redirected the agent somewhere it should not be.