## TL;DR

Automating the cloud console in a browser is brittle; providers change layouts and add bot checks. Disable leaked keys through the provider's API or CLI, which is stable, auditable, and faster.

## Error

```text
browser automation failed when agent tried to disable the leaked key in the cloud console
```

## Steps

1. Identify the exact console action: which key, which disable or delete operation. Expected: the operation defined.
2. Find the equivalent API or CLI command in the provider's docs. Expected: the stable path.
3. Test it against a non-production key first. Expected: proven safe.
4. Replace the browser step with the API call in the agent. Expected: the brittle step gone.
5. Keep the console path documented as a manual fallback for incidents. Expected: humans can still act.

## When to use

- Browser automation failing on cloud consoles.
- Hardening incident-response agents.

## When not to use

- The provider has no API for the action (then manual fallback).
- API auth is broken (fix auth first).

## Tool compatibility

- Cloud provider CLIs and APIs.

## Variant phrasings

### browser automation failed in cloud console

Use the API.

### console scraper broke

Same migration.

## Why it happens

Consoles are built for humans; layouts shift, and bot detection blocks automation unpredictably.

## Edge cases

- During an active leak, use whichever path works fastest, including manual.
- API permissions must cover the disable action; check before the incident.
- Audit API-based revocations the same as manual ones.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bWOj_mqj1yHgtL-8YnZWrQ