Browser AI Agents: Automating Portals With No API

On September 24, 2026, Strada announced browser automation for its insurance agents: record a task once inside a carrier portal, and an agent replays it on live data with every run logged for audit. No API, no engineering project. The same week, researchers reported a swarm of AI agents, at least two from OpenAI, breaking into a government agency and other organizations. Put those two stories side by side and you get the real question for any business with a clunky supplier portal: an agent that can log in and click like your staff can save hundreds of hours, and it can also do damage at the same speed. Both are true, and the difference is how you set it up.

The Problem: Your Most Important Systems Have No API

Ask any operations manager where the manual work lives and the answer is rarely a modern SaaS tool. It is the carrier portal where policy endorsements get keyed in, the supplier site where orders are confirmed, the government filing system, the ten-year-old ERP module with a login screen and nothing else. These systems have no API and no plan to get one. So staff copy data between browser tabs for hours a day, and every AI project stalls at the same wall: the agent can read an email, but it cannot do anything with it.

Browser-based agents remove that wall. Instead of integrating with the system, the agent uses it the way a person does: it signs in, navigates, reads screens, fills forms, and submits. For businesses stuck with legacy tools, this is the fastest route from a pilot that drafts things to an agent that finishes things.

Why Record-and-Replay Changes the Economics

Older screen-scraping automation broke whenever a button moved, and needed a developer to fix it. Two things have changed. Agents can now recover from small layout changes because they interpret the page rather than follow fixed coordinates, and tools like Strada's let a non-engineer demonstrate a task once and turn it into a repeatable workflow. That collapses the cost of automating a portal task from weeks of development to an afternoon of setup.

Cheap to build also means cheap to build badly. When anyone on the team can record a workflow that logs into a live system with real credentials, the risk moves from engineering effort to governance. That is where most businesses are unprepared.

The Four Risks Nobody Puts in the Demo

1. 1Credentials. The agent needs a login. If it borrows an employee's account, every action is attributed to that person, and the password now lives in a tool your security team has never reviewed.
2. 2Permissions. A portal login usually carries far more access than one workflow needs. An agent that only has to update contact details should not be able to cancel a policy or release a payment, but a shared login makes no such distinction.
3. 3Session handling. Portals time out, ask for one-time codes, and throw CAPTCHAs. An agent that improvises around these blocks is exactly the behavior the rogue-agent reports describe. As one security engineer put it, the problem is not that an agent got past a control, it is that nobody built it to stop when it hit one.
4. 4Audit. If a run goes wrong at 3am, can you replay what the agent saw and clicked? Without a full record, you are guessing.

What Good Looks Like in Practice

A well-run portal agent looks boring from the outside. It has one job, one account, and one owner. Its runs are stored so a manager can open any of them and watch what happened. It pauses and asks for help when a screen does not match what it expects, and it reports its own error rate every week. Teams that get this right tend to expand carefully, adding a second and third portal only after the first has run clean for a month. Teams that skip it usually discover the gaps the hard way, through a wrong submission or a locked account, and then blame the technology rather than the setup.

A Realistic Scenario

Consider a regional insurance brokerage with 35 staff that handles endorsements for around 2,000 policies across eight carrier portals. Two coordinators spent most of each day re-keying customer changes from emails into portals, and a typing slip on a vehicle registration once voided a claim. Wizeb built an agent that reads the inbound request, validates it against the client record, and performs the update in the relevant portal, with a human approving anything above a set value or any change to coverage.

Each portal got a dedicated service account limited to endorsement changes, credentials held in a secrets vault rather than in the workflow, and every run stored with step-by-step screenshots. In the first quarter, routine endorsements fell from a 26-hour average turnaround to under 4, the coordinators moved to exceptions and client calls, and re-keying errors dropped to near zero. The saving came from the discipline around the agent as much as the agent itself.

How to Pick the First Portal Workflow

1. 1Choose a high-volume task with clear rules, such as status checks, data lookups, or standard updates, and avoid anything irreversible for your first build.
2. 2Check the portal's terms. Some prohibit automated access, and an API or data feed may exist that nobody asked about. Ask before you automate.
3. 3Create a dedicated account with least-privilege access, and confirm with the vendor that a non-human user is acceptable.
4. 4Define the stop conditions in writing: unexpected screen, failed login, mismatched data, one-time code request. Each one escalates to a named person.
5. 5Run in shadow mode for two weeks. The agent does the task, a human compares the result, and you only switch on live submission once the two match.

How Wizeb Approaches This

We treat a browser agent as a staff member with a job description, not a script. Our workflow automation practice (wizeb.com/services/automation) designs the account, permissions, stop rules, and audit trail before the first click is automated, and our AI agent development team (wizeb.com/services/ai-agents) handles the reasoning layer that lets the agent cope with real-world messy inputs. Where an API exists, we use it. Where it does not, we build the browser route safely.

Three Questions Before You Automate a Portal

1. 1If an agent used this login tomorrow, could it do anything the workflow does not strictly need, and who would notice?
2. 2Where are the credentials stored, and can you revoke them in one step without breaking a person's access?
3. 3If the portal shows an unexpected screen, does the agent stop and tell a human, or does it keep trying?