What does bot detection mean?

Bot detection is deciding whether the thing on the other side of a signup, a login, a form, a purchase, or a call is a person rather than software, and turning it away if it is not. The mechanics are usually some mix of device and browser fingerprinting, IP and network reputation, challenges like CAPTCHA, and behavioral signals such as typing and mouse movement. The definition is stable; what changed is that both of its assumptions failed at once. Generative models made a convincing human cheap to fake, so passing the check no longer proves much, and legitimate AI agents now arrive as software acting for real paying customers, so failing the check no longer proves much either. The useful modern framing is that bot detection is one input to an authorization decision, not the decision itself.

Does CAPTCHA still work against AI?

Not as a proof of humanity, and it never really was one. A CAPTCHA was a price rather than a proof: it worked while solving it programmatically cost more than the abuse was worth. Models and cheap solving services collapsed that price. Y Combinator's framing of the wider problem covers CAPTCHA exactly: every trust signal we had was built for a world where faking a human was expensive. CAPTCHAs still do something useful, which is add friction and cost to high-volume automated abuse, so keep them at the volume-sensitive edges like bulk signup and password spraying. Do not let one sit in front of an irreversible action and count as the authorization for it. And be aware that a CAPTCHA now also blocks the legitimate agent traffic that is trying to buy from you.

Should I block AI agents from my product?

Block undeclared automation, not agents. Those are different populations and most bot defenses cannot tell them apart. An agent operating for a named customer, under that customer's credentials, inside published rate limits, is a customer with an unusual client. Y Combinator's Software for Agents request for startups argues the next trillion users of the internet will be agents rather than people, and that they need to be able to discover, sign up for, and start using tools programmatically without a human in the loop. If your front door has no lane for that, you are not neutral about it, you are opting out of the buyer. The cheaper posture is to publish a declared path (keys, scoped OAuth on behalf of a user, documented limits, terms) so that refusing the front door becomes the signal you enforce on.

How do you tell a real customer from a deepfake on a call?

Not from the call. In early 2024 a finance employee at the engineering firm Arup joined a video call with people who looked and sounded like his CFO and colleagues and authorized transfers of HK$200 million, roughly $25 million, and every other participant was synthetic. Any control whose only test is whether you saw and heard the person now fails against that attack. What still works is out-of-band verification tied to something the attacker does not control: confirming a payment or bank-detail change through a channel and a phone number you already had on file rather than one supplied during the request, requiring two named approvers above a threshold, and enforcing a delay on first payments to a new destination. These are process controls, not detection, and they are the part a startup can put in place in an afternoon.

Bot Detection When Bots Are Your Customers

Bot detection is deciding whether the thing on the other side of a signup, a login, a form, or a video call is a person, and turning it away if it is not. That job broke in two places at once.

Faking a person got cheap, so passing the check stopped proving much. At the same time a growing share of the traffic you actually want is software acting on behalf of a real customer, so turning away everything non-human started costing you revenue. Plenty of startups are still running a door policy designed for a world where neither of those was true.

This is not a call to buy a better wall. It is a call to change the question the wall is asking.

The signal you relied on was a price, not a proof

Y Combinator opened a request for startups on this problem with the case that makes it concrete: a finance worker joined a video call with his CFO and several colleagues, wired out $25 million, and every other person on that call was a deepfake.

That case is real and it is worth knowing the details, because they are the ones that generalize. The company was the British engineering and design firm Arup. The loss was HK$200 million, about $25 million, from its Hong Kong office in early 2024. Hong Kong police described the case publicly that February without naming the company, and Arup confirmed in May that it was the victim, as CNN and The Guardian reported. An employee sat in a meeting with what appeared to be several familiar colleagues and did what the meeting told him to do.

The diagnosis in YC's video is the part to pin above your threat model, not the anecdote: "Every trust signal we have was built for a world where faking a human was expensive". A face on a video call. A voice on the phone. A selfie next to a driver's license. A CAPTCHA that a script found annoying. None of those were ever proofs of anything. They were prices. They held up because forging them cost more than the fraud was worth, and generative models cut that price close to zero. YC's summary of where that leaves us is blunt: "we don't really have a good way to tell who is real online anymore."

Notice what this does and does not break. It does not break cryptography, and it does not break a check tied to something an attacker has to actually possess. It breaks every check whose entire security came from a human being hard to imitate. If you list your controls and mark the ones in that second category, that list is your real exposure this quarter, and for most startups it is longer than expected: payment-detail changes approved on a call, account recovery decided by a support agent's judgment, enterprise onboarding where somebody eyeballs a document, voice as the second factor on a phone-based flow.

Your best new traffic is also a bot

Now the second break, and founders underrate it because it does not arrive looking like a security problem. It arrives as flat conversion.

In a separate request for startups, Software for Agents, YC makes the demand-side argument directly: "The next trillion users on the internet won't be people. They'll be AI agents." Then it spells out what those agents need from your product. They need documentation good enough to let them "discover, sign up for, and instantly start using new tools programmatically without needing a human in the loop."

