Every other use case on this site treats checkout the same way: deny by default, no exceptions, full stop. Procurement agents research vendors but never transact. Support agents read status pages but never touch a payment form. This page is different on purpose. Agentic commerce — an agent authorized to complete a purchase on a customer's behalf — is the one workflow where checkout access is deliberately allowed, and only through a human-approval gate built around the same verified page-type data.
In plain words: checkout stays denied everywhere except a short, explicit list of approved vendors and spend limits an organization sets itself, and even an approved purchase routes through a human confirmation step before the money moves. Every other identity and write page type — login, signup, post creation, uploads — stays denied exactly as it does everywhere else on this site.
2026 showed what happens when an agent acts without a human in the loop. Third-party account takeovers and the Hugging Face breach both involved agents completing consequential actions with nobody checking first. An authorization gate on spending is the same lesson applied specifically to commerce.
Across every other use case this database supports, checkout and cart are treated as pages an autonomous agent should never reach on its own initiative. A procurement agent researching vendors is explicitly denied checkout access, full stop, regardless of what it finds. A support agent, a lead-enrichment agent, a content-research agent — none of them have any legitimate reason to be anywhere near a payment form, and the default policy for all of them reflects that.
Agentic commerce is the deliberate exception. When a business explicitly wants an agent to complete purchases on a customer's or an operator's behalf — reordering office supplies from an approved vendor, executing a pre-approved subscription renewal, completing a purchase a customer has already configured and confirmed they want — the checkout page type can be allowed, but only for domains on an explicit approved-vendor list, only within a spend threshold the organization sets, and only after a human-approval step confirms the specific transaction. Outside that narrow, explicitly configured exception, the same default-deny rule that governs every other use case on this site still applies here too.
The gate is what makes the exception safe. Every proposed checkout runs through the same sequence, and a purchase only completes if it clears every stage — not most of them.
The agent identifies a purchase it believes fulfills its task and requests to proceed to checkout on a specific domain.
The domain is checked against the page-type map and the organization's approved-vendor allowlist. Off-list domains are denied here, immediately.
The proposed amount is checked against a configured limit — per transaction, per day, per vendor. Over-threshold requests route to a stricter approval path.
A human reviews the specific transaction — vendor, amount, item — and approves or denies it. Nothing executes without this step.
An approved purchase completes and is logged with full detail; a denied one is logged too, with the reason, for the same audit trail.
It's worth being explicit about how little actually changes. Commerce-safety policy is the standard default-deny policy with one narrow, conditional carve-out — not a wholesale loosening of the rules.
| Page type | Default policy (every other use case) | Commerce-safety policy (this page) |
|---|---|---|
| login | deny | deny — unchanged, no exception exists for identity surfaces |
| signup | deny | deny — account creation is never part of this exception |
| password_reset | deny | deny — unchanged |
| cart | flag | flag — building a cart is lower stakes than paying; still logged |
| checkout | deny | allow, gated — only for approved vendors, within threshold, after human approval |
| subscribe | flag | flag — unchanged; a recurring commitment gets its own review |
| post_create / comment | deny | deny — content-write surfaces are outside this exception entirely |
| upload | deny | deny — unchanged |
Notice what's absent from the right column: there is no row where an identity or content-write page type becomes more permissive. The exception is scoped to exactly one page type, checkout, and even that one page type only loosens from an unconditional deny to a conditional, human-gated allow — never to an unconditional allow.
It's worth stating the reasoning for why the exception stops precisely at checkout and doesn't extend to, say, signup. Completing a purchase on a pre-approved vendor within a spend limit is a bounded, reversible-enough action that a business can reasonably choose to authorize in advance and confirm per instance. Creating an account, resetting a password, or posting content on the agent's behalf are qualitatively different: they create standing state — an identity, a credential, a public post — that persists and compounds in ways a single bounded purchase does not. That's a deliberate line, not an oversight, and it's the reason this exception is written narrowly enough to name a single page type rather than a category of "commerce-adjacent" actions.
The commerce-safety policy is not a separate system — it's the same page-type-driven policy engine every other use case on this site runs, configured with one additional rule and one additional integration point: a human-approval queue the agent's checkout request routes through before it's allowed to proceed.
Of the 28 page types this database classifies, exactly one carries a conditional allow rule anywhere in this product's guidance, and it appears only on this page. Every other use case, every other industry, every other guide treats checkout as an unconditional deny. That asymmetry is deliberate: agentic commerce is a real, growing workload, but it is a narrow slice of what agents on the open web should be allowed to do, and the policy language reflects that narrowness rather than papering over it.
This is a narrower workload than most of the use cases on this site, and it shows up in a few specific contexts rather than broadly across agent deployments. It is worth naming those contexts explicitly, because the gate design only makes sense once the scope of "who approved what, and why" is clear.
Reordering consumables from a short, pre-approved vendor list — office supplies, standard parts — within a set budget, with a human confirming anything unusual.
An agent a customer explicitly authorizes to complete a specific, pre-configured purchase — not to browse and decide what to buy unsupervised.
Executing a renewal the account holder already approved in principle, with the gate confirming the specific charge before it recurs.
In every one of these, the agent is not deciding whether a purchase should happen in some open-ended sense — a human or a prior configuration step already decided that. What the agent is automating is the mechanical act of navigating to checkout and executing a specific, bounded transaction, with the gate ensuring the specific instance still gets checked against the vendor list, the spend limit, and, for anything non-routine, an actual person.
What none of these contexts look like is an agent independently deciding to shop: browsing a category of products, comparing options across several unapproved vendors, and completing whichever purchase it judges best, unsupervised. That broader, more autonomous shopping-agent pattern is a genuinely different risk profile from the bounded, pre-configured transactions this gate is built for, and it deserves a correspondingly stricter design — likely closer to always-flag rather than conditional-allow — that is outside the scope of what's described here. The gate on this page assumes the purchasing decision itself is already made; it only automates and verifies the mechanical execution.
Checkout stays denied everywhere except the vendors and thresholds you configure, with human approval on every transaction. Start with the free sample, then pick a plan.
