An AI agent that can log into websites

Almost everything worth doing on the web is behind a login — the dashboard, the portal, the back-office with no API. Here is why most agents stop at the login page, what it takes to get past it honestly, and where it still fails.

Ask most AI agents to "check the numbers in the supplier portal" and they will do one of two things: tell you how they would do it, or try, hit a login form, and give up. The public web is easy. The logged-in web — where your invoices, your orders, your customers and your team's tools actually live — is where agents go quiet.

That is not an accident of model quality. It comes from how the agent is built. Working behind a login needs three things, and most agents are missing at least two of them.

What logging in actually requires

1. A real browser, not a fetch

A login page is not a document; it is a small application. It sets cookies, runs scripts, sometimes checks that a real browser is on the other end, and often redirects through a second domain before it lets you in. An agent that fetches HTML and parses it never gets past the first step. An agent driving a genuine browser — the same Chromium a person would use — does, because from the site's point of view itis a person's browser.

2. A session that survives

Logging in once is not the hard part. Staying logged in is. Most agents run in a sandbox that is created for a task and destroyed afterwards, which means every task starts logged out and every task starts with the password prompt — and the two-factor prompt, and the "new device" email. That is not just annoying; it is what gets accounts flagged. A site that sees a fresh device log in twenty times a day treats it as an attack.

The fix is boring and structural: the agent needs a machine that persists. Same browser tomorrow, same cookies, same "remembered device". Log in once, and the session is simply there next time, the way it is on your own laptop. This is the single biggest difference between an agent with a computer of its own and one that borrows a temporary sandbox.

3. A human for the parts only a human can do

Some steps must not be automated, and a good agent knows it. The password itself. The code from your phone. The CAPTCHA. The consent screen for a bank. An agent that tries to script its way through those is either going to fail or going to do something you did not authorise.

The honest design is a handover: the agent gets to the login page, stops, and hands you the keyboard. You type the password on the agent's own screen, approve the code, and hand it back. It carries on from there — and because the machine persists, you do this once, not every time. On MyClawn that handover is literal: the desktop is streamed to your browser and you take over by clicking into it. You can watch what that looks like.

How the approaches compare

Scrapers and API wrappers

Fast and cheap when a site has a public API or a plain HTML page. Useless behind a login that expects a browser, and brittle the moment the site changes a form field. Good for reading public prices; wrong for your own portal.

An extension in your own browser

This solves the login problem by using your sessions — the agent is already logged in as you, to everything. That is exactly the issue. It works only while your laptop is open, it acts inside the account you use for everything else, and a page it visits can talk it into doing things with your logged-in identity. Convenient; not something to leave running unattended.

A persistent cloud desktop of the agent's own

The agent has its own machine, its own browser and its own sessions, separate from yours. It stays logged in between tasks, it keeps working after you close your laptop, and the logins it holds are the ones you chose to give it — on a screen you can watch and take over at any moment. This is what MyClawn is. It costs more than a fetch (a real machine has to exist), and it is the only one of the three that holds up for the "check the portal every morning" kind of job.

What still breaks

• Sites that forbid automation. Some services ban automated access in their terms, and some detect it well. An agent using a real browser passes most checks, but "most" is not "all", and a ban is your account, not the agent's. Read the terms for anything that matters.
• Sessions that expire on purpose. Banks and some enterprise tools log you out after minutes and demand a fresh code each time. Persistence helps less there; expect to be handed the keyboard often.
• Two-factor that lives on your phone. The agent cannot and should not read your authenticator. Each new device approval is a human step, once per machine.
• Anything irreversible. Logged in is one thing; clicking "pay" or "delete" is another. Set the agent up to stop before those and let you confirm on screen — the point of being able to watch is that you can.

Where this is the wrong tool

If the job is reading public pages, a scraper is cheaper. If you need the agent to act as you inside your own accounts for a few minutes while you watch, a browser extension is fine. The persistent machine earns its cost when the work is recurring, behind a login, and should keep happening when you are not there — and when you want a line between the agent's identity and your own.

Read how sessions, credentials and the take-over work in Security & trust, or give an agent a computer of its own and log it into the first portal yourself.