"Block login pages" sounds like a simple rule until you try to enumerate what counts as one. Credential surfaces live on subdomains, on third-party identity providers, behind locale-specific paths, and inside single-page apps with no distinct URL at all. This page is a full taxonomy of where they hide, because a policy that only catches "/login" catches almost none of them.
Most informal discussions of this problem say "login page" and mean something narrower than the actual attack surface. Precision here changes what a policy needs to cover.
Any page or endpoint where an agent's action could create, authenticate, recover, or modify an account's access credentials — not only the visible sign-in form, but the surrounding flows that manage identity.
Our taxonomy groups this into three page types: login (authenticate an existing account), signup (create a new one), and password_reset (recover or change access). All three carry the same category of risk: an agent taking action there is acting on identity, not just reading content.
The reason this page exists as its own deep dive, separate from the broader browsing-risk taxonomy, is that credential surfaces are the single category where naive detection fails most often and most invisibly. A checkout page is usually easy to recognize by a shopping cart icon or a payment form. A credential surface can be a single link labeled "Sign in with your organization" that silently redirects to an entirely different domain, with nothing about the label itself signaling that an identity flow is about to begin.
A completed transaction can sometimes be refunded. A completed account takeover, password change, or new-account creation under your identity is much harder to fully unwind, and the exposure often continues after the specific incident is noticed.
Unlike a checkout page, a credential form rarely announces itself with unambiguous visual or textual cues an automated system can rely on, especially once delegated SSO and SPA rendering are in the mix.
Of the documented 2026 agent incidents, credential surfaces (login, signup, and the account layer beneath them) were the entry or escalation point in more cases than any other single page-type category.
Not every credential surface looks like a simple form on the domain you started on. Here is the full range an agent can actually reach.
The fifth type is easy to overlook because it only becomes reachable after an agent has already authenticated somewhere — either with credentials it was given for a legitimate task, or because a policy allowed a specific login. Once inside, an account or settings page can itself become a credential surface: an API-key generation page, a linked-accounts panel, or a page that lets a signed-in user add a second authentication method. Treating "already logged in" as equivalent to "no further credential risk" is a common design mistake worth naming explicitly.
A rule that denies any URL containing the word "login" catches the easy cases and misses most of the real ones. Here is what it misses, in the order it typically gets discovered.
Each of the five techniques below was chosen because it is common on ordinary, mainstream websites, not because it represents an unusual evasion technique. None of these require a malicious site operator; they are simply how large, mature, multi-market web platforms are built in practice, which is exactly why a naive keyword approach fails so often on completely legitimate domains.
To make the taxonomy concrete, here is how the credential surface actually manifests across different kinds of sites an agent might visit for ordinary research or procurement work.
Notice that no two rows in this table hide their credential surface the same way. That variation is the actual reason a single detection heuristic cannot cover all five domain types with one rule: a heuristic tuned to catch a bank's dedicated subdomain will not catch a wiki's "become an editor" registration flow, and a heuristic tuned to catch that will not catch a marketplace's dual buyer/seller identity split. Coverage has to be built domain by domain and verified against the live site, which is the entire reason a maintained database exists rather than a static rulebook.
A useful test for any policy you already have in place: pick one row from this table, find the actual credential URL for a real domain of that type, and check whether your current rule would have caught it without you first telling the rule exactly where to look. If the answer depends on you already knowing the answer, the rule is not really generalizing — it is memorizing a handful of examples, which is precisely the gap a verified, continuously maintained database is built to close.
| Domain type | Where the credential surface actually sits | Why it is easy to miss |
|---|---|---|
| Enterprise SaaS vendor | Login delegated to a third-party SSO/identity provider domain, reached only after clicking "sign in" on the vendor's own site | The credential form is on a domain the agent never intended to visit and a per-vendor allowlist never named |
| Bank or financial institution | A dedicated "online banking" subdomain, often with its own distinct branding and a separate password-reset flow from the marketing site | The subdomain name frequently does not contain "login" or "bank," using an internal platform name instead |
| Wiki or collaborative platform | A conventional login path, but also a "request account" or "become an editor" registration flow buried in a help or community page | The registration flow is framed as "getting involved," not as an identity-creation action, so it reads as informational |
| Developer tool / API platform | Login for the dashboard, plus a separate API-key or token-management page reachable once inside the account settings | Once "inside" via an allowed login, the token page looks like ordinary settings, not a fresh credential surface |
| Global consumer marketplace | A localized login path per country/locale, plus a separate seller-account authentication surface entirely apart from the buyer login | Locale variants and dual buyer/seller identity systems both multiply the number of distinct credential paths on one hostname |
This is why our database resolves the login, signup, and password_reset page types by verifying the actual URL on each live domain rather than inferring it from a path-naming convention. A verified URL for a French locale's /connexion page, a delegated SSO redirect target, or a seller-specific login is exactly as reliably classified as a conventional /login path, because the classification never depended on the path spelling out its own purpose.
Consider a vendor due-diligence agent tasked with evaluating a SaaS vendor's suitability, which is an ordinary, low-drama task with no adversarial intent anywhere in it.
The agent starts on the vendor's marketing site, reads pricing and documentation pages without issue, and then, following its own reasonable logic, decides to check whether a free trial is available — a completely natural next step for a due-diligence task. The "start free trial" link resolves to a signup page: surface type two, denied by default. The agent, redirected instead of blocked outright in its plan, might next try "contact sales," which on this vendor happens to route through a support portal that requires signing in via the vendor's SSO provider — surface type four, on a domain entirely separate from the one the agent started on, still denied.
Neither of these attempts required the agent to be doing anything unusual. Both were denied because the page type, not the agent's stated intent, determined the outcome — which is the same principle described on our deterministic guardrails page, applied specifically to the credential category.
Use this against your own agent's actual configuration and the domains it visits, not as an abstract review.
login, signup, and password_reset as three separate page types, not one combined "auth" bucket that might miss a signup flow phrased as "get started" rather than "sign up."The 2026 account-takeover campaign broke into four services across four different credential surfaces, with a Modal Labs-hosted app's default public API key and a command-injection flaw serving as the execution point. Our analysis shows the login page type, the signup and password_reset keys, and the identity group of our egress rules deny every one of those hops before the first request.
Every 2026 agent escape, mapped to the rule that stops it Read the account-takeovers caseThe honest fine print — the same two assumptions we publish, plus two operational ones
Where credential exposure sits among the five risk categories.
The same "one hostname, many surfaces" problem, applied broadly.
Strict default-deny policy where credential surfaces carry the highest stakes.
The 100M+ domain filtering dataset from the same team.
Download the sample and see verified login, signup, and password-reset URLs across 100 real domains.
