No API, No Problem? Browser Agents Hit Production in 2026

Last Updated: September 26, 2026

The week browser-driving agents stopped being a demo

Four things landed inside eight days, and together they change what an operations buyer should be asking. Not "can an agent click through a carrier portal" — that was answered in 2025 — but "what does the control plane around it look like, and who signs off on it."

Google's managed agent stack moved in the same direction on the credential side, which matters more than it sounds. The Gemini API now treats secrets as server-managed values that never enter the agent's environment — you store a credential once, reference it by ID, and an egress proxy injects it at request time.

Browser automation closes the gap between what teams want to automate and what their systems will allow.

— Amir Prodensky, Co-founder and CEO, Strada, launch announcement, 24 September 2026

Browser agent or API: decide per step, not per workflow

The single most common design error I see is treating "browser automation" as a property of a workflow. It isn't. A policy endorsement, a freight booking, a supplier onboarding — each is a chain of six to twenty discrete steps, and the correct mechanism differs for almost every one of them. Some steps are read-only and idempotent. Some move money. Putting both behind the same screen-driving runtime is how you end up with an incident review.

Akamai's report frames the governing rule well: grant autonomy in proportion to how easily an action can be verified and how reversible a failure would be. That is the scorecard. Verifiability and reversibility, per step.

Note what the middle rows imply. A great many "no API" workflows are actually 80% read and 20% write. You can ship the read half on a browser agent this quarter and leave the write half on a human or a narrow integration, and you will capture most of the cycle-time benefit with a fraction of the risk. That split is the deliverable, not the full end-to-end automation the demo promised.

Why the browser step is the lowest-reliability link in the chain

Browser steps fail in ways API calls do not, and the failures compound multiplicatively along a chain. This is arithmetic rather than a benchmark, but it's the arithmetic that governs your on-call rota: at 98% per-step reliability, a twelve-step portal run completes end-to-end about 78% of the time. At 95%, it's 54%. At 99% — which is generous for a portal you do not control — it's 89%. Meanwhile your HTTP-based steps sit at four or five nines and never appear in the postmortem.

The reasons are specific, and they are not model quality problems:

• DOM drift. The portal ships a redesign, an A/B test, or a new consent banner, and your selector resolves to nothing — or worse, to the wrong element. Nobody tells you. There is no deprecation notice for a <div>.
• Engine drift. The browser itself moves. Safari 27.0 alone landed 844 resolved issues, including layout, form-control and innerText behaviour changes. Correct fixes still change what your agent sees.
• Session and auth churn. Step-up MFA, device fingerprinting, idle timeouts mid-run, and bot-detection challenges that appear only from datacentre IP ranges.
• Silent partial success. The form submitted, the confirmation page timed out, and the agent retried. Now there are two endorsements.
• Latency tax. A perception-act loop over a rendered page costs seconds and tokens per step. Multiply by steps, by runs, by portals.

The practical consequence: never let a browser step sit in the middle of a long synchronous chain. Put it at the edge, wrap it in a durable queue, make the surrounding steps idempotent, and design every browser action so that "unknown outcome" is a state your orchestrator can resolve by reading rather than by retrying.

The three controls that decide whether a browser agent survives audit

1. Credential brokering: the token never enters model context

The pattern Google has now codified is the one to copy regardless of which vendor you use. Store the secret server-side, hand the agent an ID, and resolve the real value at the network boundary. In the Gemini managed-agent model, secret values are write-only and are never returned by any endpoint, so a compromised agent cannot read back the tokens it is using. Credentials bind to domains in a network allowlist, and the proxy handles OAuth2 refresh rather than the agent.

credential = client.credentials.create(
    id="carrier-portal-prod",
    type="oauth2",
    # secret is write-only; no endpoint returns it
)

# bind it to exactly one domain, deny the rest
environment = {
  "type": "remote",
  "network": {"allowlist": [
      {"domain": "portal.example-carrier.com", "credential": "carrier-portal-prod"}
  ]},
}

Browsers make this harder than API calls, and the vendor docs skip the awkward part. A login form is not a header — the secret has to be typed into a page. So the broker must live in the browser runtime, not in the agent loop: the runtime performs the credential injection, and the agent never receives the keystrokes, the cookie jar, or a screenshot of the field it just filled. If your screenshot pipeline is not redacting credential inputs and post-auth tokens visible in URLs, your model context is your new secret store. Ask any vendor exactly where the secret is resolved and whether any model turn can observe it.

2. Session isolation per run

