As of 22 October 2026, a check at the edge stopped agents on a server before the sign-up page loaded at 13 products, and a signed agent Cloudflare already knows reached that same page at 8 of 13. The sign-up page opened for that signed agent at Canva, Freshdesk, Jotform, Kit, Later, Make, Mollie and Salesforce. Where the check sat on the form, a signature didn’t get our agent past it.
For an owner, the edge rule is the setting to look at before the form. For a builder, a signature a provider already knows can get your agent past an edge check; at the form, plan for a person to take that step.
Sign-up, not the API, is where our own path stops
Driving from a server, our agent stopped at sign-up or its verification at 95 of 148 products we drove. That is the step before any key, call or real work, so the API behind it never came into play.
As of 22 Oct 2026: our drives of 148 products, 1–22 Oct 2026 · Today's numbers
Data table
| Products | Out of | Share | |
|---|---|---|---|
| Stopped at sign-up or its verification | 95 | 148 | 64% |
What stopped it there differs by product: an edge check before the page loads, a challenge on the form, a phone number the form requires, or terms that allow only accounts a person makes.
Some of those stops aren’t bot checks. Help Scout took our address with no CAPTCHA, then asked for an SMS code to a phone number before the account existed. No bot-check setting changes that step; a sign-up route that doesn’t need a phone does.
For an owner, the fix sits on the sign-up path: the page, the bot check in front of it and the form. Good API docs and an MCP server don’t help an agent that never reaches them. For a builder, check where a product’s sign-up stops before you build against its API.
A signed agent Cloudflare already knows reaches the sign-up page
Fetched this way, the sign-up page opened at 109 of 131 products where we tried it, pages that open on every path included.
As of 22 Oct 2026: our drives of 148 products, 1–22 Oct 2026 · Today's numbers
Data table
| Products | Out of | Share | |
|---|---|---|---|
| Sign-up page opened for a known signed agent | 109 | 131 | 83% |
Canva, Freshdesk and Kit each put a Cloudflare challenge in front of the sign-up page (www.canva.com/signup1, the Freshdesk sign-up on www.freshworks.com2, app.kit.com/users/signup), and it stopped our agent. The known signed agent got the page at each of them.
Reaching the sign-up page isn’t a sign-up: every edge and signed-agent number here stops at whether the page loaded. Our agent signs every request with Web Bot Auth. Signed, not verified: during these drives no bot-check provider listed our agent as a verified bot, so a check could see the signature but had no verified identity to trust. The signed agent measured here is one Cloudflare already recognizes; ours was not that agent.
An agent in a person’s own browser wasn’t measured. A check that judged the network and browser stopped our signed agent at 58 of 96 products where a bot check stopped it.
On recordKitEmail marketingL1Needs a personWhere a Cloudflare edge stops a known signed agent, an owner’s own rule is the place to look
Since 1 July 2026, Cloudflare counts signed agents registered with it as verified bots, labelled Direct or Intermediary by who can operate them. Its docs say verified bots are left out of the default bot configurations on every plan (Cloudflare docs). So by Cloudflare’s own docs, where its edge still stops a signed agent it knows, look for a rule or block set on that site.
Cloudflare’s example of a bot-score rule leaves verified bots out in its opening condition: not cf.bot_management.verified_bot and not cf.bot_management.static_resource and not cf.bot_management.corporate_proxy and cf.bot_management.score lt 30
. Check that your own score rules carry the same exclusion.
If you want agents at sign-up and not elsewhere, AWS’s AgentCore docs list path rules among the policies an owner can set for signed agents: Permit authenticated agents to access only certain paths or resources on the website
.
Look at what a rule covers, too. At Make, sign-up, login and the OAuth consent page sit behind the same Cloudflare challenge: registering an OAuth client worked from our server, and the consent step then sent our agent to that challenged login.
Not every edge stop in our drives was Cloudflare’s: at Jotform, what our agent met was an edge rate limit, a 429 on the sign-up page’s own scripts.
A challenge on the form stops our signed agent at submit
The page loaded for our agent. The check decided when the form was sent.
As of 22 Oct 2026: our drives of 148 products, 1–22 Oct 2026 · Today's numbers
Data table
| Judged our network and browser | A challenge on the form | Total | |
|---|---|---|---|
| Stops | 58 | 38 | 96 |
Basecamp took the name, email, organization and password; the Create my account button opened an hCaptcha image puzzle. DocuSign showed an Arkose Labs puzzle after Get Started, on the developer sign-up and on the eSignature trial. Asana showed a Google reCAPTCHA checkbox after Continue on its work-email sign-up.
Cloudflare showed up at the edge and on the form in our drives. At Linear, the docs are open to agents, with llms.txt, every page as Markdown and the full GraphQL schema; the email sign-up then shows a visible Cloudflare Turnstile once the email is entered. Cal.com shows the same widget on app.cal.com/signup, and its auth.md says agents don’t register on their own.
We didn’t submit these forms on any other path, so this is what our agent on a server met at submit. For an owner who wants agents to sign up, the way past a form challenge is a documented route that doesn’t run through the form: let AI agents sign up shows the options. For a builder, a challenge at submit means a person takes that step.
Each provider treats a recognized signature differently
Cloudflare marks a verified bot in the rule field cf.bot_management.verified_bot (boolean) and a signed agent in cf.bot_management.signed_agent, so an owner can write rules on either. A builder registers a signed agent through the Bot Submission Form, Verification Method: Request Signature.
As of 22 Oct 2026: our drives of 148 products, 1–22 Oct 2026 · Today's numbers
Data table
| Provider | Stopped it | Let it through | Met it |
|---|---|---|---|
| Google reCAPTCHA | 41 | 10 | 51 |
| Cloudflare | 34 | 0 | 34 |
| hCaptcha | 10 | 0 | 10 |
| ALTCHA | 1 | 2 | 3 |
| Arkose Labs | 3 | 0 | 3 |
| The product's own check | 1 | 1 | 2 |
| Akamai Bot Manager | 1 | 0 | 1 |
| Castle | 1 | 0 | 1 |
| DataDome | 1 | 0 | 1 |
| Friendly Captcha | 0 | 1 | 1 |
| HUMAN Security | 0 | 1 | 1 |
| A check we couldn't name | 3 | 1 | 4 |
| Stytch device fingerprinting | 1 | 0 | 1 |
Vercel’s docs say its bot protection and Attack Mode recognize verified bots automatically and let them pass through without a challenge (Vercel docs). BotID passes the fields isVerifiedBot, verifiedBotName, verifiedBotCategory (botid >= 1.5.0) to the app.
DataDome blocks automated requests that carry no authentication: Any automated request coming from an unauthenticated bot or AI agent is categorized as "Threat Detection" and is blocked by default.
. It treats Web Bot Auth as an authentication method, and an authenticated agent then meets the customer’s own policy: Our customers can decide to authorize them based on their own bot policy.
. At the one product where our agent met it, GitHub, DataDome stopped our agent at sign-up with an access-restricted page.
HUMAN gives a high trust level to an agent it can verify on each request: HUMAN assigns High Trust Levels to agents when we can verify the agent via cryptographic key on each request.
. A HUMAN customer allows an agent to create an account or log in under Sightline Cyberfraud Defense > Policies > AI Agents Permissions: Account Creation and Login, per agent and application, and only for agents HUMAN knows: You can only manage permissions for AI agents that are known to HUMAN.
. At the one product where our agent met it, Webflow, HUMAN let our agent through: the email and password sign-up at webflow.com/signup went through with no challenge shown.
AWS’s AgentCore docs list Akamai among the vendors that verify these signatures and apply the site owner’s policies: Bot control vendors (such as Cloudflare, Akamai Technologies, and HUMAN Security) can verify these signatures against public key directories and apply appropriate policies configured by website owners.
. At the one product where our agent met Akamai Bot Manager, Salesforce, it refused our agent on the Developer Edition sign-up with a 403 and no challenge shown.
If your sign-up runs behind any of these, your provider’s setting above is where a signed agent gets let in or kept out. Which bot checks stop AI agents has each provider’s results in our drives.
