browser automation failed when agent tried to open the quarantine portal

TL;DR

Admin portals resist automation: they redirect through SSO, demand interactive MFA, detect headless browsers, or move URLs between product updates. Before debugging selectors, ask whether the task should use the portal at all, since quarantine actions usually exist in an API or PowerShell. If the portal is genuinely required, stabilise the session: a persistent authenticated profile, the current portal URL, and explicit waits for the redirect chain to settle.

browser automation failed when agent tried to open the quarantine portal

Use this when

• The agent browser times out or lands on a login or error page for the quarantine portal.
• Portal steps worked until a product or URL change.

Not for this skill when

• An API covers the quarantine action. Migrate to it rather than repairing portal automation.
• The failure is a CAPTCHA or interactive MFA wall. That needs a human session design, not selector fixes.

Steps

1. Reproduce the failure manually in a normal browser with the agent account and record the exact redirect chain and final page. Verify: the human path and the agent path differences are documented.
2. Update the automation to the current portal URL and wait on a stable post-login element rather than a fixed delay. Verify: the browser reaches the quarantine list in a test run.
3. Persist the authenticated browser profile between runs so SSO is a resume, not a fresh login, within your security policy. Verify: a second run starts already authenticated.
4. Add a pre-flight check that confirms the portal loaded and the expected queue element exists before any action step runs. Verify: failures report as portal-not-ready with a screenshot, not as confusing downstream errors.
5. Run the full quarantine review flow on a test item. Verify: the item action completes and is visible in the portal audit.

Variant phrasings

browser automation quarantine portal login redirect fail

The portal login variant.

playwright admin portal sso persistent profile automation

The session variant.

Compatibility: Playwright and similar browser automation against Microsoft Defender and gateway admin portals.

Why it happens

Portals are built for humans with interactive identity checks, and vendors actively change them. Automation against them is a maintenance subscription, which is why the API question comes first in every repair.

Edge cases / pitfalls

• Portal UI text and layout change without notice. Anchor automation on stable labels and roles, not positions.
• Keep screenshots on failure by default; portal failures are illegible from exceptions alone.
• An agent account for portal automation needs the least role that can do the task, and its use should be auditable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vR98tVTqdLgmnxR68sT9Zg