An agent that browses a merchant's catalog and an agent that completes a purchase are doing two entirely different things, and most policies treat them as the same event because both happen inside "the shopping flow." They aren't the same, and lumping cart, checkout, and payment together is exactly how a well-intentioned procurement or shopping agent ends up authorizing a real transaction nobody reviewed. This guide separates the three transaction page types, argues for denying all of them by default, and then covers the one legitimate exception: an agent explicitly authorized to transact, gated by human approval rather than by hoping the agent doesn't try.
"Don't let the agent buy anything" is the right instinct and the wrong policy, because it treats three page types with genuinely different risk as one thing, and it's a good example of why the four-layer enforcement model tracks specific page types rather than a single blunt "commerce" flag. A policy that denies all three uniformly is safe but often more restrictive than the actual task needs; a policy that allows all three because "it's just the shopping flow" is the mistake that lets a research agent accidentally place an order.
Consider the ordinary version of this failure: a procurement-research agent is told to "compare pricing across our shortlisted vendors and summarize the cheapest option." Nothing about that task requires checkout access — the agent needs pricing and product pages, nothing more. But if the agent's browsing tool treats "the vendor's e-commerce site" as one undifferentiated domain rather than a set of distinctly typed pages, there is nothing stopping it from following a "buy now" link it encountered while comparing prices, landing on checkout, and — if the tool auto-fills a stored payment method for convenience, which browser-automation tooling frequently does by default — completing a transaction nobody asked for. The task never called for a purchase. The page-type boundary is what would have stopped it; the task description alone did not.
Adding an item to a cart is, on most sites, a stateful but non-financial action — nothing has been charged, and the action is trivially reversible. Many research and comparison-shopping agents have a legitimate reason to interact here.
Checkout is where shipping, billing, and order details are entered and confirmed. It is the last page before a charge happens, and on many sites it is functionally the same event as payment — deny it by default with the same seriousness as payment itself.
Wherever a site separates payment (entering or confirming a card, a bank transfer, a stored payment method) from checkout as a distinct step, it is the single highest-severity commerce page type on the domain. Deny unconditionally outside the authorized-agent exception below.
The database also carries subscribe (recurring-payment sign-up — treat it exactly like checkout, since a subscription is a payment commitment that recurs without further agent action), pricing (read-only, safe to allow broadly), and product (read-only, the actual target of most legitimate shopping-research agents). A policy that names all five explicitly, rather than lumping them under one "commerce" bucket, is the difference between "the agent can research products and prices" and "the agent can spend money," which are not the same permission and should never be granted by the same rule.
The same verified-vs-guessed argument that applies to login applies here, with an added twist: payment is frequently handled by a third-party processor on a completely different domain from the one the agent started on.
| Pattern | Why a guessed path or domain-level rule misses it | What a verified URL gives you |
|---|---|---|
| A payment processor on its own domain (a hosted payment page, e.g. a Stripe, Adyen, or Braintree checkout redirect) | A rule scoped to the merchant's domain never evaluates the processor's domain the browser actually lands on | The processor domain is checked on its own record when the agent's client follows the redirect |
A multi-step checkout across several distinct paths (/cart, /checkout/shipping, /checkout/payment, /checkout/confirm) | A single path guess like /checkout catches only one step, leaving the others unclassified and, under a weak default, allowed | Each step, where the site's structure exposes it as a distinct link, is independently verified |
A subscription or recurring-billing flow that never uses the word "checkout" at all (/plans/upgrade, /billing/confirm) | Keyword-based path guessing depends on the vendor using expected terminology | The subscribe page type is classified by function, not by matching a keyword in the URL |
| An in-app or embedded checkout (an iframe or a same-page overlay with no distinct top-level URL) | Guessing needs a URL to guess; an embedded flow may not expose one to the outer navigation layer at all | Verification is based on the actual link the site's structure surfaces, including the embedded flow's own endpoint where discoverable |
The practical implication is the same one that runs through the login-pages guide: a rule that only understands the domain the agent started on will miss a transaction surface that legitimately lives somewhere else. Anywhere your policy evaluates a single domain in isolation, ask whether the actual commit point for that flow might be on a different one, and re-check after every redirect rather than only at the point of first contact.
Everything above is written from the buyer side: an agent operating on someone's behalf, browsing other companies' commerce sites. The same page-type distinction matters just as much from the merchant's own side of a transaction.
A merchant deploying an AI agent internally — for customer support, for catalog management, for fraud review — has a mirrored version of the same problem: which of its own page types should that agent be allowed to reach? A support agent answering "where is my order" questions has a clear need for order-status pages and no need whatsoever for its own checkout or payment-processing admin surfaces. A catalog-management agent updating product descriptions needs write access to product pages specifically, and nothing about that task implies access to the store's payment configuration or its customers' stored payment methods. The page-type boundary that keeps an outside research agent off a merchant's checkout is the identical boundary that should keep an internal support agent off the merchant's own payment infrastructure — the direction of the request changes, but the classification, and the argument for denying by default, does not.
This symmetry is why the four commerce page types are useful as a shared vocabulary rather than a buyer-only concept: a merchant writing an internal agent policy and a buyer writing an outbound-agent policy can describe the exact same boundary — cart is low-risk and often fine, checkout and payment are commit points and should be denied absent an explicit, narrow exception — without either side needing to reason about the other's infrastructure. The database's role is to make that boundary a verified URL on each specific domain rather than a shared assumption both sides hope holds.
There is exactly one legitimate reason to allow an agent onto a checkout or payment page: it has been deliberately authorized to transact, inside an explicit spending policy, with a human approval step in the loop. Building this correctly means the exception is narrower than "this agent can use checkout," not broader.
The authorized-to-transact flag belongs on the specific agent role and task, never as a global policy setting. "Procurement-approval-agent may reach checkout on pre-approved vendor domains" is a policy; "checkout is allowed" is not.
Authorization to transact should not mean authorization to transact anywhere. Combine the checkout allow with a vendor-domain allowlist, so the exception can't be exercised on a domain nobody approved.
A per-transaction and a rolling spending cap should be checked by the policy layer itself before the checkout request is allowed through, not left to the agent's own judgment about what's reasonable.
Route the actual payment submission through a flag-for-approval state rather than a silent allow, so a person confirms the specific order before money moves, even when every other condition is satisfied.
Notice what this pattern is not: it is not "trust the agent because it asked nicely," and it is not a prompt-level instruction telling the agent to be careful with money. It is four deterministic conditions — named exception, domain scope, spending cap, human confirmation — evaluated by the policy engine, any one of which failing results in deny. An agent that has been told in its system prompt "only buy things under $50" is one injected instruction away from ignoring that limit; a policy engine that refuses to pass a checkout request above a hard-coded cap has no prompt to be talked out of it.
This sketch layers the four conditions above onto the general check function from the implementation guide. It is illustrative only — wire the actual spend-cap accounting and approval workflow into your own systems.
Note the final return value: even a fully authorized, in-cap, on-allowlist checkout request resolves to flag, not allow. The policy engine's job in the transact case is to filter out everything that shouldn't reach a human at all — wrong agent, wrong vendor, over budget — and hand only the legitimate remainder to a person for the actual approval.
Every one of these numbers comes from the same source of truth as the rest of this site.
The 2026 account-takeover campaign shows what an unsupervised agent does with any reachable transactional surface once it has a foothold: it used a rogue app deployed on Modal Labs-hosted infrastructure and login pages on four services to act with authenticated permissions its operator never reviewed. Nothing about that pattern is specific to accounts — a checkout or payment page reachable the same way is the commerce-side version of the exact same failure. Our analysis shows the identity-group and transact-type deny rules would have refused the entry points before any authenticated action, commerce or otherwise, was possible.
See the incident-by-incident prevention analysis Read the account-takeover analysisThe honest fine print — the same two assumptions we publish, plus two operational ones
The identity-side equivalent of this guide: why login is the highest-severity page type of all.
A fully annotated YAML schema for writing exactly this kind of exception as a policy file.
Where the checkout gate above fits into a full cache-lookup-decision-audit architecture.
Merchants building the mirror-image policy — steering agents toward product and pricing pages while keeping checkout gated on their own storefront — should also see how webfilteringdatabase.com's broader filtering categories combine with page-type data when the concern is a whole class of destination rather than one page type on one domain.
One more scoping note worth stating plainly: none of this replaces your payment processor's own fraud controls, 3-D Secure prompts, or card-network rules. Those exist to catch a fraudulent charge after it is attempted. The page-type policy in this guide operates earlier, at the navigation layer, deciding whether an autonomous agent should be allowed to reach the checkout or payment form in the first place. A transaction that never gets attempted is not a transaction your processor's fraud model needs to evaluate at all, which is the cheapest possible place to stop an agent-driven purchase that should never have happened.
Download the free sample, confirm cart, checkout, and payment resolve the way your policy expects, then see full coverage.
