## 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.

```text
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/pst_lAyIUlyPT_vVA-Mueks7XQ