Browser profiles

A browser profile is a web application and its sign-in, kept by the platform: the start URL, the sign-in URL if it differs, the account to use and the session that sign-in saved. Give a profile to an agent and its Browser tool opens the application signed in - to answer a question, write a report, build a presentation from a dashboard, or record a demo in the Video Studio - without ever seeing the credentials.

Profiles are listed under Tools & Integrations > Browser profiles. They need no feature flag: they work whether or not the Video Studio is turned on.

Create a profile

New browser profile asks for:

Name and Start URL: the application's home page, where every session opens and is checked.
Sign-in URL (optional): the page that starts the sign-in when it is not the start URL - for single sign-on, the page the application's "Sign in with SSO" button opens.
Username, Password and TOTP secret: stored encrypted and never shown again. A blank field keeps what is stored, Clear removes it. They are typed here only: the assistant can create a profile and set its addresses and sign-in options, but never takes a credential in the chat - what a tool receives stays in the conversation - so it asks you to add them on this page.
Private-network hosts (optional): see Private networks.
Keep the session alive: how often the platform refreshes the saved session so it does not expire between uses.

An administrator can publish a profile to the whole company: everyone can then use it, with their agents and their recordings, without ever seeing its credentials.

Sign in runs the sign-in in the platform's own browser, in the profile's own session: signing in to the application in a tab of your own browser does not sign the profile in.

Single sign-on: an application that sends you to a hosted identity provider (SAML or OpenID Connect) works like a first-party sign-in form. Set the sign-in URL to the page that starts the single sign-on, or set confirm_selector to the application's single sign-on button. The sign-in follows the whole way back to the application and is done only once the start URL shows the signed-in application.
MFA: with the account's TOTP secret (the key an authenticator app is enrolled with, as base32 or as the otpauth:// link of its QR code), the sign-in answers the code prompt by itself. Paste the secret itself, not a reference to a password manager (op://..., a ${...} placeholder): the platform checks it is a real key and refuses a reference, saying so. Without a TOTP secret, an MFA prompt pauses the sign-in, with the platform's browser kept open on the prompt for 5 minutes (MFA window): type the code on the profile's card, or give it to the assistant in the chat. A push approval shows the screenshot of the prompt and the number to enter in your authenticator app; the sign-in continues by itself once you approve.
Passkeys and security keys: when the account's default MFA method is a passkey, Windows Hello or a FIDO security key, the platform's browser cannot use it (there is no device to tap). The sign-in detects this, backs out to "Sign in another way", and chooses a code method instead - an authenticator code (which it answers from the TOTP secret) or a text message. Give the profile the account's TOTP secret so these accounts sign in unattended; if the account offers only a passkey and a phone-approval push, the sign-in asks you to approve the push.
Test a sign-in: Test sign-in on the profile's card runs the whole sign-in once without saving anything, and shows where it got to - the steps it took and the page it ended on. Use it to check a profile signs in cleanly without touching the session a recording relies on.
Renews by itself: a profile that has the account's password and a valid TOTP secret (or a saved single-sign-on session) carries a Renews by itself badge - the platform signs it in again on its own when the session expires, so recordings and agents keep working without anyone signing in again.
Sessions: once signed in, the profile keeps the session - the cookies of the identity provider and of the application, and the application's storage. A profile reads Signed in only when the start URL, opened with the saved session, shows the signed-in application; otherwise it reads Session expired (lands on login page) with the page it landed on. Check the session checks it now. When the application cannot answer - it is restarting, overloaded or limits the rate of requests (an HTTP 5xx or 429) - the check opens it again a few times over about half a minute, then says so (start_url answered HTTP 503: the application is unavailable...). The profile then reads Saved, not checked rather than Session expired, it is not signed in again (by the keep-alive, Check the session, a recording or an agent), a recording stops with profile session not checked, and an agent's Browser tool says the application did not answer instead of asking you to sign the profile in; check again once the application is back. A recording whose own page is refused that way reloads it before its first step.
Timeouts: under Sign-in selectors and timeouts, the sign-in timeout (120 s by default) counts from the last page change; a sign-in that stops moving fails and names its stage and the last page it was on.

Give a profile to an agent

On an agent's Configuration > Tooling tab, with the Browser tool on, the Browser profiles card lists the profiles the agent may sign in with. Binding is explicit: an agent never reaches every login its users can see.

The agent lists them with the browser's profiles action and opens one with navigate and the profile's name. The session it opens is checked first; when it has expired and the profile can sign in by itself (its password and TOTP secret, or a saved identity provider session), it signs in again. When the sign-in needs a person (an MFA code with no TOTP secret), the agent says so: sign the profile in on its card, then ask again.
A run opens a profile only for a person who may use it - its owner, the people and groups it is shared with, or everyone for a company profile. An administrator's role does not widen that: a run never opens someone else's private profile. A run that acts for nobody (an anonymous visitor of a public widget, a company assignment without a run-as user) opens none.
Read-only: a binding marked read-only lets the agent navigate to URLs and read the pages (their text, their accessibility tree, screenshots), never click, type, press a key or run a script. A page reached by a link can still change something in an application that changes state on a simple visit; give such an application to an agent you trust.
When the agent closes the session, or after five idle minutes, the platform saves the refreshed session - only if it still opens the application, and only if nobody saved a newer one meanwhile.

Every time an agent opens a profile, the audit log records it (browser_profile, action use) with the agent and the person it acted for.

Your own General Assistant uses the profiles you give it under My profile > General Assistant Tools > Browser profiles, shown once its Browser tool is on. There is no platform default: a profile is a login, given by its user.

Private networks

Browser profiles reach public addresses only, like the agent browser tool. An application on a private network needs two things: an administrator turns on Browser profiles on private networks (Settings > Security, or BROWSER_PRIVATE_TARGETS, see Configuration), and the profile names the hosts it may reach (Private-network hosts). Loopback, link-local and cloud metadata addresses stay refused either way.