Agent disclosure

How Ottom’s agents identify themselves

Ottom sends automated shopping agents to storefronts to check whether an AI assistant could complete a purchase. We do that in the open. Everything below is how you recognise us, and how to stop us if you would rather we did not visit.

User agent

Every request we make to a storefront carries this string:

OttomAgent/1.0 (+https://ottom.io/agent)

When a check walks your store at phone size, the same string is followed by the word Mobile, so your store serves the layout a shopper on a phone gets:

OttomAgent/1.0 (+https://ottom.io/agent) Mobile

It still starts with the string above, so a rule that looks for that string finds both.

Our browser also sends client hints, as the automation library that drives it sets them by default. We change nothing in them to look like a person’s browser.

From header

Every request we make to your store’s own pages carries a From header. RFC 9110 defines that header as the mailbox of whoever runs the client, so ours is an address and not a link:

[email protected]

Requests your pages make to other services, such as a font host or a payment widget, carry our user agent but not this header. Those services did not ask to hear from us.

A person reads that mailbox. Your bot protection can key a rule on it, and a reply reaches the same place the opt-out below does. The link to this page is in the user agent above, which is where a URL belongs.

Egress IP addresses

All store-scanning traffic leaves from this static address:

• 93.189.5.236

The same list in machine-readable form, for a firewall rule or a script: https://ottom.io/agent/ips.json

This address is also what Ottom’s own servers use to reach the internet, so a request from it is Ottom, but not necessarily a scan. The user agent tells you which.

Check a request was really us

A request is ours when all three are true:

1. Its user agent starts with OttomAgent/.
2. It came from an address in the list above.
3. Where it went to one of your own pages, its From header is [email protected].

Anyone can copy a user agent, so the address is the check that matters. A request that carries our user agent from any other address is not us. Forward it to [email protected] and we will confirm it in writing. If you use Cloudflare, our Cloudflare settings guide shows where each rule goes.

Block us in robots.txt

Our robots.txt token is OttomAgent. To stop every visit:

User-agent: OttomAgent
Disallow: /

To keep us away from part of your store, disallow just that path. A group for any prefix of our token, such as User-agent: Ottom, applies to us too. We read robots.txt at the start of every check, so a change applies to the next one.

What we check against robots.txt

A retrieval check reads robots.txt first, then checks every page it fetches against it, including every redirect. A Disallow: / that applies to us ends the check there.

A journey walks your store the way a shopper does: it opens a product page, clicks, and follows your store’s own links and buttons. Pages it reaches by clicking are not checked against robots.txt, because a shopper’s browser would not check them either. Pages the journey opens itself by address are checked: your basket at /cart, the cart routes your platform publishes, and Shopify’s /checkout. If one of those is disallowed, the journey does not open it and its report says so.

A few requests a journey makes are not checked against path rules, and we list them because your robots.txt may name them. The product page and home page it starts from. The read-only cart and product data described under checking your cart, such as /cart.js, which Shopify’s default robots.txt covers with Disallow: /cart. Without it we cannot tell whether an add to cart worked. And on Shopify, when an AI agent handed the add to cart never acts, one request to /cart/add.js, the same request your add to cart button sends.

A retrieval check waits the crawl delay you set between the pages it fetches, up to 5 seconds. A longer delay is waited as 5 seconds, so a scan still finishes.

Synthetic checkout identity

Our journeys reach your checkout and stop there. On the way, the scripted walk types only what a checkout asks for before it shows the payment step: the email address below, and, where a checkout asks for contact and delivery details first, the test identity described after it. When an AI agent takes over a step, the one thing it can type is an email address, and only into an email field. Nothing we run types a password, a card, a date of birth or a government id, nothing presses a pay or place order button, and no order is placed.

The email address is always of the form below, so you can set up a filter now and recognise it at a glance:

scan-<run-id>@agent.ottom.io

That mailbox accepts no mail. One filter rule on @agent.ottom.io would catch all of it. Where a checkout on a store that is not Shopify asks for contact and delivery details before the payment step, the scripted walk fills them with an identity that is just as obvious: the name Ottom Scan, the street line Ottom Agent Test, and for a UK store London EC1A 1BB with the phone number 07700 900123, from the range Ofcom keeps for drama. For a US store it is New York, NY 10001 and 202-555-0123, a number kept for fiction. For a store in Germany, France, Ireland, the Netherlands, Spain, Italy, Australia, Canada and New Zealand it uses a central, public postcode and its city in that country, such as 10115 Berlin for Germany, and a phone number from the range that country keeps for fiction, or +44 7700 900123 where it keeps none. It keeps the delivery country your checkout already shows when it is one of these. When it is not, it chooses the United Kingdom, or else the United States, if your checkout offers either, as a shopper from the UK would; otherwise it types only the email address. It takes the free or cheapest delivery option, and presses continue. It never presses pay.

One exception, at the basket only. Where a UK store will not open checkout until a delivery postcode is given, the scripted walk types EC1A 1BB, a central London postcode that belongs to no shopper, or the central postcode above for a store in one of the other countries, and takes the first delivery date the store offers. It never types a date of birth: an age check that asks for one is where the walk stops.

Scan modes, and when an AI agent is involved

A store is walked in one of three scan modes. In Script, a script walks every step and no AI agent is involved. In Hybrid, the script walks every step and an AI agent takes over only a step the script stops at, as the next section describes. In Full AI, an AI agent takes every step itself. Hybrid is the default. A store’s verified owner can choose Script or Hybrid for it, and Full AI is available on request. Full AI is not running yet: until it passes our test suite, a store set to it is walked in Hybrid.

Every rule on this page holds in every scan mode. Whichever mode walks your store, our agent never pays, never signs in or creates an account, never accepts cookies, types nothing but the synthetic checkout identity above, and stays on your store and its checkout. How each mode is scored is on the scoring page.

When an AI agent takes over a step

In Hybrid, a journey walks your store with a script first. When the script stops at a step, an AI agent takes over that one step and tries to get past it. It uses the same browser session as the walk, so it carries the same user agent and From header and leaves from the same addresses as everything else on this page.

Before a stall is reported, an AI agent walks your store again on its own, from the product page, within the same journey. It follows every rule on this page. A journey that stops short of the payment step can therefore show as two walks in your logs, a few minutes apart.

It does not browse freely. Our code lists the controls on the page, and the AI agent picks one of them and one of a fixed set of actions: click, choose an option, scroll, or type the checkout email address above. It is also shown a screenshot of the screen, so it sees what a shopper sees, but it can only act on a control in that list. It never supplies an address to visit or text of its own to type. Controls that would pay, place an order, sign in or create an account are taken out of that list before it is given it, and refused if it names one anyway. If a click takes it off your store and its checkout, the takeover ends and it goes back.

Checking your cart after an add

On Shopify and WooCommerce stores, a journey also asks your store what its clicks did. After pressing add to cart it reads your cart: /cart.js on Shopify, the Store API’s cart on WooCommerce. On Shopify it also reads the product’s own data at /products/<handle>.js to know which versions can be bought. These are the public endpoints your theme already calls, read in the same browser session as the walk, so they carry the same user agent and From header and leave from the same addresses. They only read: nothing is added, changed or removed by them, and one walk through your store makes at most 12 of them.

What we never do

• We never submit payment. Journeys stop at the payment step. No card details are entered and no order is placed. An AI agent that takes over a step takes no further action once a payment form is on the page, and a request that looks like it submits a payment is blocked while it acts.
• We never sign in or create an account. A checkout that insists on an account is reported as a finding, not signed up to.
• We never pretend to be someone else. No spoofed user agents, no real-looking third-party email addresses, no residential proxies.
• We never accept cookies on anyone’s behalf. When your store shows a cookie banner, our agent rejects it, or closes it if there is nothing to reject. An AI agent that takes over a step is never offered the banner’s accept control.
• We never ignore a Disallow: /. A store whose robots.txt disallows our token at its root gets a robots.txt read from us and nothing more. What we check below the root is set out above.

Rate limits

Any one store receives at most 3 full agent journeys per day, counted across everyone who asks, not per requester. Retrieval checks are lighter still, a handful of page fetches each, and capped at 12 per store per day on the same basis. Both caps bind whoever asks, so a free scan can be refused because the store has already had its allowance today. A journey counts once however many walks it takes: one that stalls is walked a second time to confirm the stall, and one we could not finish for a reason of our own is walked again about ten minutes later.

A merchant can raise their own store’s ceiling by contracting with us for more frequent checks. That raises it for everyone who asks about that store, not only for them, because the limit is a property of the storefront rather than of who is asking. The most any store can receive in a day is 8 full journeys and 72 retrieval checks. Every limit, and what happens when a store reaches one, is on the limits page. Why the limit is counted per store is in the help centre.

Allowlisting

If your bot protection challenges us, your scan will report a blocked storefront rather than a real verdict. Allowlist the user agent above, or the egress address listed above, and re-run the scan. Allowlisting our agent walks through it.

Opting out

Mail [email protected] from an address at the store’s own domain. That domain then stops being scanned, along with every subdomain of it. That covers every scan anybody requests, the ones we run ourselves, and our free tools. It applies to the next scan anybody requests, and scans already waiting in a queue are stopped before they start.

Three cases it cannot decide on its own. Mail from a shared mailbox such as Gmail or Outlook proves control of a mailbox and not of a shop. A storefront on a platform domain, for example yourshop.myshopify.com, cannot be opted out this way either, because that domain is the platform’s rather than yours. And mail that does not pass your domain’s DMARC check, including mail from a domain that publishes no DMARC record, cannot show it came from your domain, because anybody can type a From address. All three arrive as an ordinary support request and a person answers them, inside one business day.

Changed your mind? Mail the same address from the same domain and say so. A person lifts it inside one business day and replies to confirm. You can also block us in robots.txt.

Canonical version of this page: https://ottom.io/agent