Synthetic traffic identification and allowlisting

ScoutSentinel probes are synthetic traffic and they say so. This page explains the markers and how to use them. The public policy lives at /synthetic, which is also where our user agent links.

Markers on every request

The X-ScoutSentinel-Probe value is the id of the probe run that made the request. It is the same id you see on the Observation (probeRunId) and in the runs list, so a request in your logs can be matched to the exact run, its evidence and its runner identity. The value is issued per run by the platform and delivered to the runner with the job; it is not derived from anything you can predict, and it is not a signed token you can verify offline at your edge. Treat it as a correlation id, not as authentication.

The user agent string and header name are constants in the platform (SYNTHETIC_USER_AGENT, PROBE_HEADER_NAME) and change only with a version bump announced here. The default marker parameter name is scoutsentinel (PROBE_MARKER_PARAM).

Allowlisting through bot protection

Bot protection that challenges or blocks a probe turns a working journey into unknown with reason blocked_by_bot_protection. The probe recognises the common interstitials (Cloudflare, Akamai, PerimeterX, DataDome, Imperva) and records the block as a coverage problem, never as a failure of your journey. To avoid it:

1. Prefer the customer marker. It is a value only you and ScoutSentinel know, sent as a query parameter or header of your choosing on requests to your hosts. Allow requests that carry it, and rotate it when you need to.
2. For regional runners, allow the published egress ranges for the regions you selected as a second factor. Edge probes run from Cloudflare’s network and do not have stable addresses.
3. Do not allowlist by user agent alone; anyone can send that string. Do not allowlist by the X-ScoutSentinel-Probe header alone either; it identifies a run, it does not prove the sender.

Cloudflare WAF example (custom rule, skip managed challenge and bot fight mode) for a marker sent as a query parameter:

(http.request.uri.query contains "scoutsentinel=<your-value>")

Or for a marker sent as a header named X-Assurance-Marker:

(http.request.headers["x-assurance-marker"][0] eq "<your-value>")

Rotate the value by changing it on the Watch and in your rule in the same change window; probes pick up the new value on their next scheduled run.

Keeping probes out of analytics, fraud and revenue

• Filter analytics on the user agent or the marker; most tools support a bot exclusion rule.
• Use a dedicated test account and your payment provider’s test card path. ScoutSentinel never uses live payment credentials; secrets you store are used only where your plan references them.
• Tag orders and leads created by a probe using the marker so downstream fulfilment, CRM and fraud scoring can ignore them.
• Volume: each Watch runs at its configured interval per location. A Watch every five minutes from three locations produces 36 runs per hour, each a short fixed sequence of requests.

What probes do not do

• No port scanning and no crawling beyond the steps in the approved plan.
• No credential stuffing or brute force; secrets are yours and are used only where your plan says.
• No storage of personal data beyond what appears in evidence you configured, which is redacted for known secret values and retained under your policy.

Opting out

If you operate a site that ScoutSentinel is probing and you did not ask for it, email security@scoutsentinel.com with the hostname and, if you have them, sample X-ScoutSentinel-Probe values from your logs. We identify the customer from those run ids, verify domain control, and pause the Watch while we do so; see the synthetic traffic policy.