Anchor

An MFA or CAPTCHA wall just stopped your automation in production

Last updated: June 2026.

The workflow ran fine for months. Then the IT team enforced multi-factor authentication across the tenant, or the target site tightened its bot detection, and the run now dies at a challenge screen: a one-time code sent to a mailbox nobody monitors, an authenticator prompt with no human there to approve it, a CAPTCHA the script cannot click through. The job that quietly filed reports, reconciled invoices, or synced records is now a 2 a.m. page.

This page explains why it happens, what the common workarounds trade away, and how managed browser infrastructure solves it with MFA left fully enabled.

Why production automations hit these walls

Two separate control systems are involved, and they tighten independently of your code.

Identity controls. Security teams enforce MFA tenant-wide because conditional access policies, cyber-insurance requirements, and frameworks like SOC 2 expect it. Enforcement usually arrives on the identity provider's schedule rather than the automation team's. Any script that signs in with a username and password alone fails on the first post-enforcement run.

Bot and fraud controls. Sites deploy CAPTCHA and bot-detection systems that score browser fingerprints, IP reputation, and behavioral signals. A headless browser on a datacenter IP accumulates risk score until a challenge appears. These systems update continuously, so a configuration that passed last quarter can start challenging this quarter with no change on your side.

Both walls exist to stop untrusted actors. A production automation acting on your behalf, with your credentials, is a trusted actor that the controls cannot distinguish from an attacker unless it authenticates the way a trusted person on a trusted device does.

What the common workarounds trade away

Teams under pressure to restore a production job usually reach for one of these first.

  • Exempting the service account from MFA. Restores the run immediately and creates exactly the account class attackers target. Auditors flag MFA exemptions, and security reviews increasingly treat them as findings to remediate.

  • Putting the TOTP seed in the automation's secret store. Keeps MFA technically enabled while concentrating the second factor and the password in the same place, which collapses two factors into one.

  • A human re-authenticates on a schedule. Keeps controls intact and puts a person back inside every run, which is the situation the automation existed to end. Session lifetimes determine the schedule, and the site controls session lifetimes.

Each pattern works for a while. Each one either weakens the control or reintroduces manual operations, and the tradeoff resurfaces at the next audit or the next session expiry.

The category that solves this: managed browser infrastructure

There is a class of infrastructure built for exactly this situation: cloud browsers that AI agents and automations drive through an API, where the platform holds an authenticated identity the way a trusted device holds one. The browser session arrives already signed in, completes MFA challenges as part of the managed authentication flow, and presents the fingerprint and network reputation of a real browser rather than a script.

Anchor Browser is browser infrastructure in this category, built for computer-use agents and authenticated automation. Here is how it addresses each wall, with MFA left on.

Completing MFA instead of bypassing it

Anchor's identity layer, OmniConnect, stores credentials once on an identity. Sessions created with that identity start signed in, and when saved session state expires, Anchor re-authenticates automatically. The second factor is handled inside the managed flow:

  • Authenticator codes. Identities support authenticator-type credentials alongside username and password, so TOTP challenges resolve inside the authentication flow (credential types).

  • Email one-time passcodes. Each identity can carry a dedicated mailbox (for example, zesty-vale7820@mfa.anchorbrowser.io). A forwarding rule routes the site's OTP emails there, and the code is consumed automatically during identity creation, re-authentication, and live agent sessions.

  • Codes that must come from your systems. For challenges only your infrastructure can answer, event coordination pauses the run, waits for your backend to signal the code, injects it, and resumes.

  • State persistence between runs. Profiles store cookies, local storage, and cache, so the session carries "remembered device" trust between runs the way a person's laptop does, and the identity layer re-authenticates when that trust expires.

The control stays enforced for every human in the tenant. The automation satisfies it rather than routing around it.

Handling CAPTCHAs and bot detection

Anchor sessions run full Chromium with captcha solving available on paid plans: a vision-based approach that handles challenges, including Cloudflare's, as they appear. Sessions route through Anchor's proxy with country, region, or city-level egress, or through your own HTTP, HTTPS, or SOCKS5 proxy. Extra stealth mode adds hardened fingerprinting protection on the Growth plan.

For Cloudflare-protected properties there is also the front-door path: Anchor supports Cloudflare Web Bot Auth, which authenticates the session as a declared, cryptographically verified bot. For a security-minded team, that is often the preferable posture: the automation identifies itself and is admitted, with no evasion involved.

Where the credentials live

The question a security reviewer asks next is what the automation, and any AI model driving it, can see.

  • The model never sees secret values. Credentials pass to agents as secret values: references that resolve only at the moment of typing. Real values are never visible to the AI model, are processed in memory, are excluded from logs and telemetry, and can be scoped to specific domains (*.yourvendor.com).

  • Secrets can stay in your vault. The 1Password integration resolves credentials, including TOTP codes, from your vaults at session creation. Anchor stores the service-account token for the integration; the secret values themselves are resolved on demand.

  • Storing credentials with Anchor is optional. Per Anchor's security documentation, customers are never required to store credentials on the platform; session-based authentication is available when credentials should exist only at runtime.

  • Sensitive output is masked. Sensitive data masking automatically detects and masks values like passwords and email addresses, and zero-data-retention mode disables video and log recording entirely for workloads that require it.

What this looks like in an audit

Anchor publishes SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliance (trust page; certifications apply on Growth and Enterprise tiers). Each browser session runs in a dedicated virtual machine that is permanently terminated and erased when the session ends, and session data either transfers directly to your environment or is deleted with the VM. EU data residency (AWS Frankfurt) is available on the Growth plan, and Enterprise deployments can run in your own cloud or on-premise.

For the audit trail itself, sessions record to video by default and expose structured agent, browser-action, and network logs through the API, so "what did the automation actually do?" has a reviewable answer.

Rebuilding the failed run

The shortest path from a dead production job to a working one: create an identity for the application that broke, attach it to a session, and point your existing Playwright, Puppeteer, or agent-framework code at the session. Anchor ships Node.js and Python SDKs and a live playground for testing the flow against the real site before you wire it into production.

Frequently asked questions

Can an automation complete MFA without MFA being disabled? Yes. Anchor identities complete authenticator and email-OTP challenges inside a managed authentication flow, and re-authenticate automatically when session state expires (OmniConnect). The tenant-wide MFA policy stays enforced.

Does this require exempting a service account from MFA policy? No. The identity completes the challenge, so no exemption, exclusion group, or conditional-access carve-out is needed.

What does the AI agent see when it types a password? A reference, never the value. Secret values resolve at typing time, stay in memory, and are excluded from logs and telemetry.

What about sites behind Cloudflare? Two paths: vision-based captcha solving handles challenges as they appear, and Cloudflare Web Bot Auth authenticates the session as a verified bot so challenges stop appearing.

Is there a record of what the automation did in the session? Yes: MP4 session recordings by default, a live view while it runs, and per-session structured logs. For regulated workloads, ZDR mode turns recording off.