Enterprise browsers already do category-based control well: block gambling, block file-sharing, allow business software. That control was built for humans clicking links. An agent embedded in the same browser needs a second axis — not just what kind of site is this, but what kind of page, on a site the browser has already decided to allow. AI Agent Allowlist is that second axis: 28 page types, verified, across 40 million+ domains.
Your category engine keeps deciding which sites are reachable at all. This layer decides which pages, on those sites, an agent may touch.
Written for the teams that build a browser’s policy engine or evaluate one for enterprise deployment — not for end users configuring a personal browsing profile.
Your customers were exposed to this. In 2026, agents reached wiki-edit endpoints on legitimate, category-allowed sites — including roughly 15,000 edits absorbed by one hijacked wiki, DseWiki, through legacy write endpoints a category filter would never have flagged. A page-type rule on the same allowed domain would have.
Category filtering answers “is this domain allowed at all?” at the site level, once, and applies the same answer to every page on it. A page-type rule answers a second, independent question for every navigation: on this already-allowed domain, is this specific URL a safe page to read, or a credential, transaction, or write surface the agent should never touch? Enterprise browsers need both answers, evaluated separately, because the second one changes on every click while the first one does not. A browser that already runs category filtering is not starting over to add this — it is adding one more lookup to a decision point it already owns.
A browser’s content-filtering stack was built to answer one question well. Agent traffic asks it a second question it was never designed to answer.
Category engines assign a verdict to the domain as a whole — Software, Retail, News — and that verdict does not change based on which page within the domain is being requested.
A retailer’s product catalog and its checkout flow carry the same category verdict today, even though one is safe reading and the other is a transaction an agent should never trigger unsupervised.
Wikis, forums, and community sites are frequently allowed by category — legitimate collaboration tools — with no signal distinguishing their read pages from their edit and post endpoints.
Login and password-reset pages on an allowed domain look, to a category engine, exactly like every other page on that domain.
Some write endpoints accept plain HTTP GET requests — DseWiki’s edits were exactly this — which a method-only or category-only check has no way to catch.
A human clicking into a checkout page is making a deliberate choice a category filter never needed to second-guess. An agent doing the same thing may be one ambiguous instruction away from an unintended purchase.
The two layers answer different questions and combine into a single enforcement decision at the point your browser already intercepts every navigation. Neither layer alone is enough for agent traffic; together they cover the domain-level and page-level questions a policy engine actually needs answered before a request fires.
Site category (your existing engine, or the 59-category filtering taxonomy and 700+ IAB categories in this database): is the domain itself one your policy allows agents onto at all — Software vendor, allowed; Gambling, not allowed?
Page type (this database’s core schema): on an allowed domain, is this exact URL a documentation page, a pricing page, a login page, or a checkout — each with a different default policy.
URL-pattern rules (the egress rules library, included with every license): catches write and exfiltration surfaces — wiki edits, WebDAV, registry admin panels — on any domain, allowed or not, regardless of category.
A single allow/deny/flag decision your browser enforces before the request fires, logged the same way your existing category decisions already are.
Every row above sits on a domain your category engine has already allowed. The page-type axis is what turns “this domain is fine” into “this specific page is fine,” which is the granularity agent traffic actually needs.
Axis 3 matters most for exactly the sites your category engine is right to allow: collaborative platforms, wikis, and community tools that are legitimate parts of a modern workflow and would be an over-broad block if denied wholesale. Their write endpoints are the surface the egress rules were built for, and because those rules are evaluated on the URL pattern itself rather than the HTTP method alone, they still catch a write endpoint that happens to accept a GET request — a distinction that mattered directly in the 2026 wiki-hijack incident, where the write traffic looked, at the transport level, identical to an ordinary page read.
Picture an enterprise browser deployed to a procurement team, with an in-browser agent enabled to research suppliers. The category engine already allows the supplier’s domain — it is a legitimate manufacturing vendor, categorized Business & Industrial. That single verdict now has to govern every page on the site the agent might visit.
Without a page-type layer, the browser has exactly one lever: allow the whole domain, or block it. Allowing it means the agent can read the vendor’s catalog and specification sheets — useful, intended research — but nothing stops it from also reaching the vendor’s account-registration page, or a “request a quote” form that silently submits a lead with company details attached. Blocking the whole domain to avoid that risk removes the research capability the agent was deployed for in the first place.
With page-type rules layered on top of the existing category allow, the browser keeps the domain open and adds page-level granularity: product and documentation pages stay allowed; signup and subscribe pages deny or flag by default. The procurement team keeps its research capability and its lead-generation exposure at the same time, on the same domain, in the same browser session.
Own the default policy shipped to every managed endpoint — typically strict default-deny on identity and commerce page types, applied uniformly across business units regardless of which agent product a given team has adopted.
Distribute the page-type policy alongside existing device and category-filtering profiles, so it ships through the same management channel administrators already use, without standing up a second console for a second dataset.
Configure narrow exceptions for their own agent workflows — a procurement team approving checkout on specific vendor domains, for example — on top of the security team’s baseline.
The reason this splits cleanly across three teams is the same reason category filtering already splits this way: a browser vendor exposing page-type policy as a configurable layer, rather than a fixed rule, lets each of these teams own the part of the decision that is actually theirs.
In practice, the security team’s baseline and the business unit’s exceptions rarely conflict, because they operate on different scopes. The baseline says “identity and commerce page types deny by default, everywhere, for every agent session” — a rule the security team is unlikely to ever want overridden globally. The exception says “this specific vendor domain, for this specific procurement workflow, may proceed to checkout” — a narrow carve-out scoped to one domain and one agent role, which is exactly the shape a page-type-plus-domain-allowlist condition is built to express.
Identify which browser sessions or extensions are agent-driven versus human-driven — page-type rules typically apply only to the former.
Local database load for zero added latency, or an API call from your existing policy-evaluation point.
Page-type conditions evaluate after category allows the domain — a second gate, not a replacement for the first.
Log decisions before enforcing them, then turn on hard denial for identity and commerce page types first.
Some browser vendors already run a category-classification pipeline for their filtering engine and ask a reasonable question: can we extend that pipeline ourselves instead of licensing a second dataset? The honest answer is usually no, for reasons specific to page-type detection rather than site categorization.
Site categorization classifies one thing per domain. Page-type detection classifies dozens of URLs per domain and has to be right about which specific link is the login page versus the help center — a materially harder problem per domain, multiplied across 40M+ of them.
Finding the real login URL, not a guessed one, means walking each site’s actual navigation, footer, and internal links — the pipeline behind this database individually analyzed more than 10 billion links to build it.
Page-type URLs move on a different schedule than site categories — a redesign can relocate a login page without changing what category the site belongs to, which means a second, independent re-verification cycle to keep current.
Browser vendors evaluating this as an embedded, on-device or gateway-synced feature typically license the full database rather than call an API from every endpoint, to keep the lookup local and avoid a network dependency per navigation.
| License | Coverage | One-time price | Refresh |
|---|---|---|---|
| Database — 10M domains | Top 10M by real-world usage | $14,999 | 30% of price / yr |
| Database — 15M domains | Extends into regional/niche properties | $24,999 | 30% of price / yr |
| Database — 30M domains | Near-complete active-web coverage | $49,999 | 30% of price / yr |
| 40M+ / custom slice | Full repository, or cut by geography/vertical | Contact | Contact |
| OEM embed | Bundled inside your browser distribution for your customers | Custom | Custom |
A quarterly refresh keeps page-type URLs aligned with sites that redesign, and picks up newly registered domains — roughly 300,000 screened per cycle. For a control shipped inside a browser your customers rely on daily, a stale map is a growing blind spot, not a one-time cost saved. Full self-serve terms are on pricing; OEM embed terms are quoted via contact.
One deployment detail worth planning for up front: a browser vendor distributing a licensed database to every managed endpoint is effectively distributing a data file to your entire install base on every refresh, not just to a central policy server. Most vendors solve this the same way they already solve category-database distribution — a compressed delta update pushed through the existing endpoint-management channel — so the addition of page-type data does not require a new distribution mechanism, only a new payload on a channel you already operate, sized the same way a category database update already is today.
An enterprise browser already enforces a category policy at the tab level: employees on managed endpoints cannot reach gambling or adult domains, full stop. A customer now wants the same browser's agentic-browsing feature scoped so an in-browser research assistant can read a vendor's documentation but never reach that same vendor's login form.
The category engine has no opinion here, because the vendor's domain is not gambling or adult — it is an approved SaaS vendor, and the category rule already allows it. The page-type layer is what narrows the allowed surface within that approved domain, denying login, signup and checkout while leaving documentation, pricing and support pages reachable. The two engines run side by side, evaluated in the same request path, with the category rule answering "which domain" and the page-type rule answering "which page on it."
If your enterprise browser sits behind a corporate proxy or SSE stack, coordinate page-type enforcement with that layer rather than duplicating it — see SSE agent traffic policy. If you are packaging this as a feature for platform partners rather than an end-customer product, the OEM framing on agent platform vendors may describe your business model more precisely. For the underlying four-layer mechanism, read agent guardrails and the full page-types database overview. Browser vendors that also filter human traffic to unapproved AI tools may want AI Tools Blocklist’s 20,000+ AI-tool domain list alongside this.
One question that comes up outside this FAQ often enough to note here: how this interacts with existing safe-browsing and malware-URL feeds. The two stay independent and complementary. A malware or phishing feed answers “is this URL known-bad, regardless of what it is?” Page-type data answers “what kind of legitimate page is this, and should an agent be allowed on it?” A URL can fail a malware check and never reach the page-type question at all; a URL that passes the malware check still needs a page-type answer before an agent is allowed to touch it. Browsers that run both checks in sequence — safety first, then page type — get the full picture neither feed provides alone.
Page-type rules for agent traffic, layered onto the category filtering you already ship. Start with the sample, then talk deployment.
