## TL;DR
Stop looping on the login page and find out which sign-in step the automation cannot complete, because consoles like the AWS IAM console policy page use redirect based single sign-on, MFA prompts and consent screens that a naive browser flow cannot pass. Prefer the AWS IAM API for this step if it exists, since API access is the stable path for agents. Where the UI is unavoidable, use the approved automation account with its enrolled second factor method, a persistent browser profile, and a human handoff point for any interactive challenge.

```text
browser automation failed on AWS IAM console policy page: agent stuck on the login page with error
```

## Use this when
- The agent browser session sits on the login page for the AWS IAM console policy page and the run fails.
- Sign-in works for a human in a normal browser but not in the automation session.
- The page changed, a consent or MFA screen appeared, or the session expired mid-run.

## Not for this skill when
- The account credentials themselves are wrong or the account is locked. Restore the account through the normal route first.
- The agent reaches the page but reads the wrong data. That is a page reading problem after successful sign-in.

## Steps
1. Capture what the automation actually sees: a screenshot or page text at the stuck point, the address it is on, and the last action before the stall, saved with the run log. Verify: the stuck state is evidenced rather than described from memory.
2. Walk the same sign-in manually in a clean browser with the automation account and note every step the flow demands, including redirects, MFA prompts, consent screens and device checks. Verify: every interactive step in the flow is listed in order.
3. Check whether the step to revoke a stale IAM role is available through the AWS IAM API or an official export, and switch the workflow to that path if it is, keeping the browser flow only as a fallback. Verify: the workflow uses the API path, or the reason it cannot is documented.
4. If the UI path must stay, configure the automation with a persistent profile for the approved automation account, complete its MFA enrolment with an approved method, and add waits for the redirect chain instead of fixed short timeouts. Verify: a fresh automated sign-in reaches the signed in landing page.
5. Add a human handoff for any step that must stay interactive, such as a push approval, so the run pauses and notifies instead of circling the login page until it fails. Verify: the workflow pauses with a clear handoff message when the interactive step appears.
6. Run the full step to revoke a stale IAM role through the repaired path and confirm the resulting data matches a manual spot check in the console. Verify: the automated result matches the manual check for sampled items.
7. Record the sign-in design, the account used and the handoff rule in the workflow notes, and alert the team that console redesigns will break this flow before API changes will. Verify: the notes describe the working sign-in path and its fragility.

## Why it happens
Admin consoles are designed to keep automated sign-ins out: they layer federation redirects, risk based challenges and MFA on top of the login form, and they change layout without notice. An agent that treats the console like a stable API surface will keep meeting new interactive steps it cannot pass. The robust pattern is API first, and where a console is genuinely required, an explicitly designed sign-in with an enrolled automation identity and a human handoff for the steps that are interactive by policy, not by accident.

## Variants and edge cases

### agent cannot get past login on AWS IAM console policy page
The stall phrasing. Capture the actual page state first; login page can mean credentials, MFA, consent or a broken redirect.

### browser automation session expires during access review
The session phrasing. Persistent profiles and API steps reduce how much of the run depends on one long browser session.

### use API instead of console to revoke a stale IAM role
The better path phrasing. If an official API or export covers the step, it is almost always the right answer for an agent.

Edge cases to check before closing the review cycle:
- Never assume a timed out call did nothing. Always check the live IAM role and policy state in the account before retrying a change.
- Two retries at the same settings prove nothing. Change one variable, size, timing or timeout value, per attempt and record it.
- Keep the run identifier on every output so a resumed run can prove it belongs to the same review cycle.

Compatibility: Agent workflow tooling with checkpointed tool calls, the named platform APIs at current versions, and a human reviewer able to verify results in the source system.

## Provenance

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