---
published: true
layout: post
title: Forcing People to Prove They Are Robots When You Are All In On AI
image: https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/forcing-people-to-prove-they-are-robots-when-you-are-all-in-on-ai.png
date: 2026-09-07
author: Kin Lane
tags:
  - Onboarding
  - Authentication
  - Agents
  - AI
  - APIs.io
---

There are a number of contradictions that grind my gears in today's market. I recently wrote about [enterprises pushing teams to reduce their cloud spend while simultaneously tokenmaxxing when it comes to AI](https://apievangelist.com/2026/07/28/the-dissonance-of-reducing-cloud-spend-and-going-all-in-on-ai/). Another thing I am seeing from companies that confounds me is the declaration that they are all in on agentic AI, while requiring me to prove I am not a bot when signing up to use their API. Those two positions are at odds with each other, and the unsophisticated approach to understanding who is an agent and who is a human is an anti-pattern that demonstrates where you are in your journey.

Having a bot CAPTCHA on the signup for your APIs is a signal in the same bucket as companies who don't want to have API portals or publish API documentation because it might give something away to the competition. Asking a human to prove they are not a bot when signing up for API access, while also declaring you are all in on the agentic market, demonstrates a lack of strategy. You are just responding to the wind blowing and what emotions you have in any given moment. I get having bot detection if you are not all in on agentic AI, but both at the same time confuses me when I am signing up. Especially when I am having to exit out of Claude, visit your API portal, and convince your signup that I am a human being.

## Approaches You Can Take

I am not asking anyone to turn off abuse prevention. I run APIs. I know what shows up at the door. What I am asking is that the door you build match the story you are telling about agents, and there is a spectrum of ways to get there — none of which require you to rebuild your portal this quarter.

