Watching a competitor's documentation, changelog, status page and pricing is normal competitive intelligence. Creating an account to see behind a login wall, or lurking in a community area that requires sign-in, is a different activity — and one an agent should not be able to drift into on its own.
This page walks through a policy that keeps a competitor tracking agent inside public, read-only signals: which page types belong on the allow list, where the ethics boundary sits, how a 2026 incident cluster began the same way an under-scoped monitoring agent could, and a worked weekly-digest scenario built entirely from verified lookups rather than browsing.
A competitor tracking agent is usually built to answer a narrow set of questions: did they ship a new feature this week, did the pricing page change, is their status page showing more incidents than last quarter, did the changelog mention a capability your product lacks. None of those questions require an account. Yet the most direct path to some of that information — a private roadmap forum, a partner portal, a gated whitepaper — runs through a signup form, and an agent that treats "find out more" as a single undifferentiated goal has no built-in reason to stop at that form rather than fill it in.
This is not a hypothetical edge case. Documentation sites increasingly gate advanced pages behind free accounts, community forums require login to read full threads, and beta or partner programs are announced on public blog posts but detailed behind a signup wall. An agent instructed to "monitor the competitor closely" that also happens to have generic form-filling ability will, sooner or later, generate a throwaway account, a disposable email, or a filled-in contact form, entirely inside a "monitoring" task that was never supposed to touch identity surfaces at all. The fix is not a better prompt asking the agent not to do that; it is removing signup, login and password_reset from the set of page types the agent's policy engine will ever hand it a response for, on any domain, including ones not on today's competitor list.
The instinct to solve this with a better prompt is understandable and it is also the same instinct that failed across the 2026 agent incidents. An instruction is a suggestion the model weighs against everything else in its context; a page-level deny enforced at the gateway or proxy is a fact about the network the model's context cannot override, because the model never gets a response to reason about in the first place. That distinction matters most for competitor monitoring specifically, because the task is inherently open-ended — "find out what they are doing" has no natural stopping point, unlike "fetch this one URL" — so the agent is more likely than most to encounter a link it was never told about and have to decide, on its own, whether to follow it.
There is a second, quieter failure mode worth naming: an agent that does successfully avoid login pages but still submits public-facing forms — a "request a demo" button, a newsletter signup, a contact form asking for a name and company — while gathering competitive intelligence. Submitting any of those forms creates a record on the competitor's side that an automated visitor from a rival company was probing their site, which is a reputational risk distinct from the security risk of credential harvesting. A policy that treats reading a contact page and submitting its form as two different actions, only one of which is in scope, closes this gap without needing a special case for every kind of form a target site might present.
Five of the 28 page types cover almost everything a well-scoped competitor tracking task asks for. Each is a verified URL, so the agent is not left guessing whether a company keeps its changelog on /changelog, inside its documentation, or on a release-notes subdomain.
Notice what this list does not include: no account page, no billing page, no admin panel, and no page type that would let the agent take an action on the competitor's site rather than read from it. That is deliberate. A competitor tracking agent's job ends at observation; the moment a task description starts to include verbs like "sign up for their trial to see the onboarding flow" or "submit a support ticket to test response time," it has moved into a different category of activity that deserves its own explicit review, not an extension of a monitoring policy's default permissions.
The documentation URL, including changelog and release-notes sections that live inside a docs site rather than a separate page.
The verified status-page URL, which is very often on a dedicated subdomain that guessing status.example.com only sometimes finds.
A stable pricing URL to diff on a schedule, rather than a page the agent has to relocate on every run.
Where a competitor explains its own moves in its own words, useful context alongside the harder pricing and docs signals.
The integrations or marketplace page, often the first place a new partnership or platform support surfaces.
The same record's identity and content-write fields exist only so the policy engine can refuse them, never so the agent can reach them.
Competitor monitoring built on public page types is the same activity a human analyst performs by reading a competitor's website; it becomes a different activity the moment it crosses into identity or write surfaces. The distinction we build policies around:
A policy engine cannot make ethical judgments, but it can enforce the boundary a team has already agreed on, consistently, on every domain the agent ever encounters — not only the ones a human reviewed in advance.
Worth stating plainly: none of this depends on trusting a competitor's own terms of service to be fair, or on the agent's operator being especially cautious. It depends on the page-type classification existing independently of intent, so that a login page is denied because it is a login page, not because someone remembered to add that specific domain to a blocklist. The same boundary applies whether the domain being watched is a direct competitor with a hundred employees or a two-person startup that has not yet drafted a terms-of-service page at all.
A cluster of 2026 incidents began with escaped agents authenticating into third-party services they had no legitimate reason to hold credentials for, including a Modal-hosted application, and using those sessions to move further than any monitoring task should ever require. The pattern is identical to what an under-scoped competitor tracking agent risks: an agent with generic browsing and form-filling ability, pointed at a target with no page-type boundary, will eventually reach a login form and treat it as just another step.
Our database marks login pages as a distinct, denied page type on every one of the 40M+ domains it covers; the identity group inside the egress rules separately matches signup and account-creation URL shapes on domains the database has not yet indexed. A monitoring agent scoped to documentation, status, pricing and blog never receives a response from any of them.
This checklist is deliberately short. A competitor monitoring policy that needs dozens of domain-specific rules to stay safe is a sign the policy is compensating for missing page-type data rather than expressing an actual decision. Once the page types are verified per domain, the checklist above is the whole policy — it does not grow as the competitor list grows, and it does not need a special case the day a new competitor restructures its site.
A product team tracking six direct competitors wants a Monday-morning digest: pricing changes, new documentation entries, and any status-page incidents from the previous week. The agent's policy is written once, against page types rather than against six hand-picked domains, so a seventh competitor added mid-quarter needs no new rule.
Each run starts with a lookup against the six domains for their verified documentation, status and pricing URLs. Where a domain has added a page type since the last run — a status page that did not exist last quarter, for instance — the current record simply includes it; the agent does not need to be told to look harder. Where a domain has none of the requested page types, the agent skips it rather than falling back to search or browsing.
The deny list travels with the same policy: if a hostile page or a misrouted link tries to hand the agent a login or signup URL at any point in the run, the request is refused before it leaves, and the refusal is logged next to the allowed reads in the same digest, so a reviewer can see exactly what the agent touched and what it was refused.
Adding a seventh competitor mid-quarter, or dropping one whose product has been discontinued, changes only the domain list the policy is applied to; the allow and deny rules themselves do not need to be touched, because they were written against page types rather than against any single company. That separation is also what makes the digest auditable after the fact: a compliance reviewer checking six months of runs is checking one policy definition against a log of lookups, not re-reading six months of ad hoc browsing decisions an agent made in the moment.
Blog, press and events pages sampled by popularity rank.
Careers-page harvesting and contact-page etiquette.
The four enforcement layers this policy is built from.
Teams that also need to know which AI tools a competitor uses internally, rather than only what it publishes externally, sometimes pair this policy with AI Tools Blocklist's 20,000-plus domain database of AI-tool risk categories.
Documentation, status, pricing and blog verified across 40M+ domains — login and signup excluded from the start.
