Yes. AI agents can work behind logins when they operate in the browser session you already use.

The useful context often sits on the other side of a login.

An internal dashboard, payroll portal, support admin, procurement site, or customer account may contain the only version of the information you need. A generic web-research agent cannot complete that work from public pages alone.

Strawberry is a browser environment, so it can work from the signed-in pages already relevant to your task. That lets a workflow gather the real context rather than simulating it from search results.

Logging in is a separate human step when a site requires it.

Some services require an existing session, a one-time code, an authenticator, or an approval from the account owner. Those are security controls for the account, not details an agent should solicit in chat.

Open the site and sign in normally when needed. Once the authorized page is available, Strawberry can continue with the defined workflow in that browser context.

Use a connector when its supported operations are the safer route.

For a system with a native integration, specific operations can be safer and more legible than navigating a broad admin surface. The integration boundary makes it possible to define exactly what the workflow can retrieve or update.

Use browser work when the critical step is genuinely website-only. Use a connection when its available operations fit the job. A strong workflow can combine both without confusing one kind of access for the other.

Start with reviewable work before allowing a logged-in action.

The safest first task behind a login is usually read-heavy: collect invoices, summarize open support tickets, compare policies, or prepare a list of missing fields. Review the output and exceptions before extending the workflow into changes.

If the work repeats, encode the boundaries in a skill. A routine can then do the reconnaissance on schedule without quietly turning access into autonomy.

Frequently asked questions