Login is the one page type where a wrong answer has the worst consequences: a missed login page is a credential surface an agent can reach unsupervised. This page documents how login URLs are found and verified in the database, and the specific edge cases — SSO redirects, subdomain-hosted identity providers, locale-prefixed paths — that make path-guessing unreliable. Full context on the 28-page-type schema this key belongs to is on the page-types database overview.
The 2026 account-takeover campaign entered four third-party services by requesting login pages. Our analysis shows every one of those requests matches a login-key deny before the credential is ever submitted. Read the full breakdown: how the account takeovers could have been stopped.
Most page types have a moderate cost when misclassified: an agent that misses a documentation page just does slightly worse research. A missed or wrongly classified login page has a categorically different cost, because it is the surface an agent uses to authenticate, and authenticating is precisely the action a well-designed agent policy exists to gate.
This is why login gets treated as its own reference topic rather than one row in a general page-type list. The database's approach for login specifically combines live link-structure verification with a second, independent layer — a pattern-matching egress rule — so that a login surface missed by one layer still has a chance of being caught by the other.
It is worth being precise about what "wrong" means for a login classification, because the two failure directions are not symmetric. A false negative, missing a real login page and treating it as an ordinary content page, leaves a credential surface reachable. A false positive, flagging an ordinary page as login when it is not, merely denies an agent a page it did not need to authenticate on anyway, a cost measured in a slightly less complete research pass rather than an exposed credential surface. Given this asymmetry, the detection approach documented below is deliberately conservative on the side of catching login-shaped surfaces, even at the cost of occasionally over-flagging an account-adjacent page that turns out not to require credentials.
The same classification pipeline that builds the rest of the page-type database applies to login, with extra scrutiny given the stakes.
The pipeline follows the actual links a domain publishes — navigation menus, footers, header account controls — rather than requesting a fixed set of candidate paths and checking which ones respond.
Candidate URLs are evaluated for the structural and content signals of a login page: a credential form, an account-entry call to action, a return-to parameter, or a link explicitly labeled sign in, log in, or member access in the site's own navigation.
A candidate is confirmed as the domain's login page type only when the evidence is specific to that domain's actual structure, not because it matches a common convention other sites happen to use.
If a login surface is confirmed, the exact URL goes into the domain's page_types field under the login key. If none is confirmed, the field explicitly records that no login URL was verified for that domain, rather than silently omitting the key.
This number is worth stating plainly rather than rounding up, because it explains why login needs a second layer of coverage beyond the database key alone.
Not every domain in the repository has a discoverable, publicly linked login page. Some domains are purely informational and have no account system at all. Others gate their login behind a corporate SSO portal that is not linked from the public site in a way the classification pipeline can verify with confidence. Others still route authentication through a third-party identity provider on an entirely different domain, which is a real login surface but not one that belongs on the vendor's own domain row. In each of these cases, an honest "not verified" is the correct answer — and it is also an answer a policy built only on the database key alone cannot fully rely on for complete login coverage.
The remaining share of domains, those without a verified login key, is not evenly distributed across categories of site. A domain that is purely a content property — a news outlet, a static reference resource, a single-purpose marketing microsite — genuinely may have no login surface, and the absent key is simply an accurate description of that domain's structure, not a coverage gap. The domains where an absent login key actually matters for policy purposes are the ones that do have an authenticated area but route to it in a way the verification pipeline could not confirm with confidence, which is exactly the population the identity-group egress rule exists to backstop.
This is the specific design reason login receives double coverage where most page types rely on the database key alone.
The verified login URL for the roughly 29% of classified domains where one was found, including login pages on auth subdomains or unusual query-string routes that a fixed pattern would miss.
A pattern rule matching the shape of a login (wp-login.php, /accounts/login, /auth/login, session/new and similar forms) on any domain, including the long tail the database has not verified yet.
A login page that evades one layer is often caught by the other, and default-deny catches whatever slips both. The identity group in the egress rules library also covers signup and password_reset, the two other page types in the identity group, on the same logic. Full rule definitions are published at the egress rules library, and the general four-layer enforcement model this fits into is covered on agent guardrails.
Four patterns account for most of the cases where a simple "assume /login exists" heuristic produces a wrong or missing answer.
Many SaaS platforms do not host their own login form at all; they redirect to a third-party identity provider such as an SSO gateway, often on a completely different domain or subdomain. A pattern that only checks the vendor's own domain for a login path never sees the actual authentication surface.
Login is frequently split onto its own subdomain, separate from the marketing site and even from the main application. A path-only guess anchored to the primary domain misses this entirely; verification has to follow the domain's actual linked structure to the subdomain.
International sites frequently prefix every path with a locale or region segment. A hard-coded guess for /login fails on every localized version of the site, while the same page under a locale prefix is a perfectly real, verifiable login URL.
Some applications render the login form client-side at a route that never triggers a distinct server request, or bury it behind a client-side router fragment. Verifying these requires evaluating what actually renders, not just what URL pattern is requested.
Each of these four patterns defeats a fixed-path guess in a different way, which is precisely why a single static heuristic cannot cover login reliably across a diverse set of domains: an SSO redirect defeats a same-domain assumption, an auth subdomain defeats a same-hostname assumption, a locale prefix defeats a fixed-path assumption, and a single-page application defeats a server-request assumption entirely.
| Question | Path-guessing (e.g. always assume /login) | Verified database key |
|---|---|---|
| Does the URL actually exist on this domain? | Unknown until requested; often 404s or redirects to something unrelated | Confirmed present in the domain's live link structure at classification time |
| Does it work across subdomains? | No, unless every relevant subdomain is separately guessed | Yes; verification follows the domain's actual linked structure wherever it leads |
| Does it survive locale prefixes? | No; a fixed path breaks under any locale-prefixed routing scheme | Yes; the localized URL itself is what gets verified and recorded |
| What happens when no login page exists? | A guess still gets issued as a request, wasting a step and risking a false positive match on an unrelated page | The field records explicit absence; no wasted request, no ambiguity |
| Coverage across 40M+ domains | Would require maintaining pattern variants for every convention in use, indefinitely | Delivered pre-verified as part of the database |
Detecting login accurately is only half the value; the other half is what a policy does once it has the answer.
The recommended default, consistent with how the identity group is treated across this site's guardrail guidance, is to deny or flag-for-human-approval any request that resolves to the login page type, along with signup and password_reset in the same group. This holds regardless of whether the agent's stated intent looks benign: a support agent legitimately trying to check its own account status and a hijacked agent trying to take over a third-party account both generate a request to the same login URL, and a policy that tries to distinguish intent at that point is reasoning about something the URL itself cannot tell it.
An important distinction sits underneath this default: an agent operating on a session already provided by its own operator, such as a support agent using credentials its company issued it, is not the same thing as an agent autonomously navigating to a login page and attempting to authenticate on its own. The former is a legitimate operational pattern outside the scope of this policy; the latter, autonomous authentication, is the exact move a deny-by-default login policy is built to stop, and it is what every documented account-takeover step in the 2026 campaign looked like.
Teams building out this policy sometimes ask whether a middle ground exists between hard deny and silent allow, and the honest answer is that there is one, but it changes who is accountable for the decision rather than eliminating the risk. Flag-for-human-approval routes the login request to a person before it proceeds, preserving the option for a genuinely legitimate authentication need while keeping a human, rather than the agent's own judgment, as the actor who decides to authenticate. Hard deny removes the option entirely and is the more conservative default for agents that have no legitimate reason to authenticate as part of their job. Which of the two an organization chooses is a risk-tolerance decision, not a data-quality one; the login classification itself is the same regardless of which policy consumes it.
A concrete illustration of the detection-to-policy pipeline on a single, well-known domain, using publicly known facts about how Stripe structures its site rather than any private data.
Stripe separates its marketing and documentation content, reachable at paths like stripe.com/docs and stripe.com/pricing, from its authenticated dashboard, reachable through a distinct login flow. A verification pass following Stripe's actual link structure identifies the login entry point precisely, records it under the login key for stripe.com, and leaves the documentation and pricing paths recorded under their own separate keys. A policy engine checking any of these four URLs against the database gets four different, page-type-specific answers from one classified domain: pricing and documentation allowed, login denied. This is the same worked example used in more depth on proxy filtering vs. the agent allowlist, applied here specifically to how the login determination itself gets made.
The value of this worked example is that it generalizes. Any domain with a public content surface and a separate authenticated area — which describes most SaaS vendors, most e-commerce sites, and a large share of the modern web — produces the same shape of result: a small number of denied identity and transaction surfaces sitting alongside a much larger set of allowed research and reference pages, all derived from the same underlying verification pass rather than from separate ad hoc rules per domain.
See where the login key sits inside the complete field-by-field reference on the page-type schema reference.
See how login-key coverage varies with license tier and why default-deny fills the gap regardless of tier on coverage tiers.
See how a login-page deny decision plugs into an existing proxy's policy hook on proxy filtering vs. the agent allowlist.
For blocking humans' own access to risky AI tool login surfaces, rather than agent navigation, see the sibling product AI Tools Blocklist.
Many domains have no public login surface at all, gate authentication behind an unlinked corporate SSO portal, or route login through a third-party identity provider on a different domain. The database records absence honestly rather than guessing a path that may not exist.
The identity-provider domain itself, if it is in the 40M+ repository, carries its own login classification. The egress rules library's identity-group pattern rule also catches login-shaped paths on any domain, including one an agent reaches only via an SSO redirect chain.
Agents operating on a session their own operator already provided are a different path entirely and are not asking the policy to open a login page. The deny-by-default rule targets autonomous authentication attempts specifically, treating them as deny or as flag-for-human-approval.
The database key gives the verified, exact login URL including odd cases like auth subdomains and query-string routes. The pattern rule catches the shape of a login on domains the database has not verified yet. A login surface that slips one layer is often caught by the other.
Yes. All three sit in the identity group and follow the same live-link-structure verification approach, with the same egress-rule pattern coverage as a second layer.
That the policy engine sits on the agent's egress path and sees every request, that default-deny is active for unclassified destinations, and that URLs are visible at enforcement time. Under those assumptions, a request to a classified or pattern-matched login page is denied before authentication occurs.
Download the free sample or review the full schema reference.
The honest fine print — the same two assumptions we publish, plus two operational ones
