August 12, 20266 min read

Why your AI agent keeps getting blocked (and how to fix it)

By The Masklabs team

An AI agent that browses the web is still just a program making HTTP requests, and most of them make those requests from a datacenter. Sites have spent years learning to spot that pattern: no residential ISP, no carrier, a block of IPs that only ever sees automated traffic. Your agent doesn't have to be doing anything wrong to get walled off. It just has to be calling from an address that looks like a server room instead of a phone.

The datacenter tell

A research agent that fetches a dozen pages, a computer-use agent clicking through a checkout, a scraping agent walking search results, they all make the same kind of request a person browsing from their phone would make. The difference sites key on is the IP. Datacenter ranges are well known and easy to block outright, throttle, or gate behind a CAPTCHA the agent can't solve. Route the same request through a real US mobile carrier IP and it looks like what it's supposed to look like: someone on a phone, on a normal connection, loading a page.

That's the whole premise of Masklabs. Exit addresses come from real phones on carrier networks, not a datacenter range, so an agent's traffic blends in instead of announcing itself.

Wiring an agent to the gateway

The gateway is one connection string. Point your agent's HTTP or SOCKS5 client at it and every request the agent makes goes out through a mobile exit:

http://mlabs_a1f9c3:<PASSWORD>@proxy.masklabs.io:8080
socks5h://mlabs_a1f9c3:<PASSWORD>@proxy.masklabs.io:1080

HTTP runs on port 8080, HTTPS on 443, SOCKS5 on 1080. That's it for setup. There's no SDK to install and no separate proxy service to run alongside your agent. Drop the string into curl, into a headless browser's proxy config, or into whatever HTTP client your agent framework already uses underneath, and the agent is browsing from a mobile IP without any change to how the agent itself works.

Rotating for breadth, sticky for a task

Agents don't all browse the same way, so the credential doesn't lock you into one mode.

  • Rotating (the default). Use the credential with no suffix and you get a fresh IP on every request. This is right for an agent doing breadth work: pulling search results across many independent sites, checking prices across a list of targets, or running any loop where each request doesn't depend on the one before it.
  • Sticky, for a task with steps. Append _sticky to the login and the gateway holds one IP for about three minutes. This is right for anything that has to look like one continuous session: an agent logging in, walking through a multi-page booking flow, or paging through results a site ties to the requesting IP. If the IP changes mid-flow, the site drops the session and the agent has to start over.
mlabs_a1f9c3_sticky:<PASSWORD>@proxy.masklabs.io:8080

Same credential, same password, just the suffix. You can also target a specific city with _loc_<CITY> across 46 US cities, useful when an agent needs to see the page a user in a particular market would actually see.

Spend visibility for a loop you don't babysit

The failure mode that's unique to agents isn't a blocked request, it's a retry loop that doesn't know when to stop. An agent stuck re-fetching a page, re-running a step, or looping on a bad selector will keep making requests until something external stops it. A credential with no cap can turn that loop into a bill you find out about after the fact.

Masklabs meters by the byte against your plan's included GB pool, and each credential carries its own usage line and an optional limit. Set a cap on the credential your agent uses and a runaway loop pauses when it hits zero instead of running up unbounded usage. You'll see it in the dashboard as one credential's line spiking, not as a mystery on the invoice.

Running more than one agent, or more than one environment, is the same pattern: separate credentials on one shared balance. A practical split:

  • agent-prod for the agent actually running in production, capped at whatever budget makes sense for the job.
  • research for a one-off agent doing exploratory browsing, capped low since it's not something you're monitoring closely.
  • staging for testing agent changes before they touch the production credential, so a bug in a new prompt or a new tool doesn't spend the production budget.

Up to 50 credentials can exist on one org, all drawing from the same prepaid pool, each one independently capped. When the pool runs low, add data at your plan's per-GB rate for the rest of the month rather than sitting on a fixed monthly overage.

The bottom line

An agent's requests fail the same way a human's would if it browsed from an obviously automated address, and datacenter IPs are exactly that. Give the agent a real mobile exit instead, rotate when it's covering ground, hold sticky when it's mid-task, and cap the credential so a loop you're not watching can't spend past what you intended. The agent's code doesn't change. Only where its traffic comes from does. See the quickstart for the full setup, or pricing for the GB pools.