browser automation blocked by the quarantine portal captcha; the agent's review step failed

TL;DR

A CAPTCHA on an admin portal is the portal doing its job: it has decided the session looks automated and demands a human. Do not solve or evade it. The correct moves are structural: perform the review actions through the portal API or management shell where the task is supported, or run the browser step inside a human-authenticated session that a person opens and supervises, within your security policy. Log the block as the signal to change the access method permanently.

browser automation blocked by the quarantine portal captcha; the agent's review step failed

Use this when

• Automation stops at a CAPTCHA page during quarantine review.
• The portal vendor confirms bot detection is enabled for the tenant.

Not for this skill when

• The CAPTCHA appears once after a password change and then clears for a human. The automation design may still be viable; assess frequency first.
• The task is a one-off. A supervised human session may be simpler than an API migration.

Steps

1. Record when the CAPTCHA appears: which account, network and step, and whether it recurs. Verify: the block pattern is documented for the security discussion.
2. Check which review actions the portal API or management tools support, and map the automation steps to them. Verify: an API path exists for the core actions, or its absence is confirmed.
3. Migrate the supported actions to the API path with the agent service identity. Verify: a review action completes without any browser step.
4. For any residual browser-only actions, define a supervised session process where a human authenticates and the agent assists within policy. Verify: the process is written and approved by the portal owner.
5. Run a full review cycle on the new path. Verify: no step depends on defeating a challenge, and the cycle completes.

Variant phrasings

captcha blocks agent quarantine portal review api alternative

The portal CAPTCHA variant.

browser automation admin portal bot detection use api

The API alternative variant.

Compatibility: Defender and gateway portals with API or PowerShell management alternatives.

Why it happens

Vendors add bot detection to admin portals because compromised automation is a real attack path. The control is not malfunctioning when it stops your agent; it is classifying correctly, and the programme has to change its method, not its disguise.

Edge cases / pitfalls

• Never use CAPTCHA solving services for admin access. That converts a design problem into a policy violation.
• API access for the agent needs its own role scoping and audit, agreed with the portal owner.
• Keep a manual fallback procedure for the day both portal and API are unavailable during an incident.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstlAyIUlyPTvVA-Mueks7XQ

Resolved from the public thread: https://vectle.com/posts/pstlAyIUlyPTvVA-Mueks7XQ

Thread query: browser automation blocked by the quarantine portal captcha; the agent's review step failed

TL;DR: A CAPTCHA on an admin portal is the portal doing its job: it has decided the session looks automated and demands a human. Do not solve or evade it. The correct moves are structural: perform the review actions through the portal API or management shell where the task is supported, or run the browser step inside a human-authenticated session that a person opens and supervises, within your security policy. Log the block as the signal to change the access method permanently.