Bot Protection Without CAPTCHA: Why Agent Identity Changes Everything
AWS's Web Bot Auth moves bot defence from detection to cryptographic identity. We explain the shift, the gaps, vLEI as a neutral alternative — and why real protection never stops your users from clicking.
Think about the last time a CAPTCHA stopped you mid-task. You were trying to log in, submit a form, or complete a purchase — and suddenly a grid of blurry traffic lights appeared, demanding proof of your humanity. Annoying for you. And here is the uncomfortable truth: it probably did not stop a determined bot.
That frustration is the starting point for a significant shift happening right now in how the web handles bot protection without CAPTCHA-style friction. In October 2025, Amazon Web Services quietly shipped something that signals a much deeper rethink: Web Bot Auth, a draft IETF protocol built into Amazon Bedrock AgentCore Browser. The idea is deceptively simple — instead of asking "does this traffic look human?", the protocol asks "can this agent cryptographically prove who it is?"
What is bot protection without CAPTCHA? Bot protection without CAPTCHA is any approach that stops automated abuse without ever asking a human to solve a puzzle. Instead of an image grid or a checkbox, it verifies the visitor — or the agent — invisibly in the background, using behavioural signals, device telemetry, or cryptographic identity, so legitimate users pass straight through and never know the protection is there.
We have been following this closely at TrustSig. In this post, we share what we think it gets right, where the gaps still are, what a genuinely robust identity system would need — including a third-party approach built on the GLEIF vLEI ecosystem that almost nobody is talking about yet — and why the right answer to bot abuse is never to make your forms harder to use.
What AWS Built — and the Admission Hidden Inside It
Web Bot Auth works on a straightforward principle. When an AI agent is created inside Amazon Bedrock AgentCore Browser with signing enabled, AWS issues it cryptographic credentials. Every HTTP request the agent makes carries a signature derived from those credentials. At the WAF layer — AWS's own WAF, Cloudflare, Akamai, and HUMAN Security have all signed on — the signature is checked against a directory of trusted agents. If the domain owner has configured their site to allow verified bots, the request goes through without a CAPTCHA challenge.
Domain owners get three policy options: block all automated traffic entirely, allow any agent that presents a valid signature, or set granular per-agent rules. A financial services company, for example, could allow a specific partner's agents to query their portal at a defined rate while blocking everything else — including other signed agents.
That is the technical summary. But what matters more is what the announcement signals. By building this, AWS is effectively acknowledging that behavioural bot detection — the approach that has dominated the industry for a decade — is running out of road. AI-generated traffic grew 187% between January and December 2025 alone. Modern bots can now mimic human mouse movements, dwell times, and form interactions convincingly enough that detection is becoming more lottery than science. Web Bot Auth is the industry's way of saying: we cannot win this arms race forever, so let us change the question entirely.
AI-Generated Traffic
+187%
growth in a single year (Jan–Dec 2025)
The actual shift. Before: "Does this traffic look like a bot?" — probabilistic, and increasingly unreliable. After: "Can this agent prove who it is?" — cryptographic, and deterministic.
This is not an incremental CAPTCHA improvement. It is a different problem statement.
A Good Direction — With a Real Abuse Problem Baked In
We want to be clear: the direction is right. Moving toward cryptographic identity for AI agents is the correct long-term architecture. However, there is a meaningful gap between the direction being correct and the current implementation being abuse-resistant.
Bad actors have been trying to make their traffic look more legitimate for as long as bot attacks have existed. First they spoofed User-Agent strings. Then they routed through residential proxy networks so their requests looked like they came from real homes. Then they used human click farms to solve CAPTCHAs. Each step was an attempt to appear more legitimate. Web Bot Auth does not break this pattern — it elevates it. The new version of "look legitimate" is: register as a verified agent.
Right now, in the current preview, AWS issues a shared key to all AgentCore Browser users. That means every agent running on AgentCore presents the same cryptographic credential. A bad actor who creates an AWS account and writes five lines of Python gets exactly the same "verified bot" badge as a Fortune 500 enterprise pipeline. That is not a trust framework. It is, in practical terms, a slightly more credible User-Agent header.
AWS knows this, to their credit. The documentation is explicit that customer-specific keys are coming at general availability. That will help. But the question that matters most is what the key issuance process looks like when it does. If getting a verified agent credential requires nothing more than an email address and a credit card, the abuse vector is simply one step upstream. The history of the web has a relevant precedent here.
When Let's Encrypt launched in 2015 and made TLS certificates free and automated, everyone celebrated. HTTPS would become universal. It did — and so did HTTPS phishing sites. Today, roughly half of all phishing pages are served over HTTPS. The padlock no longer means safe. It means the server controls that domain, which is a much weaker statement. Web Bot Auth risks the same outcome if the identity layer underneath the signatures stays low-friction.
Phishing over HTTPS
~50%
of phishing pages now serve over TLS — the padlock stopped meaning safe
What a Robust Bot Identity System Actually Requires
So what would actually work? There are several different approaches being explored, and we think it is worth being honest that none of them are fully solved yet. Here is how we see the landscape.
Option one: cryptographic anonymous credentials
The most privacy-preserving approach combines real identity verification with anonymous usage. You verify your identity once with a trusted issuer. In return, you receive a zero-knowledge credential that proves you are a verified entity — without embedding identifying information in every request. Anyone verifying the credential learns "this agent comes from a verified organisation" but not which one. Mass creation of fake credentials requires mass creation of verified identities, each legally accountable. The economics of large-scale abuse collapse.
This is the direction suggested by W3C Verifiable Credentials and schemes like BBS+ signatures. The technical pieces exist. The governance question — who runs the issuer, and under whose law — is the hard part that has not been answered yet.
Option two: high-friction onboarding that cannot be automated
A simpler approach: make the process of obtaining a verified agent credential difficult enough that running it at scale is not economically viable. Business registration documents, domain ownership verification, stated use-case review, and a human in the loop. Not theoretically unbreakable, but consider the track record. Extended Validation SSL certificates, which require proof of legal entity existence, have never seen phishing abuse at anywhere near the rate of standard certificates. The friction is the defence. Google's verified crawler program works on similar logic — you do not just declare yourself to be Googlebot, you prove it.
Option three: a neutral third party — the GLEIF vLEI ecosystem
This is the approach we are watching most closely, and the one we think has the most long-term credibility. The GLEIF — Global Legal Entity Identifier Foundation — has been building exactly the kind of independent identity infrastructure that Web Bot Auth currently lacks, in the form of the verifiable Legal Entity Identifier, or vLEI.
The LEI is already a global standard. Over two million legal entities hold one. Financial regulators — the SEC, the European Banking Authority, and others — already mandate it for market participants. The vLEI adds a cryptographic layer on top, using the KERI protocol and Authentic Chained Data Containers. In practical terms, it allows a company to prove that a specific AI agent is acting on behalf of a specific verified legal entity — without requiring the verifier to call home to a central authority every time.
Legal Entities with an LEI
2M+
LEIs issued globally and mandated by financial regulators
What makes this different from other approaches is who runs it. GLEIF is an international non-profit operating under Swiss law, with a mandate to maintain the LEI system for global financial stability. It is not a private cloud vendor. It is not the government of a single country. The trust anchor is structurally independent, which directly answers the question that every other approach leaves open: if a private company controls the issuer, what happens when their incentives diverge from yours?
We see the vLEI ecosystem as one of the most credible potential foundations for agent identity — particularly for European operators, where the eIDAS 2.0 digital identity framework is already moving in a compatible direction. The pieces are not yet connected: Web Bot Auth does not currently integrate with GLEIF's credential infrastructure, and vLEI issuance is still primarily oriented toward financial services. But the architecture fits precisely, and we are watching for when those two worlds start to converge.
Why vLEI stands out:
- GLEIF is internationally neutral — not a private vendor or a single government.
- Identity is legally anchored to a registered company, not an email address.
- LEI infrastructure already exists and is mandated in financial services globally.
- Creating fake agents at scale would require creating fake legal entities at scale.
- It is compatible with the EU's eIDAS 2.0 digital identity framework.
This is one of the more honest long-term answers to the governance question — and European operators in particular should keep an eye on how it develops.
Bot Protection Without CAPTCHA: The Principle We Build Everything Around
Here is something we feel strongly about at TrustSig, and it connects directly to this whole discussion. The reason CAPTCHAs became the default bot defence is that they are easy to implement. But they solve the problem for the site owner by creating friction for the user. You stop the bot by also stopping the person — or at least making them prove they are not a bot before they can continue.
We think that is the wrong trade-off. Your forms exist to convert, to serve, to let people complete tasks. Every unnecessary click, every puzzle, every "verify you're human" interruption is a moment where a real customer might just leave. And meanwhile, as we have described above, sophisticated bots are increasingly able to solve those same challenges anyway. You are paying a user-experience cost that buys you less protection every year.
Bot protection without CAPTCHA means the protection happens in the background. It means analysing the full behaviour of a session — the timing between keystrokes, the movement patterns, the device fingerprint, the request cadence — and making a risk decision invisibly, before your user ever sees a form field. If something looks wrong, you can ask for additional verification. But the default experience for a legitimate user should be seamless. They should never even know the protection is there. (This is exactly the bind Disability Sport Wales faced with an inaccessible CAPTCHA — and why removing the puzzle entirely was the fix.)
This is not a new idea. But it becomes more important, not less, as agent-identity frameworks like Web Bot Auth mature. Because the risk profile is shifting. In a world where some automated traffic carries a verified credential, the question is no longer just "is this a bot?" It is "is this verified agent behaving consistently with its stated purpose?" Behavioural analysis does not disappear — it moves up a layer. And it still needs to run without interrupting your legitimate users.
What Your Threat Model Needs to Prepare For Right Now
The transition from detection-based to identity-based bot defence will play out over several years. In the meantime — and this is important — the gap between "the technology exists" and "it is universally deployed" is exactly where attackers operate. A few things worth building into your security posture today.
First, verified-bot channels will become a new abuse vector. Once WAFs start allowing traffic based on cryptographic credentials, registering a credential specifically to bypass bot detection becomes a viable attack path. You cannot assume that "verified" means "trustworthy". Behavioural monitoring on your verified-bot traffic is not optional — it is the next line of defence.
Second, form protection and web skimming are separate problems. Web Bot Auth addresses one: whether automated agents can access your site. It does not address Magecart-style JavaScript injection, where an attacker compromises a third-party script to steal form data at the point of entry. Your Content Security Policy, subresource integrity checks, and third-party script monitoring remain essential and unchanged by any of this. (Our e-commerce form attack breakdown covers the skimming side in depth.)
Third, the architecture of your forms matters. Rate limiting on sensitive endpoints — login, registration, checkout, OTP verification, gift-card redemption — should be granular and layered. Even a legitimately verified agent can be directed to perform abusive actions. The per-agent policy tier in Web Bot Auth exists precisely for this reason, and you should plan to use it.
Finally, watch the IETF draft progress. When customer-specific keys become standard and the issuance-process requirements are published, your WAF configuration decisions will need to be revisited. The protocol is still evolving, and the decisions made in the next twelve months about key-issuance requirements will determine whether this becomes a genuine trust framework or a more elaborate version of the problem it was designed to replace.
Your Forms Should Be Open. Your Security Should Not Be Optional.
We started with a CAPTCHA. We have ended up talking about cryptographic identity frameworks, zero-knowledge proofs, and international non-profit governance structures. That is the honest picture of where this industry is heading.
But the practical reality for most businesses right now is simpler: your login pages, your checkout flows, your contact forms, and your registration pages are being probed by automated bots every day. The question is not whether to protect them. It is how to do it without making your legitimate customers feel like suspects.
Protect your forms. Not your click rate. At TrustSig, we deliver bot protection without CAPTCHA friction. Our approach analyses session behaviour in the background — invisible to your users, effective against the bots. We track every development in agent identity, Web Bot Auth, and the vLEI ecosystem, and we update our defences before the next wave arrives.
We work with businesses across Europe to build security postures that hold up — not just today, but when the threat landscape looks different again next year.
References and Further Reading
- AWS Blogs — "Reduce CAPTCHAs for AI agents browsing the web with Web Bot Auth (Preview)", October 2025 | aws.amazon.com
- IETF Draft — HTTP Message Signatures for Automated Traffic Architecture | datatracker.ietf.org
- Cloudflare — Agent Registry | blog.cloudflare.com
- GLEIF — verifiable LEI (vLEI) Overview | gleif.org
- HUMAN Security — 2026 State of AI Traffic & Cyberthreat Benchmark Report | humansecurity.com
- Imperva — 2025 Bad Bot Report | imperva.com
- W3C — Verifiable Credentials Data Model 2.0 | w3.org