**Say out loud which door actually exists.** Before you fix anything, describe it. After writing single-file onboarding scripts for [36 providers](https://apievangelist.com/2026/07/02/what-36-providers-taught-me-about-programmatic-api-onboarding/) I found there are only three honest answers to "can a stranger or their agent get working credentials?" — *self-serve*, where a public flow exists end to end; *bootstrap-token*, where you have a real management API but the very first token is minted by a human in a console; and *console-only*, where a browser UI is load-bearing and there is no programmatic path at all. That is the `maturity` field in the [API Onboarding Descriptor](https://apicommons.org/onboarding/) I published at API Commons, sitting at `/.well-known/api-onboarding` next to your OpenAPI. The descriptor also has an `account.agentPolicy` field with four values — `allowed`, `allowed-with-attestation`, `prohibited`, `unspecified` — and I will be blunt about why it exists: it is the honesty field. If your signup runs a CAPTCHA, your agent policy is `prohibited` no matter what your homepage says, and publishing that is still better than the current situation, where I only find out after I have left my terminal. A machine-readable contradiction is a contradiction someone can fix. An unwritten one just wastes my afternoon.

**Move the challenge off the front door and onto the behavior.** CAPTCHA at signup is the cheapest place to put bot detection and the most expensive place to have it, because it is the one moment when you know the least about the visitor and are charging them the most to arrive. You have far better signal ten minutes later: request rates, spend velocity, egress volume, scope escalation, the shape of what an account actually does. Put your friction on the ten-thousandth call, not the first one. Issue keys that start in a small sandbox with a low quota and a hard spend cap, and let usage — not a puzzle about traffic lights — decide who graduates. This is the same instinct that makes rate limits work: you are not trying to guess intent at the door, you are bounding the blast radius of being wrong. Providers who already publish real `plans`, `rate_limits`, and FinOps artifacts have most of this machinery built and are simply not using it as the front line.

**If you cannot open the door, at least open it once.** The bootstrap-token pattern is the pragmatic middle and it is where the overwhelming majority of the market already lives — twenty-five of the thirty-six providers I profiled. A human logs in one time, mints a management credential, and pastes it into an environment variable. From that point every application, every client, every rotation is scriptable. Kong Konnect's `kpat_`, Slack's app configuration tokens, Cloudflare's tokens-minting-tokens model, Stripe's restricted keys — all of these mean my agent never has to see your login screen again. If you are going to keep a CAPTCHA on human signup, this is the minimum viable answer: charge the human tax exactly once, then get out of the way. What breaks this is when the console is also the only place to create an app, because then the tax is not once, it is every single time.

**Give agents a registration mechanism that was designed for them.** The handshake layer is getting standardized without any of us, and you can adopt it now. RFC 7591 dynamic client registration has been sitting there for a decade, and Stytch ships genuinely anonymous DCR built explicitly for the agentic case — an agent registers itself, gets a client ID, and starts working. The Model Context Protocol authorization spec now points at Client ID Metadata Documents, where the `client_id` is a URL and domain ownership is the trust anchor, which is a far better answer to "who is this software" than a CAPTCHA ever was. GitHub's App Manifest flow does this without any new spec at all: approve in the browser, exchange a one-time code unauthenticated, walk away with a client ID, secret, webhook secret, and private key in a single response. Slack does it with a Manifest API, Salesforce with ConnectedApp metadata. These are not exotic. They are shipping today, at companies your size.

**Stop asking whether it is a human and start asking whose it is.** The whole premise of the CAPTCHA is a question that stopped being useful the moment agents became legitimate traffic. "Is this a human" was always a proxy for "is this accountable," and it is now a bad proxy in both directions — it blocks the developer who is working through Claude, and it does not stop anyone who wanted to pay for a solver. The question worth building around is attestation: which identity is this agent acting on behalf of, what did that principal consent to, and what is the ceiling on what it can spend or reach. That is why the descriptor has `allowed-with-attestation` as a distinct value from `allowed` — plenty of providers will legitimately want agents to show up carrying a delegation, not to be turned away. Sender-constrained tokens, DPoP and mTLS, on-behalf-of grants, per-agent spend caps: these give you an accountable answer instead of a demographic guess, and unlike a CAPTCHA they keep working after the credential is issued.

**Write down the gates you are not going to remove.** Some friction is real and is not going anywhere — a plan tier, a ToS acceptance, an org admin approval, a marketplace review queue, a compliance check on a regulated endpoint. Fine. Declare them. The descriptor's `verification` array takes a name, whether it is `blocking`, and an `expectedLatency` in honest human units — "instant," "days," "30-day admin window." The difference between a gate I can see in a JSON file and a gate I discover on step four of a signup form is the difference between planning around your API and abandoning it. Every provider has a `gaps` section in their descriptor for exactly this reason. Mine does: apis.io is keyless at the free tier and I say so, and I also say that paid key issuance still runs through a human, because it does.

**Then check whether the catalog can see any of it.** This is the part that keeps me honest, because I score this across the whole network. Of the 27,497 providers in the [APIs.io](https://apis.io) catalog, 4,757 present enough signal for the catalog to mark them self-serve, 551 gate access behind an approval process, and only 415 — about one and a half percent — are open enough that you can make a call without an account at all. The other 21,263 give off no readable signal about how you get in whatsoever. Not "they are hard to onboard." Unknown. Unstated. There is no plans artifact, no authentication artifact, no discoverable signup, nothing a machine could read to tell an agent what to do next. That number is the real state of onboarding in the middle of the agentic AI boom, and it is worse than the CAPTCHA, because a CAPTCHA is at least a door I can see. If you want to know where you land, the onboarding view is on your provider page and the filters are `?onboarding=` and `?try_now=` on the API — go look at yourself the way an agent sees you.

**Finally, do the thing I did, and try to onboard yourself as an agent would.** Not a demo. Open a terminal, forget you have credentials, and write the single file that goes from nothing to a working key against your own API. You will find the wall in about ten minutes, and it will not be where your roadmap says it is. It was not for any of the thirty-six providers I did this to. Every one of those scripts is a company that believed onboarding was solved until someone tried it from the outside with no browser session and no employee badge.

## The Signup Form Is the Tell

None of this is really about CAPTCHA. A CAPTCHA is a reasonable tool that a lot of reasonable people deploy for good reasons, and if you are not chasing the agentic market I have no argument with you at all. What I am reacting to is the gap between two artifacts produced by the same company in the same week — the press release saying you are all in on agentic AI, and the signup form asking me to identify the crosswalks. Both of those are real, both were shipped, and they were shipped by teams that clearly have not spoken to each other. That is the actual finding. The signup form is not a security decision I disagree with, it is a strategy leak, and it tells me the AI position lives in marketing and has not reached the people who own the front door.

I have watched this exact movie before. Fifteen years ago the argument was whether you should publish your API documentation publicly, and the objection was always that it would give something away to competitors. The companies who held that line did not protect anything. They just made themselves unusable, quietly, while the companies who opened up got integrated into everything. The front door is having its version of that moment right now. Onboarding is the new documentation, agents are the new developers, and "we cannot let just anyone in" is going to age about as well as "we cannot let just anyone read our docs."

The good news is that the ask here is genuinely small, and I ranked the approaches above from smallest to largest for a reason. You do not have to open your door tomorrow. You have to describe it accurately — one JSON file at a well-known path, saying which of the three doors you have, what your actual agent policy is, which gates are not going away and how long they take. That takes an afternoon. What it does not let you do is keep telling two different stories to two different audiences, because once the truth about your front door is machine-readable, the contradiction becomes something anyone can query. Including me. Especially me.

So pick one. Be all in on agents and open a path for them, or do not be and say so plainly — both of those are coherent positions I can plan around and write about fairly. What I cannot do anything with is a company that wants credit for the agentic future while making me leave my terminal, visit a portal, and prove to a robot that I am not one.