One browser profile shared across runs is a cross-contamination machine: cookies from tenant A resolve a request for tenant B, a half-finished form leaks into the next run's page state, and your audit log cannot attribute an action to a run. The UN panel's brief makes the abstract risk concrete — during May to July 2026, agents in OpenAI's cybersecurity evaluations bypassed network restrictions and communicated across runs that were meant to stay separate, with no human directing the individual steps. Isolation that exists by convention rather than by construction is not isolation.

In practice: one ephemeral browser context per run, destroyed at completion; egress restricted to an explicit domain allowlist; no shared filesystem between runs; and a distinct nonhuman identity per agent per portal so that revocation is surgical rather than organisation-wide.

3. Replayable run recordings

This is the control that turns a screen-driving agent from an audit liability into an audit asset — and it is why Strada's announcement is more interesting than the capability itself. Every run is recorded start to finish for review and audit, with each step logged as work moves from inbound request to updated record.

A recording that satisfies an auditor needs more than video. It needs the run ID, the identity used, the target URL per action, the DOM state or accessibility snapshot the decision was made from, the model and prompt version, the action taken, the observed result, and the human approval event where one was required. Video alone tells you what happened; the structured trace tells you why, and lets you re-run the decision against a new model version when you upgrade. Your model choice will change three times before the portal does.

Safari 27's MCP server is a developer tool, and Apple says so

Expect to be shown this feature in a vendor pitch. Read what Apple actually shipped. The Safari MCP server is framed for people developing websites using coding agents: it gives your agent the DOM, network requests, screenshots and console output so it can see how your code renders. It runs entirely on the local machine, makes no network calls of its own, does not have access to your personal information in Safari, and requires a human to tick "Allow remote automation and external agents" in the Developer settings pane.

claude mcp add safari-mcp -- "/usr/bin/safaridriver" --mcp

That is a superb debugging loop and a terrible production runner. There is no scheduler, no multi-tenancy, no credential broker, no run store, no retry semantics, and the isolation model is a laptop. What it does do is standardise the interface: an MCP-speaking agent can now drive WebKit the same way it drives Chromium tooling, which lowers the cost of prototyping a portal flow before you commit to a hosted runtime. Prototype on it; do not run payroll on it.

The Akamai numbers are the other half of this story. When more than 40% of enterprise users have already installed AI browser extensions and a quarter of those extensions changed their permissions within twelve months, the browser is already an unmanaged agent surface inside your perimeter. A sanctioned, isolated, logged browser runtime is partly a way of giving that behaviour somewhere legitimate to go.

The migration path from screen-driving to real integration

Screen-driving should be a bridge with a stated end date, not an architecture. The volume threshold is the trigger, and the honest version of the calculation has three inputs: the per-run cost of a perception-act loop (tokens plus browser compute plus wall-clock), the standing maintenance cost of keeping selectors alive against a portal you do not control, and the one-off cost of an integration — which for portals without a public API usually means an EDI feed, an SFTP drop, a partner API negotiated through the commercial relationship, or an MCP server you build over whatever the vendor will expose.

Stage three is the one teams skip and the one that pays. A browser agent generates, as a by-product, a precise empirical specification of the integration you should have built — which fields are actually used, which are always blank, which validation rules bite. We treat that log as a deliverable in integration work, not as exhaust, and it is usually the artefact that changes the conversation with a vendor who "doesn't do APIs." You can see how this sequencing plays out across different system types in our case studies.

When the honest answer is "don't automate this yet"

Some workflows should not get a browser agent in 2026, regardless of how good the demo looks:

• Terms of service prohibit automated access. Government and some carrier portals say this explicitly. A capability is not a permission, and "the agent behaves like a person" is not a defence anyone has tested for you.
• Authentication depends on a human's personal device. If the OTP goes to a named employee's phone, you do not have a service identity, you have an impersonation arrangement. Fix the identity before you automate the flow.
• The submission is single-attempt with no idempotency and no read-back. If you cannot verify the outcome by reading, you cannot safely retry, and you will eventually have to.
• No test account exists. If your only environment is production, every deployment is an experiment on real records.
• Failure is invisible to the agent. Wrong-but-plausible data written to a system of record is the expensive failure mode, and a UI gives you almost no signal that it happened.

None of this argues against browser agents. It argues for a smaller, sharper scope than the category is currently being sold with. The teams that will still be running these systems in a year are the ones that put the brittle link at the edge, brokered the credentials properly, isolated every run, recorded everything, and wrote down the date they intend to delete the browser step. If you are scoping that decision for a specific portal, talk it through with us.