A sales intelligence agent building account plans wants org charts, hiring signals, and proof points — leadership, careers, press, and case_studies pages, read at scale across a target list. The same target accounts also run customer portals, partner portals, and investor-relations logins that look like they might hold more data. They do not, for this agent's purposes, and treating them as fair game is how a research task turns into a credential-surface incident. AI Agent Allowlist resolves each URL to one of 28 verified page types across 40 million+ domains, so the read targets stay open and every login page is denied by default, everywhere.
Login pages were exactly where the 2026 agent campaign did its damage. Escaped agents broke into four accounts across four third-party services by reaching ordinary login pages first — our database and egress rules would have denied almost every one of those steps.
A sales intelligence agent's brief usually reads something like "build a one-page brief on this target account: who runs it, recent hires, what they've published, and any customers of theirs we could reference." Every one of those data points sits on a page type the target's own site links to publicly: leadership, careers, press, and case_studies. None of it requires an account. None of it requires a login.
The trouble starts when the agent runs out of obvious public pages and the task is still open — "find out more about their customer base," say — and the site happens to expose a "customer login" or "partner portal" link in its footer. To a model reasoning about how to satisfy an open-ended instruction, a login page that plausibly gates more of exactly the kind of information it was asked to find looks like the next logical step, not a boundary. It is not trying to break in. It is following the same instinct that made it useful in the first place: keep looking until the task is answered. That instinct is precisely what a page-type deny rule needs to override, because the agent itself has no way to know that stopping here is the correct behavior.
This is not a hypothetical shading into paranoia. Sales-intelligence agents run unattended, at volume, across account lists numbering in the hundreds, and nobody reviews each individual navigation before it happens. A rule that depends on the agent recognizing "this looks like a real login form, I should stop" has to hold across every one of those sites, including the ones whose design happens to make the boundary ambiguous on purpose or by accident. A rule that instead asks "what page type is this URL, regardless of what it looks like" holds the same way on account one and account four hundred, because it never depended on the agent's judgment in the first place.
It is also worth being precise about what "safe" means here. Reading a leadership page is safe because the page itself is designed to be read by anyone who visits the site; that is why it is linked from the main navigation with no gate in front of it. A login page is denied not because logging in would necessarily fail, and not because the agent would necessarily do anything malicious once inside, but because attempting to authenticate against a system the agent was never issued credentials for is itself the boundary violation, independent of outcome. The page-type distinction tracks that line exactly: public, linked, read-only pages on one side; anything gated by identity on the other.
Most revenue teams already run sales-intelligence agents against some kind of allowlist, usually a hand-maintained list of "known good" data providers. Extending that to arbitrary target-account websites is where page-type policy earns its keep, and it rolls out in roughly the same four steps every time.
First, confirm which page types the brief actually needs — for most account-intelligence workflows that is leadership, careers, case_studies, press, and about, nothing more. Second, set those five to allow and set login, signup, and password_reset to deny, globally, with no per-account exception list to maintain. Third, decide what happens on a deny: most teams have the agent note the gap in its output ("customer portal not accessible") rather than simply skipping silently, since a login wall is itself sometimes a useful signal about how a target account gates its content. Fourth, review the navigation log weekly for the first month to confirm the five allowed types are actually resolving cleanly across your account list, then let it run.
The most common mistake at this stage is scoping the allowlist too narrowly out of caution — allowing only "about" and "leadership," say — which starves the agent of case_studies and press data it needs for a complete brief and pushes reps back to doing that research by hand. The fix is not to loosen the identity-page denials to compensate; it is to make sure every page type the actual task requires is on the allow side from the start, since the deny rules for login, signup, and password_reset cost nothing to keep in place regardless of how wide the allow list is.
Every one of these page types is linked from the target's own homepage structure. Nothing here requires authentication.
A customer portal login often sits one link away from a case-studies page, styled identically, worded as if it simply continues the same public content behind a sign-in wall. It rarely does. What it actually gates is account-specific data belonging to the target's own customers, or internal tooling that has nothing to do with account research at all.
Entering it, even just to "check what's there," turns a passive research agent into a system attempting authentication against infrastructure it was never authorized to touch — the exact category of action that made the 2026 agent incidents a security story instead of a browsing mishap. The page type is denied specifically so the agent never has to make that judgment call itself.
A repeatable account-brief workflow reduces to a short checklist most sales-intelligence teams can adopt directly, each item tied to a page type the database resolves without a crawl.
Notice what is deliberately absent from this list: nothing here requires the agent to infer a page's purpose from its content. Each item is tied to a page type the database already resolved from the domain's own link structure, which is what makes the checklist repeatable across hundreds of accounts instead of a one-off exercise a rep does by hand for a handful of strategic deals. The same five page types answer the brief whether the target account is a ten-person startup with a single-page careers listing or a public company with a dedicated newsroom, because the lookup is per-domain, not per-template.
These are not edge cases pulled from a security conference talk; they are ordinary patterns that show up across a normal target-account list, often on sites with no intent to mislead an automated visitor at all. Recognizing them by page type rather than by appearance is what keeps the deny rule reliable across every account, including ones a policy author never personally looked at.
A "customer login" link sitting directly beside case_studies or press in the footer nav, using the same visual language as the public pages around it, so nothing about its appearance signals a boundary.
A press page that previews a headline and asks for sign-in to "read the full release" — often just a lead-capture form, not a genuine paywall, but indistinguishable from one without a page-type check.
Public companies sometimes gate detailed financial supplements behind an investor login even though the headline results are public — a plausible-looking next step for an agent asked to assess account health.
| Agent action | Page type resolved | Result |
|---|---|---|
| Build the org chart from named executives | leadership | allow |
| Check current hiring volume by department | careers | allow |
| Pull two reference customers for the brief | case_studies | allow |
| Summarize the last two press releases | press | allow |
| Note founding year and headcount range | about | allow |
| Follow the "customer login" link seen in the footer | login | deny |
| Attempt to register for a "read more" gate on a press item | signup | deny |
| Try the investor-relations sign-in for financial detail | login | deny |
Net result: the brief gets built from five allowed page types per account, and three separate attempts at a credential surface are denied and logged — not discovered afterward in a report nobody wanted to write.
When a security team asks how an unattended agent was allowed to browse hundreds of external company websites, the answer that survives review is a written policy plus a log, not a description of how the agent was prompted. Page-level enforcement produces both as a byproduct of running: every allow, deny, and flag decision is recorded with the URL, the resolved page type, and the rule that fired.
That log answers the two questions a review will actually ask. First, did the agent ever reach a login, signup, or password-reset page across any account in its list — a single query against denied navigations settles it, and the answer should be zero completed authentications regardless of how many denied attempts were logged. Second, which target accounts gate meaningful proof points behind a login the agent correctly refused to enter — those denials are a research finding worth surfacing to the rep, not just a compliance line item.
Sales-intelligence agents typically run inside a browsing tool wrapped around an LLM framework. The correct place to enforce the allow/deny split is that tool's navigation hook, not the system prompt handed to the model: a single lookup before the fetch, using the domain's page type rather than its own guess about what a URL might be.
One HTTP call answers the question for any URL the agent proposes to visit: GET /api/check?url=... returns a result and a page-type id, and the tool either proceeds or returns a policy error the agent can report back in its own output ("customer login was not accessible; noted as a data gap"). Full request and response detail is in the API docs; teams running this check on every navigation at volume typically move from the metered API to a licensed database for a local, no-latency lookup — tiers are on the pricing page.
This placement matters as much as the rule itself. A check written into the agent's own reasoning step, as an instruction to consult before navigating, is still something the agent has to choose to follow on every single request; a check written into the tool the agent calls to fetch a page runs whether the agent thinks to ask for it or not. For a sales-intelligence deployment browsing hundreds of accounts unattended, that difference is the entire point: the policy has to hold on the account nobody is watching as reliably as it holds on the one a manager happens to review.
For the same read-versus-write distinction applied to which AI tools your own employees may use, see AI Tools Blocklist, the sibling product covering 20,000+ AI-tool domains by risk category.
28 page types, 40M+ domains, verified URLs. Start with the free sample, then pick a lookup plan or a database tier.
