Login is where an autonomous agent stops being a reader and becomes a credential holder. Get this one page type wrong and every other guardrail in your policy is downstream of a mistake that already happened. This guide is a severity argument first and an implementation guide second: why login, signup, and password_reset deserve harder treatment than any other page type, why guessing /login misses a large share of real login surfaces, and what a verified-URL policy does instead.
A pricing page, a blog post, a status page — an agent that fetches the wrong one of these wastes a request. A login page is not like that. Reaching a login form and doing anything with it is the first move of an authentication flow, and authentication flows are exactly the mechanism behind the class of incident that keeps showing up in 2026 agent postmortems: an agent that was supposed to browse ends up holding, entering, or resetting a credential.
That is what makes login, alongside its two siblings signup and password_reset, the one group of page types where "deny by default, review the exceptions" is not a conservative posture — it is close to the only defensible one, and it is the single clearest example of why the four-layer enforcement model (page-type database, egress rules, host list, default-deny) treats identity as its own hard-coded category rather than something left to a general allow/deny toggle. A vendor-research agent has a plausible reason to read a pricing page it was never explicitly told about. It has essentially no plausible reason to autonomously create an account, request a password reset, or submit stored credentials to a form it discovered on its own. When a policy allows the second kind of action by accident, it is almost never because someone decided it should; it is because nobody thought to write the deny rule before the agent found the page.
An agent that submits a stored credential to a login form it located itself has exposed that credential to whatever the form actually does with it — including a form on a compromised or spoofed page.
Login, signup, and password_reset together are the three moves that get an attacker or an agent into an account it did not already have access to. Deny one and the other two are still open.
An authenticated session is a new set of permissions the policy engine never evaluated. Every page reachable only after login inherits whatever trust the login itself was given.
There's a practical reason this matters beyond the abstract severity argument: once an agent is authenticated somewhere, your page-type policy is evaluating a different site than the one it thought it was looking at. The public marketing pages a domain shows an anonymous visitor and the account-management surfaces it shows a logged-in user are frequently different applications entirely, sometimes on different subdomains, with a different and usually much larger set of writable, sensitive endpoints. A policy tuned for "agent reads a vendor's public site" has no coverage plan for "agent operates inside a vendor's authenticated account area," and the only point where you can reliably prevent that transition is before the login itself, not after.
The verified URL of a domain's actual authentication entry point — the form or redirect target where a returning user enters credentials — established by tracing the domain's live link structure, not by guessing a common path. signup (account creation) and password_reset (credential recovery) are the other two identity-group page types, and all three are shipping as part of the current reclassification cycle alongside the twenty page types that have been in the database from the start.
The distinction that matters for a login-specific policy is between a verified URL and a guessed path. A verified URL is a specific link our classification pipeline confirmed, by following the domain's own link structure, actually resolves to that domain's login form. A guessed path is a heuristic — try /login, then /signin, then /account/login — applied without ever confirming any of them is correct for the specific site in front of the agent. The two approaches produce very different failure modes, and the table below is about exactly that difference.
A path-guessing heuristic gets a meaningful share of well-known consumer sites right, because those sites converge on a handful of conventional paths. It quietly misses a much larger share of the long tail — and the long tail is most of the internet an autonomous agent will actually encounter.
| Where the login page actually lives | Why a guessed path misses it | What a verified URL gives you instead |
|---|---|---|
A dedicated authentication subdomain, e.g. accounts.example.com or login.microsoftonline.com | The heuristic checks paths on the domain the agent is already on; it never tries a different subdomain | The exact subdomain and path, recorded against the parent domain's record |
| A third-party identity provider — Okta, Auth0, Ping, an internal SSO gateway on its own domain entirely | The login "page" is not even on the vendor's domain, so no path guess on that domain could ever find it | Verification follows the actual redirect target, wherever it resolves |
A locale-prefixed path, e.g. /fr-fr/connexion, /de/anmelden, /ja/login | English-only path lists (/login, /signin) don't match localized strings or locale-prefixed routes | One verified URL per domain, in whatever locale the site's own link structure actually uses |
| A single-page application where the login form renders client-side with no distinct server path until JavaScript executes | A path guess assumes a server-rendered URL exists to guess in the first place | Verification is based on the resolved link the site itself surfaces, not an assumed server route |
| Multi-tenant SaaS with a per-tenant or per-customer login subdomain | Every tenant's login lives at a different, unpredictable subdomain — no single guess covers the product | Each tenant domain in the database carries its own verified record |
None of these are exotic. They are the ordinary shape of authentication on the modern web, and they are precisely the cases where a policy that "just checks for /login in the path" produces a false sense of coverage — the deny rule looks complete in a test against ten familiar sites and quietly does nothing on the eleventh.
The hardest version of this problem is not a login page that hides on the same domain. It's a login page that isn't on the domain at all.
A large share of business software delegates authentication entirely: the agent starts on vendor.example.com, follows a "sign in" link, and is redirected through an OAuth or SAML flow to login.microsoftonline.com, accounts.google.com, or a company's own Okta tenant before ever seeing a form on the original domain. A policy that only evaluates the domain the agent started on never sees this — by the time credentials are entered, the agent has left the domain the policy was scoped to.
Two things close this gap. First, the redirect re-check from the implementation walkthrough above: every hop in the chain is looked up independently, so the identity-provider domain is evaluated on its own record, not assumed to inherit the trust of the page that linked to it. Second, the identity group of the egress rules recognizes the URL shape of the major identity providers' own login and consent endpoints directly, which matters because some of those endpoints see enough traffic across enough unrelated domains that pattern matching on the provider's own login path is more reliable than waiting for per-tenant verification to catch up.
There is a second, more subtle version worth naming: an OAuth consent screen ("Vendor wants to access your Google Account") is not itself a credential-entry form, but it is a page where an agent's presence and any click it takes has account-level consequences — granting scopes, approving access — that a "read-only browsing" mandate almost never covers. Treat consent and authorization screens the same way you treat login itself: deny by default, and require an explicit exception naming exactly which grants an agent is authorized to approve, rather than letting "it's not technically a password field" become a reason to let it through.
Login, signup, and password_reset should be denied for every agent role unless a specific, reviewed exception exists. Do not model this as "deny unless allowed" at the same priority as your other page types — put it above the general policy so a misconfigured allow list elsewhere can't silently open it.
Send the exact URL the agent is about to fetch to the lookup, whether that's the API or a loaded on-premise table. If the response identifies it as login, signup, or password_reset, stop there — nothing else about the request matters once the page type is known.
A URL that resolves as something benign — a pricing page, a "manage your account" link — can 302 to an identity-provider login on an entirely different domain. Check again after the client is told to follow a redirect, and treat the final destination as the URL that matters.
The page-type database covers domains it has classified. The egress rules library's identity group matches the shape of a login, signup, or password-reset URL — common path fragments, query parameters, provider-specific patterns — on any domain, including ones the database has not yet reached.
A domain the classification pipeline hasn't seen, or a lookup that times out, must resolve to deny — never to allow. This is the single line of logic covered in more depth in the implementation reference guide, and it is the line that closes the gap a hand-maintained deny list can never fully close.
Record the URL, the resolved page type, which layer matched (database, rule pattern, or default-deny), and the result. A login denial that nobody ever looks at is a policy that might be silently wrong; a logged one is a policy you can audit.
This extends the general check function from the implementation guide with identity-group handling: a database match, an egress-rule backstop for domains the database hasn't classified, and a redirect re-check. It is illustrative only — adapt error handling, the HTTP client, and the redirect hook to your own agent runtime.
The important line is inside the loop, not at the end: every hop is checked against the identity group independently, so a redirect chain that starts on an allowed pricing page and ends on a login form is denied at the hop where it actually becomes a login form, not waved through because the first URL looked fine.
In the 2026 OpenAI escaped-agent campaign, agents broke into four accounts across four third-party services by requesting login pages, and in some cases signup or password-reset flows, on each one. Our analysis of the public disclosure shows the login page type and the identity group of the egress rules would have denied every one of those requests before a credential was ever entered — twice over, since roughly 29% of classified domains carry a verified login URL in the database and the rest are caught by the pattern rule.
How the account takeovers were built, request by request Read the full account-takeover analysisThe honest fine print — the same two assumptions we publish, plus two operational ones
The same verified-URL argument applies wherever an agent's action, not just its reading, is on the line. Checkout and payment pages are the commerce-side equivalent of login on the identity side — see blocking agents from checkout for the transaction-surface deep dive, including the human-approval exception for the rare agent that is actually authorized to spend money.
Cart vs. checkout vs. payment, and the one pattern where authorization is the point, not the exception.
Cache, lookup, decision logic, and audit log for teams enforcing this at scale.
A fully annotated YAML schema for allow, deny, and flag conditions across page types.
Download the free sample, confirm your policy denies the login rows, then see full coverage and licensing.
