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.
In October 2025, Amazon Web Services shipped Web Bot Auth inside Amazon Bedrock AgentCore Browser: a draft IETF protocol that lets an AI agent prove its identity with a signature instead of disguising itself as a human. The credential it issues, in this preview, is worth close to nothing. An AWS account, a credit card and five lines of Python buy you the same "verified bot" badge a Fortune 500 data pipeline carries.
A CAPTCHA asks "does this traffic look human?" Web Bot Auth asks "can this agent cryptographically prove who it is?" That is a different problem statement.
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.
What AWS Built, and the Admission Hidden Inside It
The mechanism is plain enough. An agent created inside Amazon Bedrock AgentCore Browser with signing enabled gets cryptographic credentials from AWS, and every HTTP request it makes carries a signature derived from them. At the WAF layer that signature is checked against a directory of trusted agents. AWS's own WAF, Cloudflare, Akamai, and HUMAN Security have all signed on. 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 could allow a specific partner's agents to query their portal at a defined rate while blocking everything else, including other signed agents.
Building it at all is an admission. Behavioural bot detection has dominated the industry for a decade and it is running out of road. AI-generated traffic grew 187% between January and December 2025 alone, and modern bots mimic human mouse movements, dwell times, and form interactions convincingly enough that detection is becoming more lottery than science. AWS cannot win that race forever, so it changed the terms instead.
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.
A Good Direction With a Real Abuse Problem Baked In
Moving to cryptographic identity for AI agents is the correct long-term architecture. An implementation that resists abuse is separate work, and that is the part still missing.
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. Web Bot Auth doesn't break that pattern; it elevates it. The new version of "look legitimate" is: register as a verified agent.
A single shared preview key, issued to every AgentCore Browser user, isn't a trust framework. In practical terms it's a slightly more credible User-Agent header.
The documentation is explicit, to their credit, that customer-specific keys are coming at general availability, and that will help. The open part is what the issuance process will ask for. If a verified agent credential costs an email address and a credit card, the abuse vector moves one step upstream and carries on.
Let's Encrypt is the precedent. It made TLS certificates free and automated in 2015, HTTPS became universal, and phishing came along for the ride: roughly half of all phishing pages are served over HTTPS today. The padlock means the server controls that domain, which is a much weaker statement than safe. 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, so the padlock stopped meaning safe
What a Robust Bot Identity System Actually Requires
Three approaches are being explored seriously. They differ in where the trust sits: in the cryptography, in the onboarding, or in the issuer. None of the three is finished.
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, and 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" and no more than that. Mass creation of fake credentials then requires mass creation of verified identities, each legally accountable, and the economics of large-scale abuse collapse.
W3C Verifiable Credentials and schemes like BBS+ signatures point this way, and the technical pieces exist. Who runs the issuer, and under whose law, is the governance question nobody has answered.
Option two: high-friction onboarding that cannot be automated
A simpler approach: make a verified agent credential difficult enough to obtain that running it at scale stops being economically viable. Business registration documents, domain ownership verification, stated use-case review, a human in the loop. That isn't theoretically unbreakable, but the track record is worth a look. 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, where claiming to be Googlebot counts for nothing until you prove it.
Option three: a neutral third party, the GLEIF vLEI ecosystem
This is the approach we are watching most closely. The GLEIF (Global Legal Entity Identifier Foundation) has been building 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, held by over two million legal entities and mandated for market participants by the SEC, the European Banking Authority and others. The vLEI adds a cryptographic layer on top, using the KERI protocol and Authentic Chained Data Containers. A company can prove that a specific AI agent is acting on behalf of a specific verified legal entity, and the verifier doesn't have to call home to a central authority every time.
Legal Entities with an LEI
2M+
LEIs issued globally and mandated by financial regulators
The difference 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, which leaves it neither a private cloud vendor nor the government of a single country. A structurally independent trust anchor answers the question 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 more credible 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 aren't connected yet. Web Bot Auth does not currently integrate with GLEIF's credential infrastructure, and vLEI issuance is still primarily oriented toward financial services. The architecture fits, though, and we are watching for the point where those two worlds 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.
Bot Protection Without CAPTCHA: The Principle We Build Everything Around
CAPTCHAs became the default bot defence because they are easy to implement, and they solve the site owner's problem by creating friction for the user. You stop the bot by also stopping the person, or at least by making them prove they are not one 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 and every "verify you're human" interruption is a moment where a real customer might just leave, and sophisticated bots 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: 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. Ask for additional verification when something looks wrong. A legitimate user should never 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.)
None of that is a new idea, and it gets harder to skip as agent-identity frameworks like Web Bot Auth mature, because the risk profile shifts. Once some automated traffic carries a verified credential, "is this a bot?" stops being the useful question and "is this verified agent behaving consistently with its stated purpose?" takes its place. Behavioural analysis moves up a layer, and it still has 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, and the gap between "the technology exists" and "it is universally deployed" is exactly where attackers operate. Build four things 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.
Second, form protection and web skimming are separate problems. Web Bot Auth addresses whether automated agents can access your site. It does nothing about 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, because 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, so 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 key-issuance decisions of the next twelve months 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.
Cryptographic identity frameworks, zero-knowledge proofs and non-profit governance structures are where this industry is heading. The practical reality for most businesses right now is smaller than that. Your login pages, your checkout flows, your contact forms and your registration pages are being probed by automated bots every day. Nobody needs convincing that they should be protected; the open question 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 and 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 still hold 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