Put that sentence next to your bot defenses. Signing up programmatically, with no human in the loop, is the precise behavior your signup flow was built to stop. Out of the box, your fingerprinting, your challenge, your velocity rules and your headless-browser heuristics cannot tell a scraper farming your content from a paying customer's assistant trying to open an account. They fire on both, because the thing they measure is the same in both cases. Some stacks now ship allowlists for known good crawlers and agents, which helps, and which is worth turning on. But an allowlist is a list of the agents somebody else already vouched for, and your customer's assistant is usually not on it.

On YC's Lightcone, the hosts trace what that does to an entire category. Email is the example. Getting a personal agent its own inbox at a mainstream provider is hard on purpose, because Gmail and the others have "intentionally made it as difficult as possible for any automation" to use the product, in order to prevent spam. That is a defensible anti-abuse decision, and it also left a hole. A company called AgentMail went the other way and built an email provider designed for agents rather than defended against them. On that episode the hosts say it was already doing well before OpenClaw and that its usage exploded once OpenClaw got big, which is their account rather than a figure either of us can check.

That is the strategic point in one story. The same traffic is abuse from inside one company's rules and a product category from outside them. Whether it is one or the other has nothing to do with whether a human is present.

The reasonable objection is that this is a lot of theory to hang on early agent traffic. Fair. But you do not have to bet on the timing to act, because the two moves that follow, publishing a declared path for automation and putting out-of-band confirmation on money movement, are cheap and are worth doing on today's volumes.

Bot detection is an authorization question, not a human test

The sharpest statement of why comes from an unrelated question. On YC's Lightcone the hosts were asked when YC will accept applications from agents, and their answer is a principle that transfers directly to your front door. They compare agents to minors, except with even less standing: an agent is not a legal entity, it cannot sign anything, and a human still has to stand behind whatever it does as what the panel calls the liability sink. As long as that holds, whether a human is present is not even the question you need answered. You need to know whether an accountable party stands behind the session and whether they authorized this specific action.

Anyone who has done security work will recognize the error immediately. This is authentication and authorization collapsed into a single check. Bot detection took a weak authentication signal (does this behave like a person) and asked it to carry an authorization decision (is this actor allowed to do this). That was always shaky. It is now indefensible, because the signal is both forgeable by attackers and failed by legitimate customers.

Three questions replace the binary at your front door:

Who is accountable? Is there a named person or legal entity behind this session, with a credential they had to obtain, and a record connecting them to it? A deepfaked face on a call has no accountable party behind it. An agent using a customer's scoped API key does.
Is the actor declaring itself, and is there a lane for it? Declared automation is a customer with an unusual client. Undeclared automation pretending to be a browser is the thing you actually want to stop. You can only enforce that distinction if the declared path exists.
Does the behavior match the declared purpose? A key issued for a customer's support integration that starts enumerating other customers' records is the signal, regardless of how human the traffic looks.

None of that requires new technology. It requires you to stop asking your front door to answer a question it cannot answer, and start asking it questions it can.

Build the declared lane before you build a better wall

The practical version, in order of what pays back fastest:

Publish an agent path. Scoped API keys, OAuth on behalf of a named user, documented rate limits, and terms that say plainly what automated use is allowed. This costs a sprint. It converts the traffic that is currently bouncing off your signup, and it is the precondition for everything else, because you cannot penalize undeclared automation while giving it no declared alternative.

Make refusing the front door the signal. Once a supported path exists, automation that impersonates a browser to avoid it has told you something about intent that no fingerprint could. Enforce on that, not on the presence of automation.

Keep humans on the irreversible actions, not on the volume. Moving money to a new destination, changing payout details, granting admin, deleting data, and bulk export are where you want a second accountable human. Reads, searches, and routine writes are where agents should be welcome. It is easy to end up with this exactly inverted: a CAPTCHA on the signup form and a single support agent's judgment on the wire transfer.

Write down what an agent may do on a customer's behalf. If you are shipping agent features yourself, the same discipline applies internally. Our post on self-hosted AI agents covers the deployment side of that tradeoff, and the same principle drives it: scope the credential to the job, not to the user.

What catches abuse now is relationships, not challenges

If per-session challenges are weak, what is strong? The most useful answer we have found from someone doing this at scale is that abuse is visible in relationships and history rather than in any single interaction.

Variance is a useful witness here because it does this work for platforms most people have used without knowing it. Co-founder Karine Mellata, who was a data engineer on Apple's fraud engineering team before starting the company, described the work on Y Combinator's founder fireside, around the company's Series A, which FinTech Futures and SecurityWeek both report as $21.5 million. Take her example of GoFundMe, where a public death produces a spike of fundraisers claiming to be from the family, most of them fraudulent, against the one that is real. Every one of those pages is created by a human, so a humanity check has nothing to say about them. What does separate them, in her words, is that "there's a lot of behavioral signals you can use to do so": the identity behind the account, what the account has done before, and the artifact itself.

The stronger version is the graph. What made the coordinated cases catchable, in her account, was agents with "access to the context of entities in relation to other entities" rather than any better per-item model. Her point about why the older shape could not do it is the one that transfers: "I don't think this would have been possible if you had one classifier in isolation that was looking at one piece of content after the other."

