Three page shapes get confused constantly in agent policy design: the cart where items are collected, the checkout where a transaction is submitted, and the gateway domain a merchant's own checkout quietly redirects to. This reference explains how the database tells them apart, why the distinction matters for a spend-money guardrail, and what to do when a redirect changes the domain your agent is actually standing on.
Most homegrown agent policies write a single rule for "commerce pages" and move on. That collapses three page shapes with three different risk profiles into one bucket, and the collapse is exactly where a spend-money guardrail develops a hole: a policy that denies "checkout" by keyword match on the URL path will miss a checkout page hosted under a path that doesn't say checkout, and it will not know what to do when the agent is redirected off the merchant's domain entirely mid-flow.
The page-type database resolves this by verifying three distinct entries per domain wherever they exist — cart, checkout, and subscribe — each confirmed by the page's actual function rather than its URL text, plus classifying gateway domains like payment processors in their own right rather than treating them as an extension of whichever merchant redirected to them.
This matters most for the fleets that browse constantly and buy rarely: procurement-research agents, price-comparison agents, and general support or research assistants that happen to click through a pricing page into a shopping flow without ever intending to purchase anything. Those agents need commerce pages distinguished precisely, not lumped together, because "deny everything commerce-shaped" is close enough to correct that teams stop looking harder at it, right up until an edge case — a one-page checkout, a subscription upsell, a gateway redirect — slips through a rule that was never quite specific enough to catch it.
All three appear somewhere in a typical purchase flow. Only one of them is usually inside the merchant's own database record.
The page where items are collected and reviewed before purchase intent is finalized: add-to-cart confirmations, the cart summary table, quantity and variant edits. Verified when the merchant's own domain serves a live cart view with items and controls, not merely a link labeled "cart."
The page where shipping, billing, and payment details are actually submitted — the transaction step. This is the higher-stakes of the two commerce action types, and the one almost every agent guardrail policy denies by default, purchase-authorized agents excepted.
A shared, third-party domain a merchant's checkout redirects to for the actual payment step — a hosted Stripe Checkout session, a PayPal flow, an Adyen or Braintree drop-in. It is not part of the merchant's record; it is evaluated as its own domain when the agent actually lands there.
The 8 action types added in the current reclassification cycle — signup, password_reset, cart, checkout, upload, post_create, comment, subscribe — mark pages where an agent does something rather than reads something. Cart and checkout both qualify: adding an item to a cart writes state, and so does submitting payment details. The difference is what that write commits the agent to.
| Signal | cart | checkout |
|---|---|---|
| What the write commits to | Reversible — items can be removed before purchase | A financial transaction, once submitted |
| Typical agent policy default | Often flagged for review rather than hard-denied | Denied by default on every domain |
| Verification signal used | Live cart summary with items, quantity controls | A submittable form collecting payment or billing fields |
| Common URL shapes seen | /cart, /bag, /basket, a cart drawer route | /checkout, /checkout/payment, a gateway redirect target |
| Where it sits in the 28 types | Commerce group, action type | Commerce group, action type |
Neither label is guessed from the path text. A domain that names its cart route /bag or its checkout flow /order/complete is recorded correctly because the verification step confirms the page's actual function — a live cart with items and controls, or a form that actually collects and submits payment information — not because the path happened to contain a recognizable word.
A large share of online merchants do not process payment on their own infrastructure. They collect cart contents on their own domain, then hand the actual payment step to a hosted checkout page on a shared gateway domain built for exactly that purpose. That hop matters to a policy engine because it is a domain change, not a path change — and a guardrail that only checks the domain it started on will not see it happen.
The gateway domain itself is not a mystery entry your policy has to guess about: large payment processors are themselves classified in the 40M-domain database, with their own verified page types — including their own login and checkout entries. A lookup on stripe.com or paypal.com returns exactly the same kind of record as a lookup on any merchant, because they are domains like any other in the repository, just ones that happen to host payment flows for thousands of other sites. What is different is that the merchant's record never claims ownership of the gateway's pages — the two domains are classified independently, exactly as the redirect itself treats them.
This is the same principle covered in the implementation guide's discussion of redirect chains: a URL that was checked and allowed before the request does not stay allowed through every subsequent hop. A policy engine that checks once at the first URL and then trusts every redirect that follows has a gap precisely at the gateway boundary — the exact point where a purchase actually completes.
The classification pipeline follows the actual links a storefront exposes — navigation, product pages, cart controls — rather than starting from a list of path guesses like /cart or /checkout, which fail across the platform diversity of real e-commerce sites.
A candidate cart page is confirmed only if it renders a live cart with items and quantity controls; a candidate checkout page is confirmed only if it presents a submittable form collecting payment or billing information. A page merely linked from a "Cart" menu label is not enough on its own.
Where a merchant's checkout redirects to a gateway domain, the merchant's record captures its own verified entry point into that flow. The gateway domain is a separate record, classified independently the same way any other domain in the repository is.
Checkout flows change with storefront redesigns and platform migrations more often than most page types. Database licenses can add monthly refreshes (30% of the license price per year) so commerce-page URLs do not go stale between purchases.
A path-guessing heuristic — try /cart, then /checkout, then give up — performs reasonably well on the handful of storefront platforms that dominate case studies and demos. It performs much worse across the full population of 40 million domains, where custom builds, regional platforms, and older commerce systems each have their own conventions.
Consider the variety actually observed across live storefronts: a cart route might live at /cart, /bag, /basket, /winkelwagen on a Dutch-language site, or behind a JavaScript drawer with no dedicated URL at all until an item is added. A checkout flow might be a single page at /checkout, a multi-step wizard spanning /checkout/shipping, /checkout/payment, and /checkout/review, or a modal overlay that never changes the browser's address bar. None of these shapes is wrong; they are simply different implementations of the same commercial function, built by different teams on different platforms over different years. A guardrail that hard-codes path patterns will match the common cases and silently miss the rest — and the domains it misses are not evenly distributed. They skew toward smaller, regional, and non-English-language merchants, which is precisely the part of the web a path-guessing approach was least likely to have been tested against in the first place.
Verifying the page's function rather than its path text sidesteps this problem entirely. It costs more to build — traversing real link structures and confirming actual page behavior takes meaningfully more engineering than a regex against a handful of known-good paths — but it is the only approach that generalizes past the storefronts a heuristic's author happened to test against. This is the same argument made in more general terms in the implementation guide's comparison of build-your-own crawlers against a licensed database: the crawler is the easy part, and verified classification across the long tail is the part that rarely finishes on an internal timeline.
The Commerce group of the 28 page types also includes subscribe, the third commerce action type alongside cart and checkout. It gets its own label because a recurring-billing signup is a distinct commitment from a one-time transaction, and conflating the two in policy leads to gaps in both directions.
A one-time checkout is a single, bounded write: one charge, one order. A subscribe page sets up an ongoing relationship — a card on file, a recurring charge on a schedule, and often a separate account state that persists well past the moment the agent's session ends. An agent policy that only thinks in terms of "does this page spend money right now" can miss subscribe entirely, since the immediate page interaction may not look like a payment form at all; it may look like a plan-selection page that only asks for payment details on a subsequent step, or one that reuses payment details already on file for an existing account. Treating subscribe as its own action type, distinct from checkout, means a policy engine can deny it explicitly rather than relying on a checkout rule to catch a page that does not present as one.
In practice, most guardrail policies deny cart, checkout, and subscribe together as a single "spend or commit money" group, exactly as shown in the reference sketch on the implementation guide. The three-way split in the database exists so that the rare exception — a purchase-authorized agent that may complete a one-time checkout but must never set up a new recurring subscription, for example — can be expressed precisely instead of as an all-or-nothing commerce toggle.
| Agent role | cart | checkout | Gateway domain reached via redirect |
|---|---|---|---|
| Price-monitoring agent | Deny | Deny | Deny (re-checked on the new domain) |
| Procurement research agent | Deny by default | Deny | Deny |
| QA / test-purchase agent, scoped | Allow on approved test domains | Allow, human-approved, sandboxed | Allow only on the specific approved gateway session |
| General-purpose browsing agent | Flag for review | Deny | Deny |
The one scoped exception in the table — a purchase-authorized agent under a human-approval gate — is covered in depth on the agentic commerce safety use case, including how the approval gate itself should be designed so that "authorized to buy" never quietly becomes "authorized to buy anything, anywhere."
Several high-profile 2026 incidents involved AI agents escaping their intended scope and reaching pages they should never have touched — the Hugging Face breach through dataset uploads, the DseWiki hijack through legacy wiki write endpoints, the JFrog Artifactory covert channel, and account takeovers across four third-party services. Our analysis of the public disclosures shows the database and egress rules would have denied nearly every entry point, pre-request — the same default-deny logic covered here for commerce action types.
The 2026 agent incidents, prevented Read the account takeovers caseThe honest fine print — the same two assumptions we publish, plus two operational ones
Why pricing is the single most-requested page type, and how locale variants are handled.
Request and response shape, authentication, and quotas on the $99/mo Pro plan.
The one narrow, human-approved case where an agent is allowed onto checkout.
Verified pricing URLs instead of re-crawling storefronts for price changes.
The reference check function, including redirect re-verification.
~40 method-aware URL-pattern rules that catch risky shapes on any domain.
How the host list, database, egress rules, and default-deny fit together.
The companion product for blocking human access to risky AI tools, from the same team.
Download the free sample and confirm your cart and checkout denials actually fire before this touches production agent traffic.
