My AI Agent Hit a Login Wall — BrowserAct Let It Ask for Help and Resume
I’m a cloud architect. I manage infrastructure across multiple AWS accounts, run CI/CD pipelines, and keep monitoring dashboards healthy for clients. A lot of my day involves checking web-based tools — Grafana, GitHub, vendor portals, internal dashboards — most of which sit behind login walls and anti-bot protection.I’ve been pushing AI agents into real operational workflows for over a year now. Code generation, infrastructure provisioning, pipeline management — agents handle all of that. But there was always a gap: the agent couldn’t browse the web. It couldn’t check a dashboard, read a protected page, or handle a login flow.
That changed when I integrated [BrowserAct](https://browseract.com?fpr=sarvar04) into my workflow. It’s a browser layer that gives AI agents the ability to browse real websites — with anti-detection, session management, and human handoff built in.
If you missed the first article where I covered the full setup, start there: [I Gave My AI Agent a Real Browser — Here’s What Actually Happened](https://dev.to/aws-builders/my-ai-agent-hit-a-login-wall-browseract-let-it-ask-for-help-and-resume-3mia). This article focuses on the headless + human handoff pattern I’ve been running in production.
**A note on tooling:** I’m using Kiro as my AI agent — it’s free during preview and can execute CLI commands directly. But [BrowserAct](https://browseract.com?fpr=sarvar04) works with anything that can run shell commands: Claude Code, Cursor, Codex, CrewAI, LangChain, or even a simple bash script. The pattern is the same regardless of agent.
— -
## Real Scenario: Morning Tech Research
One of the things I do for a client is compile a daily tech digest — what’s trending, what’s launching, what competitors are shipping. Used to take me 30 minutes of tab-switching every morning.
Now my agent does it. Here’s what that looks like.
### Quick Extract — One Session, One Page
The agent opens a stealth browser session and pulls structured data from Hacker News:
```
# Open session
browser-act — session research-hn browser open 101758963005571124 \
https://news.ycombinator.com
# Get page state
browser-act — session research-hn state
# Extract top stories as JSON
browser-act — session research-hn eval \
‘JSON.stringify(Array.from(document.querySelectorAll(“.athing”))
.slice(0,4).map(el => ({
title: el.querySelector(“.titleline a”)?.textContent,
points: el.nextElementSibling?.querySelector(“.score”)?.textContent
})))’
```
Output:
```
[
{“title”: “AI agent bankrupted their operator while trying to scan DN42”, “points”: “171 points”},
{“title”: “Nobody ever gets credit for fixing problems that never happened”, “points”: “348 points”},
{“title”: “If you are asking for human attention, demonstrate human effort”, “points”: “537 points”},
{“title”: “Show HN: Homebrew 6.0.0”, “points”: “1145 points”}
]
```
Two commands to open, one to extract. The agent can summarize this, filter by topic, or flag anything relevant to the client.
### Parallel Research — Three Sites at Once
For the full morning digest, the agent opens three parallel sessions on the same browser:
```
# Create a browser for research
browser-act browser create
# Output: id=101764340218654773
# Open 3 sessions in parallel
browser-act — session research-gh browser open 101764340218654773 \
https://github.com/trending
browser-act — session research-hn browser open 101764340218654773 \
https://news.ycombinator.com
browser-act — session research-ph browser open 101764340218654773 \
https://www.producthunt.com
```
All three run independently. No conflicts. The agent verifies:
```
# Check active sessions
browser-act session list
```
Output:
```
session_name: research-gh
browser_type: stealth
browser_id: 101764340218654773
title: Trending repositories on GitHub today
url: https://github.com/trending
session_name: research-hn
browser_type: stealth
browser_id: 101764340218654773
title: news.ycombinator.com
url: https://news.ycombinator.com/
session_name: research-ph
browser_type: stealth
browser_id: 101764340218654773
title: Product Hunt — The best new products in tech.
url: https://www.producthunt.com/
```
**Where this fits:** Product teams that need multi-source intelligence before standup. Marketing teams tracking launches. DevOps engineers checking status pages across providers. Anything where you’d normally open 5+ tabs.
### Structured Data Extraction
Instead of parsing full page HTML, the agent runs targeted JavaScript and gets clean JSON:
```
# Extract trending repos from GitHub
browser-act — session research-gh eval \
“JSON.stringify(Array.from(
document.querySelectorAll(‘article.Box-row’)
).slice(0,3).map(r => ({
repo: r.querySelector(‘h2 a’)?.textContent.trim(),
stars: r.querySelector(‘span.d-inline-block.float-sm-right’)
?.textContent.trim()
})))”
```
Output:
```
[
{“repo”:”iptv-org / iptv”,”stars”:”2,650 stars today”},
{“repo”:”teslamate-org / teslamate”,”stars”:”35 stars today”},
{“repo”:”Panniantong / Agent-Reach”,”stars”:”1,045 stars today”}
]
```
No scraping framework. No maintenance when the page layout changes. [BrowserAct](https://browseract.com?fpr=sarvar04) isn’t a standalone scraping tool — it’s a browser layer. Your AI agent is the brain that decides what to do. BrowserAct is the eyes and hands that execute on the web.
— -
## Then the Agent Hits a Wall
Everything was going smoothly. The agent had data from three sources, research compiling nicely. Then it tried to check my GitHub profile settings:
```
browser-act — session research-gh navigate \
https://github.com/settings/profile
```
Response:
```
url=https://github.com/login?return_to=https%3A%2F%2Fgithub.com%2Fsettings%2Fprofile
title=Sign in to GitHub
```
Redirected to login. The agent checked the page state:
```
[2]<label />
Username or email address
[3]<input type=text name=login />
[5]<input type=password />
[7]<input type=submit value=Sign in />
[8]<button />
Continue with Google
```
With any other automation setup, this is where the workflow dies. Script crashes. Logs an error. Someone restarts it manually tomorrow.
Here’s what my agent did instead.
## The Agent Asks for Help — and Gets It
```
browser-act — session research-gh remote-assist \
— objective “Sign in to GitHub to access profile settings”
```
Output:
```
Remote assist session created.
Share this URL with the user:
https://www.browseract.com/remote-cli/1c08b0f3e0cb46168c9dd836ead748d2
expires in 1h 0m
Human assist is now active — the browser is under user control.
Do not send browser commands until the user finishes the assist session.
```
The agent recognized it couldn’t solve this. It generated a live URL and asked me for help. This is the core pattern — four steps, under a minute:
**Step 1 — Open the Remote Assist URL.** I opened that URL on my phone. I saw the actual browser — the GitHub login page, exactly as the agent left it. Click “Take Control” to interact with the browser directly.
**Step 2 — Complete the Login.** Once you click Take Control, you see the GitHub login UI. Enter credentials, complete OTP/2FA.
**Step 3 — Confirm Access.** After login, the GitHub profile page confirms the session is authenticated.
**Step 4 — Hand Control Back.** Click “Complete” in the top-right corner. The agent regains control immediately.
The session remains active for up to 1 hour, so there’s no rush.
## The Agent Resumes — Same Session, No Restart
After the human signs in and closes the remote-assist session, the agent picks up exactly where it left off:
```
# Agent checks state after handoff
browser-act — session research-gh state
```
Output:
```
url=https://github.com/settings/profile
title=Your profile
[14]<a class=color-fg-default />
Sarvar’s (simplynadaf)
[15]<a class=btn btn-sm />
Go to your personal profile
[16]<a /> Public profile
[17]<a /> Account
[18]<a /> Appearance
```
No login prompt. Full access to the authenticated session.
**Proof — navigating authenticated content:**
```
browser-act — session research-gh navigate \
https://github.com/simplynadaf/devsecops-pipeline-demo
```
Output:
```
url=https://github.com/simplynadaf/devsecops-pipeline-demo
title=simplynadaf/devsecops-pipeline-demo: DevSecOps Pipeline Demo with Security Scanning
new_tab=False
```
It shows the repo title instead of redirecting to /login. Same session. Same browser state. No restart. No lost context.
— -
## Why This Is a Design Pattern
Most automation falls into two camps:
- **Fully automated** — breaks when anything unexpected happens.
- **Fully manual** — defeats the purpose of automation.
The human handoff is a third option: the agent does 95% of the work autonomously. When it hits the 5% that requires a human — a login, a 2FA prompt, a CAPTCHA it can’t solve — it pauses, asks for help, and resumes.
I’ve been building automation for years. Every time I tried to make something “fully automated” that involved login-protected tools, it would break within a week. Session expired. MFA rotated. Cookie invalidated.
The answer was always “just add a human step” — but there was never a clean way to do that without killing the whole automation. This is the clean way.
— -
## It Runs Headless — On Any Server, Any Cloud
This entire test ran on a Linux server with no display. No screen. No desktop. The agent and [BrowserAct](https://browseract.com?fpr=sarvar04) run completely headless. But when remote-assist triggers, it gives the human a visual interface to that headless browser — through a URL.
You see the browser as if it were on your desktop — even though it’s running on a server with no monitor attached.
Here’s how this actually runs in production for my client:
**6:00 AM** — Cron triggers the agent on a headless Linux server
- Opens parallel sessions on 5 dashboards
- Extracts status data, takes screenshots
- Hits a login wall on one dashboard (session expired overnight)
- Sends remote assist URL to Slack
**6:01 AM** — Slack notification on the on-call engineer’s phone
- Taps the URL
- Sees the login page
- Signs in, taps MFA approve
- Closes
**6:02 AM** — Agent resumes
- Finishes remaining checks
- Posts morning report to team status channel
Authentication happens maybe once or twice a week. The agent handles everything else — every day. That’s the ratio: 95% automated, 5% human, zero broken pipelines.
### Morning Report Output
```
DAILY INFRASTRUCTURE REPORT — Mon Jun 15, 2026 06:04 UTC
Grafana (prod): All dashboards green. No alerts in 24h.
GitHub (org): 3 PRs merged overnight. 1 pending review.
AWS Health: No scheduled maintenance. All regions healthy.
Vendor Portal: SSL cert expires in 12 days. Ticket created.
Uptime Monitor: 99.97% across all endpoints (7-day avg).
Auth events: 1 remote-assist triggered (GitHub session expired).
Resolved in 38 seconds by on-call.
Next run: Tomorrow 06:00 UTC
```
— -
## The Honest Review
**What worked:**
- Human handoff works exactly as described. URL generates instantly, state persists after.
- The agent-to-browser integration is clean. Commands are simple, outputs are agent-friendly.
- Anti-detection gets through Cloudflare without the agent doing anything special.
- Headless mode on a server with no display works perfectly with remote assist.
- Parallel sessions are stable and independent.
- JS eval gives the agent precision extraction without any scraping libraries.
**What could be better:**
- Documentation is dense. The skill reference is thorough but overwhelming the first time.
- Error messages aren’t always helpful. “Connection closed” doesn’t tell you much.
- Speed is slower than raw Puppeteer. The anti-detection adds a few seconds per session.
- You need an API key for the stealth features.
**Cost:** Free credits on signup to test. After that, usage-based pricing on stealth sessions. For my production use case (5 sessions/day, ~2 minutes each), it’s negligible.
— -
## Getting Started
**Prerequisites:** Python 3.12+, Node.js 18+, Google Chrome, terminal access.
Install Chrome if needed:
```
# Ubuntu/Debian
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo apt install -y ./google-chrome-stable_current_amd64.deb
# Amazon Linux
wget https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm
sudo yum localinstall -y google-chrome-stable_current_x86_64.rpm
```
Install UV (Python package manager):
```
curl -LsSf https://astral.sh/uv/install.sh | sh
```
**Install BrowserAct:**
```
# Install the skill
npx skills add browser-act/skills — skill browser-act — yes
# Install the CLI
uv tool install browser-act-cli — python 3.12
```
**Configure:**
```
# Set your API key (get one at browseract.com)
browser-act auth set <your-key>
# Create a stealth browser
browser-act browser create — type stealth — name “my-agent”
```
That’s it. Your agent can now browse.
Works with Kiro, Claude Code, Cursor, Codex, CrewAI, or any tool that can run shell commands. The agent doesn’t need to be special — it just needs to call the CLI.
**Getting your API key:**
1. Log in at [browseract.com](https://browseract.com?fpr=sarvar04)
2. Click your profile -> “API Keys” -> “Manage Keys”
3. Click “Create Key” -> name it (e.g., “Production Agent”) -> Create
4. Copy the key immediately — you won’t see it again
> Treat your API key like a password. Never commit it to source code.
**Session management tip:** Always close sessions when done — open sessions consume resources. If you hit a “session already in use” error, that session name is still active. Close it or use a different name.
```
# List active sessions
browser-act session list
# Close a specific session
browser-act — session research-hn session close
```
**Note:** The browser ID shown in this article (101758963005571124) is from my account. When you run `browser create`, you’ll get your own unique ID. Use that in place of mine throughout the examples.
— -
## FAQ
**Can AI agents handle login walls?**
Not on their own. When an agent hits a login page, it can’t type your password or tap your MFA prompt. [BrowserAct](https://browseract.com?fpr=sarvar04) solves this with remote assist — the agent pauses, sends you a link, you handle the login, and the agent picks up where it left off.
**What is BrowserAct remote assist?**
A feature that lets your agent ask a human for help mid-workflow. The agent generates a URL that opens the live browser on your phone or laptop. You do the human step (login, 2FA, CAPTCHA), close it, and the agent continues. No restart, no lost state.
**Does BrowserAct need an API key?**
Yes, for stealth browser features. Free credits on signup to test with.
**Can this run on a headless server?**
Yes. That’s how I run it — Linux server, no display, no desktop environment. When the agent needs a human, the remote-assist URL gives you a visual interface from any device.
— -
## The Bottom Line
The browser was always the gap in agent automation. Not because agents can’t reason about web content — they can. But because the web is built for humans, and the moment authentication enters the picture, pure automation dies.
The human handoff pattern fixes this: the agent does 95% of the work, asks for help on the 5% it can’t handle, and resumes without missing a beat. It’s practical, it runs in production, and it replaced a workflow that used to break every other week.
If you’re a DevOps engineer, SRE, or cloud architect running AI agents — and your agents can’t touch the web — this is worth 30 minutes of your time to test.
**Resources:**
- [BrowserAct](https://browseract.com?fpr=sarvar04)
- [GitHub — BrowserAct Skills](https://github.com/browser-act/skills)
- [Documentation](https://github.com/browser-act/skills/tree/main/docs)
— -
Thanks for reading! If this was useful, give it a clap and follow for more on AWS architecture, DevOps, and AI Infrastructure.
What’s the messiest authentication flow your agents have to deal with? I’m curious what other engineers are automating around — drop a comment.
Connect with me: [sarvarnadaf.com](https://sarvarnadaf.com) | [LinkedIn](https://linkedin.com/in/sarvar04) | simplynadaf@gmail.com
