# agent's browser automation blocked by bot detection during a security review

## TL;DR
The target's bot defenses can't tell your authorized review from an attack, which is them working as designed. Get explicit authorization, run against staging or a test account, and make the automation identifiable instead of trying to look human.

```text
agent's browser automation blocked by bot detection during a security review
```

## Use this when
- Browser automation for a security review hits challenge pages or blocks
- The review target uses Cloudflare, Akamai, or similar bot defenses
- Logins during the review trigger credential-stuffing rules
- You need the review to complete without fighting the defenses

## Not for this skill when
- You don't have authorization to test the target (stop; the block is correct)
- You want to evade bot detection on someone else's site (that's not a review)
- The block is a plain IP ban unrelated to automation signals

## Steps
1. Confirm you're authorized to test this target, in writing, with scope: the target, the time window, and the techniques allowed. If it's a third-party site you don't have scope for, stop here.
Expected: a written scope you can show the site owner or your auditor.

2. Ask the site owner for a test path: a staging environment, a test account, or an allowlisted source IP or user agent string for the review window.
Expected: the review runs without fighting the defenses.

3. If you must run against production-like defenses, identify the automation: a distinct user agent string, requests from the allowlisted IP, during the agreed window, at a polite rate.
Expected: the SOC can distinguish your traffic in their logs.

4. Keep the automation well-behaved: real delays between actions, no parallel tab storms, no CAPTCHA-solving services.
Expected: no bot-defense blocks, and nothing that looks like evasion in the audit trail.

5. Document what the automation did, step by step, for the review report.
Expected: the report shows deliberate, authorized actions.

### Variant: blocked by a named bot-defense challenge page
Same answer: authorization and allowlisting, not bypass tooling. The challenge page is evidence the defense works.

### Variant: review of your own login flow triggering stuffing rules
Use the test account the defenses expect, and tell the SOC the review window so they don't treat it as an incident.

### Variant: mobile-app API review hitting device attestation
Use the test build or the attestation bypass the vendor supplies for testing. Don't try to defeat attestation; that's out of scope for a review.

## Why this happens
Bot detection keys off automation signals: headless flags, input timing, navigation patterns, IP reputation. A security review driven by browser automation emits all of them. The defenses are doing their job; the fix is coordination, not stealth.

## Edge cases and pitfalls
- Never use residential proxies or fingerprint spoofing to dodge a block during a review; that turns an authorized test into something that looks like an attack and can burn the engagement.
- If the vendor won't allowlist, scope the review to what you can do without automation.
- Record the authorization alongside the findings; "the bot filter blocked us" is a finding about testability, not a failure.
- Rate limits still apply to allowlisted traffic; stay polite even when you're invited.

## Provenance

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