Ask four questions about an automated journey
AI shopping agents make a simple allow-or-block label inadequate. A shopper may want software to compare products or prepare a basket. A merchant may welcome that discovery while applying separate rules to purchases or repeated costly actions. The policy problem is to distinguish what was observed, who is making a claim, what was authorised and what happened afterwards.
These four questions framed Blokk's 24 September guide to AI shopping agents. This retrospective develops them into a review exercise. It does not announce agent verification: Blokk's research alpha does not identify or verify specific AI agents, and signed-agent support remains pending.
1. What evidence of automation is available?
A browser can report automated control. A backend can observe repeated actions. Each observation has a source and a limitation. Browser assertions can be altered; repeated behaviour can have ordinary explanations. Write the observation in the review before writing the interpretation. For example, record a declared automation indicator separately from a repeated-action pattern.
The absence of an indicator leaves a gap. It does not establish that a person acted. A test set should therefore include ordinary fast interaction, keyboard-led use and authorised automation alongside the unwanted scenario. These are useful counterexamples for policy design, not a basis for claiming a measured real-world error rate.
2. Can the provider claim be checked?
A familiar user-agent name is supplied by the requester. Google, for example, documents ways to check crawler requests using published IP ranges or reverse DNS followed by a matching forward lookup. That is a provider-specific verification process applied to the actual request. The name alone is not the process.
Ask whether your integration receives the evidence needed for that check. A Shopify browser event does not give Blokk the original request to Shopify's infrastructure. It cannot authenticate a crawler which never contacted an observation point under Blokk's control. When that evidence is unavailable, retain an unknown identity state instead of creating confidence from a label.
3. Was this particular action authorised?
Even an established provider identity would not establish a shopper's permission to make a purchase. Browsing, changing a cart, redeeming an allowance and submitting an order have different consequences. Each action still needs the application's normal authentication and authorisation checks. An agent-provider allowlist should not silently bypass them.
For a review exercise, write a short permission statement for the action: what resource the actor may use, which operation is allowed and when permission expires. Then ask where the application checks that statement. If the answer is only a browser field or a provider name, the permission question remains open.
4. What did the merchant later establish?
An automated action can be legitimate. An action without automation indicators can still turn out to be unwanted. Keep the later business outcome separate from the earlier detection result. Record how the outcome was established and retain corrections when a merchant or shopper supplies better evidence.
A policy decision also has its own meaning. Allowing an action records what the application chose to permit; blocking it records what it chose to refuse. Neither choice proves the actor's intent. Mixing those decisions into outcome labels makes a review appear more conclusive than the evidence permits.
Turn the distinctions into a policy review
Start with one journey and complete the four questions for each meaningful action. Mark missing evidence visibly, name the control that actually exists, and agree who can review an exception. For Shopify, begin within the confirmed observation coverage and keep existing protections in place. Blokk's current offer is a guided monitor-mode pilot. Hosted monitoring has been exercised on development stores; merchant production installation and public app approval remain pending.
- State the automation observation without assigning harmful intent.
- Record provider identity as claimed, checked or unknown.
- Require permission for the action independently of provider identity.
- Review business outcomes and preserve corrections before changing policy.