The founder translation is uncomfortable but cheap to act on. The signal you need is mostly already in your database, unjoined. Account age, device and login history, who invited whom, which accounts share a payout destination or a support contact, what this actor did in its first hour. A per-session bot score cannot see any of that, which is why it catches the lazy attacks and misses the ones that cost you money. The full argument for rebuilding the review stack around that, including why the speed of the feedback loop matters more than model accuracy, is in our piece on AI fraud detection.

One caution before you automate that queue, because it is the part teams skip when they get excited about this. The automation takes the volume, not the hard part. It concentrates the difficult cases rather than removing them, so budget for the human review that is left and for the tooling those reviewers need.

Fix the call before you fix the model

The deepfake half of this problem has a boring fix that most startups have not done, and it needs no detection technology at all.

The Arup-class attack defeats any control whose only test is whether you saw and heard the person. So stop making that the test on the actions that move money or access. Confirm bank-detail and payout changes out of band, through a channel and a number you already held on file, never one supplied during the request. Require two named approvers above a threshold you set deliberately. Hold first payments to a new destination for a fixed delay. Give finance explicit permission to break protocol and call back, so that the social pressure of a video call with the boss is not what decides it.

These are process controls, and they are unglamorous, and they work precisely because they do not depend on telling real from fake. They depend on the attacker not controlling the second channel. Write them down this week and tell the team the rule is the rule even when the CFO is on screen asking otherwise.

On the offense side, the same economics that made faking a person cheap are reshaping how you get attacked in the first place. We covered that in AI penetration testing, and the short version is that an automated attacker takes the cheapest path available, which is usually a leaked credential rather than anything clever.

The trust layer itself is the startup

If you are looking for the company rather than the control, YC is explicit about the size of it. Their framing is that rebuilding the trust layer of the internet, knowing there is a verified human on the other end of a call, a message, or a transaction, is one of the most important problems of the next decade. Then the stake: "Whoever builds this becomes the layer every bank, app, and video call will check before it trusts anyone."

Two constraints separate a real attempt from a demo. The first is the one YC names and most entrants ignore: "Ideally, it's one that doesn't make everyone give up their privacy." A system that proves personhood by centralizing everyone's biometrics or identity documents has traded one systemic risk for another, and our expectation is that it meets regulators well before it meets scale. The second is that the value is in being checked, not in issuing. A proof nobody verifies is a database. That makes this a distribution problem wearing a cryptography costume, which is a very different company to build than most founders assume when they start.

And the upside is not only fraud prevention. YC's own list is the consumer version: a feed with no bots in the replies, a dating app where every match is a real person, reviews written by people who actually bought the thing. For a founder, the near-term reading is simpler. Whichever side of this you are on, the distinction that pays is the one between an accountable actor and an anonymous one, not the one between a human and a machine. The broader map of where this fits alongside the rest of the AI stack is in our pillar on AI for startups.

What to do this week

List every control whose only proof is a human being hard to fake. Voice on a call, a face on video, a support agent's judgment on account recovery, an eyeballed document. That list is your exposure, and it is the one thing here that takes an hour.
Put an out-of-band confirmation on payment and payout changes. Callback to a number already on file, two named approvers above a threshold, a delay on first payment to a new destination. Ship it before anything else on this list.
Publish a declared path for automation. Scoped keys or OAuth on behalf of a user, documented rate limits, terms that say what is allowed. Then measure how much traffic moves onto it.
Join the signals you already have. Account age, device and login history, invite graph, shared payout destinations and contacts. One query across those will out-detect your per-session bot score, and you own the data already.
Move your human review to where the hard cases are. Take the CAPTCHA off the low-risk form, put a second accountable human on the irreversible action, and staff the queue for the small percentage that genuinely needs judgment.

If you are building the operating system your company runs on rather than a one-off control, that is the whole subject of AI Operating System for Startups.

Sources

Proving You're Human, Y Combinator's request for startups, the source this article distills: the collapse of expensive-to-fake trust signals and the case for a rebuilt trust layer.
Software for Agents, Y Combinator's request for startups, for the demand side: agents as the next trillion users, and their need to sign up and start using tools with no human in the loop.
The AI Agent Economy Is Here on Y Combinator's Lightcone, for email providers deliberately blocking automation, AgentMail as the inverse product, and the argument that an agent still needs a human as the liability sink. The transcript does not label which host is speaking, so these points are credited to the panel rather than to any one of them.
This Startup Catches Fraud at Scale on Y Combinator's founder fireside, for behavioral signals, entity graphs over per-item classifiers, and the share of cases that still needs a human.
On the Arup deepfake case: CNN and The Guardian, both reporting Arup's confirmation of the HK$200 million loss. One note on the date: police described the case publicly in February 2024, while Arup has said it alerted Hong Kong authorities at the beginning of that year, so this article says early 2024 rather than pinning a month to the call itself.
Background on the company and person named: Variance on Y Combinator and its Series A as reported by FinTech Futures and SecurityWeek; Karine Mellata on LinkedIn.