Welcome real users and trusted agents. Stop the rest.
AI agents now book, shop, and fill in forms on behalf of real people. Blocking every non-human visitor loses customers; waving all of them through invites abuse. MTCaptcha reads session age, auth strength, and behavioral risk on every request, so the difference is a decision, not a guess.
This is the real widget, live, not an illustration. Try it above the way a visitor to app.yoursite.com would.
What is agent trust, and why is it suddenly the question?
For fifteen years, "is this a bot" had one right answer: block it. That stopped working the moment browser agents, RPA tools, and AI copilots started completing real tasks for real customers, logging in, filling out forms, finishing checkouts, using the same requests a scraper would send. A CAPTCHA built to say only yes or no now has to be right about three different things: a human at a keyboard, an agent acting for that human with their consent, and a script acting for no one but its operator.
MTCaptcha already had the pieces for this before the term "agent trust" existed: an adaptive risk engine that scores behavior instead of pattern-matching a fixed rule set, and, as of the SSO work shipped in the commit right before this page was drafted, session-age and auth-strength signals read directly from Google OIDC. This page is the first time either gets a name a visitor can search for.
Why treating every non-human visitor the same backfires
Shopping and travel agents act with consent
A customer who asks an AI assistant to book a flight or reorder a subscription expects it to complete the purchase, blocking that request blocks a sale, not an attacker.
Support and RPA tools are already inside the perimeter
Enterprises run scheduled scripts and support-desk automation against their own login forms every day. A blanket bot rule flags the company's own tooling as the threat.
Search and monitoring crawlers need to get through
SEO visibility and uptime monitoring both depend on well-behaved crawlers reaching the page, indiscriminate blocking trades security for invisibility.
Credential-stuffing scripts look identical at a glance
The traffic that actually needs to be stopped, scripted login attempts replaying breached passwords, arrives in the same shape as the legitimate automation above. Distinguishing them is the entire problem.
How MTCaptcha tells them apart
Every mechanism below is shipped, not planned, this page describes the product as it exists today.
Session-age & auth-strength signals
SSO sign-ins carry how recently the session was established and how strong the authentication behind it was, a fresh, strong session reads differently than a replayed or thinly-authenticated one.
Adaptive risk engine
Continuously scores behavioral and environmental signals in real time and adjusts verification difficulty accordingly, easy on a trusted agent, hard on a scripted one.
Invisible NoCAPTCHA by default
Most legitimate traffic, human or agent, passes without a visible challenge at all. Friction is reserved for sessions the risk engine actually flags.
Enterprise dashboards & Threat SPECT
Multi-user visibility into what the risk engine is seeing across an account, so a security team can confirm the split between agent, human, and abusive traffic rather than take it on faith.
Deployed in the wild
Enterprise technology (semiconductor & software)
On: New-account registration
Protects: Signup from scripted registration abuse, screened by the adaptive risk engine
Industrial engineering software (Germany)
On: Cloud login, alongside Microsoft & Google SSO
Protects: Sign-in sessions, the same surface this page is about
Real deployments, industry and mechanism only, no company names, by design.
See how your traffic actually breaks down
Tell us what you're running into, we'll show you the agent-vs-bot split on your own traffic.
Thanks, message sent!
We’ve received your message and will get back to you shortly.
For more themes and CSS style customization,
see MTCaptcha's Code Builder