Logo
AWS Bedrock AgentCore Browser tool AI agents

AWS Bedrock AgentCore Browser tool: agent blocked by CAPTCHA verification

Fix an AgentCore Browser tool agent blocked by CAPTCHA: confirm you are permitted to automate the target, stabilise the browser session, and handle CAPTCHA as a typed state with human handoff.

Jerzy Kopaczewski ·
Your agent uses the Amazon Bedrock AgentCore Browser tool to act on websites, but the task stalls because the agent hits a CAPTCHA. Before you reach for a workaround, it helps to understand what a CAPTCHA is telling you: the target has judged the traffic to be automated and is asking for proof that a human is present. This runbook takes the responsible approach - confirm you are allowed to automate the target, stabilise the session so it does not look suspicious, and treat the CAPTCHA as an explicit state with a human handoff, rather than as something to defeat.

This runbook covers CAPTCHA blocks at the AgentCore Browser tool layer. For where the Browser tool sits in the platform, see Amazon Bedrock AgentCore: architecture and pricing. For help designing safe, terms-compliant agent automation, book a consulting session.

Symptoms

The agent reports no tool fault - it simply cannot finish the task on the page.

# In the agent / Browser tool logs
Agent blocked by CAPTCHA verification while interacting with the website
# The task halts on a verification screen; the agent either waits or
# loops, retrying the same step.

Observable impact:

  • The agent reaches the page but gets stuck on a CAPTCHA screen and goes no further
  • The same task sometimes passes and sometimes gets blocked, depending on session reputation and pacing
  • The agent retries the same step in a loop instead of recognising it hit a challenge
  • Sites behind anti-bot systems (for example Cloudflare) block more often

Cause

A CAPTCHA is not a tool fault; it is the target’s response to traffic it judged automated. The reasons fall into three layers, and the order matters.

  1. Permission and compliance - first. If you are automating a target that does not allow it (terms of service prohibit bots, no owner consent, an integration API exists that you are meant to use instead), the CAPTCHA is a symptom of the real problem: you should not be automating this target this way. This is the first thing to establish, not the last.
  2. Session stability and reputation. An agent that loses its cookies and session state between steps acts from a fresh, “clean” identity every time, which looks suspicious. Machine-fast pacing and an unstable browser session both raise the odds of being shown a CAPTCHA.
  3. No model of the CAPTCHA state. An agent that does not recognise it is on a verification screen treats the challenge page as ordinary content and retries pointlessly. Without a named state, a retry limit, and a stop rule, it loops instead of handing off to a human.

Rule of thumb: a CAPTCHA is a state to recognise and handle within the rules, not an obstacle to break through. Responsible automation starts by asking whether you are allowed to automate the target at all.

Fix

Step 1: Confirm you are permitted to automate this target

Before tuning anything, establish whether automating the target is allowed. Check the site’s terms of service and whether an official API or partner access exists that is meant for integration. If the target prohibits automated access, the right fix is not to get past the CAPTCHA; it is to change the approach.

  • If an official API exists, switch the agent from the browser to that API - this removes both the CAPTCHA and the fragility of scraping
  • If you are automating your own system or have the owner’s consent, continue to the next steps
  • If the target clearly prohibits bots and you do not have consent, stop - this is a compliance question, not a technical one

Step 2: Stabilise the browser session

An agent that keeps state between steps like a real user triggers CAPTCHAs less often. The goal is a consistent, persistent session, not disguise.

  • Preserve cookies and session state between steps instead of starting from a clean session each time
  • Keep a consistent browser context within the task so the target sees one continuous session, not a series of new ones
  • Make sure the page has fully loaded before the agent acts - frame switches and actions on a not-ready state look like a bot

Step 3: Slow down to realistic pacing

A machine-fast, perfectly even sequence of actions is a classic automation signal. Introduce realistic pacing and delays between steps so the interaction is not flagged as automated purely by its rhythm.

Step 4: Treat the CAPTCHA as an explicit state with a human handoff

Instead of letting the agent retry endlessly, model the CAPTCHA as a named state with session memory, an allowed human handoff, a retry limit, and a stop rule. That lets the agent name the situation and choose a responsible next action rather than spin in a loop.

  • Detect the CAPTCHA state and stop further automated actions on that step
  • Hand off to a human (human-in-the-loop) when verification is required - the same approach we use for sensitive agent actions
  • Set a retry limit and a hard stop rule so the agent does not hammer the target with retries

Validation

Confirm the agent completes the task without stalling on a CAPTCHA, and where verification is genuinely required, hands it to a human cleanly.

# Expected flow in the logs:
# 1. The agent keeps one continuous session (same cookies between steps)
# 2. Either the target shows no CAPTCHA, or the agent recognises the CAPTCHA
#    state and hands off to a human instead of retrying
# 3. No retry loop on the verification step

Expected: on a permitted target, with a stable session and realistic pacing, the agent completes the task without a challenge. Where a CAPTCHA does appear, the agent recognises it, stops within its retry limit, and hands off to a human - rather than retrying endlessly. If you run many browser-using agents, consistent rules for handling states like this are part of the wider governance we describe in agent sprawl.