/login Was Always Going to Fail. Verified URLs Don't.Point an agent at a domain and tell it to find the login page. It will try /login, then /signin, then give up or hallucinate a URL that returns a 404. That approach fails constantly in production — not because the idea is wrong, but because the modern web stopped putting pages at predictable paths years ago. Verified URLs, discovered by crawling and confirmed against the live site, are the alternative that actually works at scale.
Several 2026 incidents involved agents reaching pages nobody meant for them to reach — the Hugging Face breach, the DseWiki hijack, the JFrog Artifactory covert channel, and a string of third-party account takeovers. A database of verified page-type URLs plus egress rules would have denied almost every one of those requests before it left the network. Every 2026 agent escape, mapped to the rule that stops it → See specifically how the DseWiki hijack ran through URL shapes no guessed-path list would have contained.
Every guessed-path scheme rests on an assumption: that a page type lives at one of a handful of conventional locations. That assumption held reasonably well on the server-rendered web of 2010. It does not hold on a web built from single-page apps, regional deployments, and outsourced identity, where the same page type can live at a dozen different shapes of URL depending on the site’s stack, its market, and its vendor choices.
The gap between the two approaches widens with scale. A guessing scheme built for a handful of familiar domains can be patched by hand every time it fails — someone notices the miss, adds a new path variant, and moves on. That workaround stops being available the moment an agent needs to operate across tens of thousands of domains it has never seen before, each with its own routing conventions, its own identity vendor, and its own rendering stack. At that scale there is no human in the loop to notice a silent miss and patch the list; the only options are a crawl-and-verify pipeline that discovers the real answer per domain, or an agent that quietly fails on an unknown but non-trivial fraction of its targets and never tells anyone.
Login is the page type every guessing scheme claims to handle, so it is the clearest place to see the gap. These are illustrative shapes — the pattern any team doing this work runs into, not records pulled from a specific customer’s data. A path-guessing agent has to hard-code every one of these shapes in advance and still misses the ones nobody thought to add.
| Site pattern | Guessed path an agent tries | Where the real login page actually sits |
|---|---|---|
| Regional SaaS deployment | /login | /de-de/login or /en-gb/account/sign-in |
| Identity split onto its own host | /signin | accounts.example.com/signin |
| Outsourced identity provider | /login | example.okta.com or example.auth0.com/login |
| Single-page app, client-side router | /login | /app#/login (only rendered after JS executes) |
| Consumer platform, brand-specific naming | /account/login | /accounts/ServiceLoginAuth or /signin/v2/identifier |
| Enterprise SSO gateway | /login | sso.example.com/login?service=main-app |
| Marketplace with separate buyer/seller portals | /login | /seller-center/login (buyer login lives elsewhere entirely) |
Multiply this by 28 page types and 40 million domains and the scale of the guessing problem becomes clear: there is no static list long enough, and every entry you add to make the guesser smarter is really an admission that the answer needs to come from crawling the actual site, not from a convention.
/login fails in practiceThese are not edge cases. They are the default condition of a meaningful share of the modern web, and any one of them is enough to make a guessed path wrong.
A site serving 40 markets does not put every login page at the same path. Country and language codes shift the URL — /fr/connexion, /jp/login, /en-au/account/sign-in — and a guesser has to know the exact locale scheme for every domain in advance, which defeats the purpose of guessing.
Plenty of sites move authentication onto its own host entirely — accounts.example.com, id.example.com, login.example.com — sometimes on a completely different second-level domain when identity is outsourced. A path guess never leaves the root domain, so it never finds these.
Single-page applications often return the same shell document with HTTP 200 for every path, then render the actual page in JavaScript after the route resolves. A guesser reading only the HTTP status code cannot tell a real login form from a blank shell — both say "200 OK."
Auth0, Okta, WorkOS, Ping and similar providers host the actual login form on their own domain, embedded or redirected from the site an agent is researching. The page type an agent needs to allow or deny may not even be part of the target domain at all.
The failure modes above are not theoretical for anyone actually running browsing agents in production. They show up as support tickets and silent task failures within the first week.
Sent to compare vendor pricing across dozens of SaaS domains, these agents lose hours to pricing pages hidden behind JavaScript tabs or region-specific paths, and occasionally wander toward a checkout page while trying alternate guesses — exactly the surface their policy should have denied outright.
Tasked with checking a vendor's current incident status, these agents fail quietly when the real status page lives on a separate status-page vendor's domain the guesser never tries, reporting "all clear" simply because it never found the page at all.
Harvesting open roles across thousands of company domains, these agents miss careers pages hosted on external applicant-tracking platforms unless the crawl already knows to follow the link off-domain to where the real listings live.
Instead of guessing a path and hoping, our approach starts from the site’s own structure and confirms every candidate before it becomes a record. The output is a URL an agent can trust, or an honest absence when no such page exists yet.
Crawling follows the site’s own navigation, sitemaps, and rendered links — including JavaScript-rendered ones — rather than assuming a path convention. This is how identity subdomains and locale-prefixed routes get discovered in the first place.
A discovered URL is classified into one of the 28 page types based on its actual rendered content and structure, not its path string — so a URL that happens to contain the word "login" but shows a marketing page is not misfiled.
Before a URL is recorded, it is confirmed to actually serve that page type on the live domain. A URL is in the database only if that domain genuinely serves it — nothing is filled in by convention or extrapolated from similar domains.
Sites redesign, migrate identity providers, and change routing schemes. Each update cycle re-checks page-type URLs against the current live site, so a URL that verified last quarter but has since moved does not sit in the database as a stale, silently wrong record.
The practical effect for a policy engine is that a lookup against the page-types database returns either a URL that is confirmed to exist and to be that page type, or nothing at all. Nothing at all is a safe, honest answer a default-deny policy can act on. A wrong guess dressed up as an answer is not.
One honest note on coverage: the eight action-type page keys — signup, password_reset, cart, checkout, upload, post_create, comment and subscribe — ship with the current reclassification cycle and are added per domain as records are re-verified. A domain without one of those keys today does not mean the page does not exist; it means verification has not reached it yet in this cycle. That is a materially different, and more honest, statement than a guessing scheme could ever make about its own gaps, because a guesser has no concept of "not yet verified" — it only has "tried" and "not tried."
Login gets the attention because it is the credential surface everyone worries about, but the guessing problem is identical for every other page type an agent needs to find. A procurement agent hunting for a pricing page, a support agent looking for a status page, or a recruiting agent trying to reach a careers page all hit the same wall: the obvious path is often wrong, and the real one is discoverable only by looking at what the site actually publishes.
| Page type | Guessed path an agent tries | Common real-world shape instead |
|---|---|---|
| Pricing | /pricing | /plans, /packages, or a locale-prefixed /en/pricing |
| Status | /status | status.example.com, hosted on a separate status-page vendor entirely |
| Careers | /careers | /jobs, or an external careers portal on a recruiting platform's domain |
| Documentation | /docs | docs.example.com, or /developers/reference under a versioned path |
| Checkout | /checkout | /cart/review, or a payment processor's own hosted checkout domain |
Status pages are a particularly clean example: a large share of sites run their status page on a dedicated third-party status-page vendor's domain rather than their own, so no path guess on the primary domain will ever find it — the only reliable answer is a crawl that follows the site's own links to wherever it actually points.
In a research context, a wrong guess just wastes a request and a retry. In a policy-enforcement context, the failure mode is worse, because a guessing scheme cannot distinguish "I found nothing" from "I found the wrong thing with high confidence."
Consider a procurement agent operating under a policy that allows pricing and documentation pages but denies checkout and account pages. If the agent's path-guessing logic mistakes a marketing landing page at /plans for the real pricing page and never discovers the actual /pricing/enterprise page behind a JavaScript-rendered tab, the agent either stalls on a task it should be able to complete, or — more dangerously — falls back to exploratory clicking that was never covered by policy in the first place. Either failure traces back to the same root cause: the policy engine was asked to make a decision about a URL nobody had actually verified.
This is why a default-deny posture and verified URLs work together rather than as alternatives. Default-deny assumes the worst about anything unclassified; verified URLs shrink the unclassified set down to the genuine long tail, instead of leaving it artificially large because a guessing scheme could not find pages that were there all along.
A zero-trust policy that checks every URL before an agent visits it is only as reliable as the map it checks against. Feed it guessed paths and it will confidently allow or deny the wrong page. Feed it verified URLs and the same policy logic becomes trustworthy, because the underlying fact — "this URL is the checkout page for this domain" — was actually confirmed rather than assumed.
Knowing the real URL for a page type is the first layer. What an agent is allowed to do once it has that URL is a policy decision built on top of it, and it belongs alongside two other ideas: never trusting a destination just because a prior visit succeeded, and treating account creation, checkout, and content-write pages as high-scrutiny surfaces by default.
28 page types, 40 million+ domains, every URL confirmed against the live site. See the schema, then check a real domain against the API.
