A vendor diagram is not a request path. That sounds obvious until a pilot starts and three people in the room are each picturing a different architecture: one sees a CDN plugin, one sees an inline proxy, one sees an API sidecar. All three can find a Cequence slide that supports their picture.
This article is for the platform engineers, security leads and CTOs at publishers and ecommerce companies who are evaluating or already piloting cequence bot protection. It is not a ranking. It separates what Cequence's current public documentation shows from what appears in a June 2026 announcement, a 2020 Fastly PDF and features that depend on your contract. Then it gives you a repeatable test plan.
One caveat on method. We do not operate Cequence, and we have not tested it. Everything below about Cequence is attributed to a public source type, and anything we could not tie to current documentation is labeled as a question for your vendor call. Your pilot environment is the authority, not this post.
Short answer: what the public evidence supports
The strongest public evidence describes Cequence Defender running inline, in the request path, alongside Istio and Envoy. That is a concrete architecture you can test. Traffic crosses a proxy tier, a decision is made there, and the result is enforced or logged at that tier.
The weaker evidence is everything else. Older integration documents show an earlier integration picture. A June 22–23, 2026 announcement announces Intent Graph and Biometric Check. Some capabilities are described as depending on your contract or package. None of those three should be treated as proof of what your deployment will do on day one.
Our position: current documentation is the baseline, and everything else is a claim with a source. Write the claim down with its source before the pilot starts. If a feature matters to your decision, it has to survive a test in your environment. A slide doesn't count.
Three questions settle most of the ambiguity:
- Where does the decision happen: at your CDN, in your cluster, or in a Cequence-operated tier?
- What happens to a request when that component is slow or unreachable?
- Can you reconstruct, from logs you own, why a specific request was allowed, challenged or blocked?
The rest of this post is a way to get written answers to those three.
What current documentation shows: Defender inline with Istio and Envoy
Cequence's public documentation describes Defender as an inline component integrated with Istio and Envoy. In practice the enforcement point is a proxy tier you may already run, or one you will need to run.
Check that against your own stack first. If your origin sits behind a managed CDN and a handful of VMs, ask what the inline deployment looks like for you. "Inline with Istio and Envoy" describes a service mesh. It says nothing about your CDN.
What an inline model gives you, in principle:
- The decision point sits on the request path, so enforcement can happen before the application sees the request.
- Latency and availability of the decision component become part of your own SLO.
- Header and body inspection depends on where TLS terminates relative to the proxy.
What it costs you:
- A new dependency in the hot path of every protected route.
- Operational ownership of version upgrades, configuration rollout and capacity.
- A need to know which client IP the component actually sees. If a CDN sits in front, the direct peer is the CDN, and the real client address arrives in forwarded headers that must be trusted only from known proxies.
Write down, in your pilot plan, the exact hop where Defender sits. Name the load balancer, the ingress, the Envoy listener and the upstream cluster. If the vendor can't name those hops for your environment, you don't have a deployment design yet.
Old diagrams versus current availability: the 2020 Fastly PDF and contract-dependent features
A 2020 PDF describing a Fastly integration is a historical artifact. It may describe a pattern that worked then, a design intent, or a pattern that has since changed. A six-year-old diagram can't tell you which, and neither can we.
The rule is simple. A diagram older than your last two infrastructure changes is a question, not an answer. If you run Fastly, ask Cequence in writing whether the integration shown in that PDF is available today, who supports it, which Fastly products it assumes (VCL, Compute, or neither), and whether it needs a separate commercial package.
The same logic applies to contract-dependent features. A capability can be real and still not be in your order form. Before the pilot, build a list with three columns: feature, source (current docs, announcement, sales call, PDF), and contract status (included, add-on, roadmap, unknown). Any row with "unknown" in the last column is a risk you carry into the evaluation.
This isn't a Cequence-specific problem. Every bot management vendor has features that live in marketing before they live in your tenant. We made the same point in our guide to Cloudflare bot protection pricing and the enterprise quote checklist, and we covered the CDN-side version for Fastly bot protection with pre-cache and post-cache checks. Where a check runs relative to the cache changes what it can see and what it costs you per request.
Ask for a dated statement of support. "Works with Fastly" is a slogan. "Version X, product Y, supported as of date Z" is something you can hold the vendor to.
Marketing claims to attribute, not adopt: Intent Graph and Biometric Check
The June 2026 announcement introduces names such as Intent Graph and Biometric Check. We won't describe how those work. We have no public documentation that explains their mechanics, and inventing an explanation would be worse than saying nothing.
What you should do is attribute them correctly. In your evaluation notes, write "Cequence announcement, June 2026, describes a capability called Intent Graph." Don't write "Cequence detects intent." The first sentence is a fact about a document. The second is a performance claim you haven't verified.
For each named feature, get answers to five questions before it influences your decision:
- Is it generally available today, or announced?
- Which deployment modes support it (inline Defender, API-based, CDN-integrated)?
- What data does it need from the browser or client, and does that require a script on your pages?
- What does it emit into your logs, and in what fields?
- How is it priced and is it in your contract?
A name like "Biometric Check" also carries a privacy question. If it implies collecting behavioral or device signals from visitors, your legal and privacy teams need to know what is collected, where it is stored and under which lawful basis. Ask before the pilot touches production traffic, not after.
A good rule for any vendor, ours included: a feature name is a label, not evidence. Evidence is a test result you can reproduce.
Deployment checks: request path, enforcement location, timeouts and fail behavior
Four checks decide whether an inline bot layer is safe to put in front of revenue pages. Run them in staging first, then on a low-risk production route.
1. Request path. Draw the path with real hostnames. Client, CDN, load balancer, ingress, Envoy, Defender, application. Confirm each hop by sending a request with a unique header and finding it in the logs of every tier. If a hop doesn't show the marker, it isn't where you think it is.
2. Enforcement location. A decision can be made in one place and enforced in another. Find out which. If the decision happens in your cluster but your CDN has already cached the page, a blocked client may still be served from cache. Test with a cacheable URL and an uncacheable one.
3. Timeouts. Ask for the default timeout the proxy applies when waiting on the decision component. Then measure it. Add artificial latency to the decision path in staging and record the p50, p95 and p99 effect on page response time. A decision budget of tens of milliseconds can turn into seconds when something degrades.
4. Fail behavior. This is the most important line in the whole evaluation. When the decision component is unreachable, does the request fail open (served without a decision) or fail closed (rejected)? For a news site during a breaking story, fail closed can be an outage. For a checkout during a sneaker drop, fail open can be an attack window. Pick the behavior per route, and verify it by actually stopping the component in staging.
Our post on Nginx bot protection and safe rollout covers the real-IP and trusted-proxy side of this in more detail. The same trusted-proxy discipline applies to Envoy.
Logging and policy checks: what you must be able to reconstruct
If you can't reconstruct a decision, you can't defend it to a customer, a partner or an auditor. Set the bar before you sign: for any single request, your team must be able to answer six questions from logs you can export.
- What did the client claim to be (user agent, declared identity)?
- What source address did the enforcement point see, and was that the real client or a proxy?
- Which policy matched, by name and version?
- What action was taken: allow, challenge, block, or monitor-only?
- What evidence or score drove the match, in a field you can read?
- What did the visitor experience afterwards, such as a challenge pass, a completed checkout or a retry?
Most pilots skip the sixth question. Blocking counts are not success. Completed legitimate sessions are. Our guide to bot false positive testing lays out how to track both sides.
On policy, require these capabilities in writing:
- A monitor-only mode per policy, so you can observe before enforcing.
- Per-route and per-hostname scoping, so a rule for login doesn't touch article pages.
- Allow-listing for crawlers you have approved, verified by more than the user agent string.
- Versioned policy changes with an audit trail and rollback.
- Log export to your own SIEM or object store, with retention you control.
Ask to see a real log line, not a dashboard screenshot. A dashboard summarizes. A log line proves.
Repeatable authorized tests with ordinary users and automation
Run these only against systems you own or have written permission to test, and tell your security and operations teams before you start. The goal is a test matrix you can rerun after every policy change.
Ordinary-user baseline. Recruit a small group on different networks and devices: corporate laptop, home broadband, mobile data, a privacy-focused browser, a VPN user and someone using a screen reader. Have them complete the journeys that earn money: read an article past a meter, log in, add to cart, check out. Record any challenge, delay or block. This group is your false-positive canary.
Simple automation. Use your own scripted HTTP client with a default library user agent against a protected route. Then set the same client's user agent to a common browser string. Record whether the action differs, and what the logs show for each.
Browser automation. Run a standard headless browser setup that you control against a staging route. Capture the outcome. Then repeat with the settings your own QA team uses for regression tests, because those must keep working. Approved automation needs an explicit allow path.
Declared crawler claims. Send a request from an address you control that claims a well-known crawler name. A claim is not proof, and your policy should treat it that way. For background on why, see our notes on what ClaudeBot is and how its traffic is identified.
Failure drills. Stop the decision component in staging and watch what the proxy does. Restore it and confirm it recovers without a manual step.
Save inputs, timestamps and outputs for every run. A test you can't repeat in a month is an anecdote.
Where an add-on layer beside your CDN fits (Centinel allow, challenge, block) and questions for your vendor call
Some teams don't want a new inline tier in their cluster. They want to keep the CDN or WAF they already run and add a layer that decides who gets through. That is where Centinel Analytica sits. It tells real visitors from scrapers and applies allow, challenge or block policy through your existing CDN or edge.
The evaluation logic in this post applies to us as much as to anyone. Ask us for the request path, the enforcement point and the log fields, and test them the same way. Our published research shows the kind of evidence to ask any vendor for. On a typical news site, 84% of requests claiming to be GPTBot were fake, so a crawler name in a user agent is not an identity.
Questions for your Cequence call, in order:
- Which exact deployment mode applies to our stack, and which public document describes it?
- Is the integration shown in the 2020 Fastly PDF supported today? Since when, and by whom?
- Which announced features, including Intent Graph and Biometric Check, are generally available in our contract?
- What is the default timeout, and is fail-open or fail-closed configurable per route?
- Which log fields show the matched policy and the evidence behind it, and can we export them?
- What does a rollback look like, and how long does it take?
Get the answers by email. Verbal answers don't survive a staff change.
Conclusion
Don't sign off on cequence bot protection, or any bot layer, until you hold a one-page document with the request path, the enforcement point, the fail behavior per route and a sample log line, each tied to a dated source. If the vendor can't fill that page, the pilot isn't ready, whatever the announcement said.
If you'd rather add a decision layer beside the CDN you already run than a new inline tier, run the same checklist against Centinel Analytica. Bring both reports to your next vendor call.
Frequently asked questions
Does Cequence Defender run inline or at the CDN?
Cequence's current public documentation describes Defender running inline with Istio and Envoy, which is a proxy tier rather than a CDN feature. Older material, such as a 2020 Fastly PDF, may show other patterns. Ask Cequence in writing which mode applies to your stack and confirm the request path with test requests.
What should I test before putting an inline bot protection layer in production?
Test four things: the exact request path, where enforcement happens relative to your cache, the decision timeout, and fail-open versus fail-closed behavior when the component is down. Add an ordinary-user baseline on varied networks and devices, and confirm every decision can be reconstructed from exported logs.
How do I treat vendor claims like Intent Graph or Biometric Check?
Attribute them to their source, for example a June 2026 announcement, and do not repeat them as verified performance. Ask whether each is generally available, which deployment modes support it, what data it collects, what it logs and whether it is in your contract. Reproducible test results are the evidence.
Can I add bot protection without replacing my CDN or WAF?
Yes, that is a common design. Centinel Analytica works alongside Cloudflare, CloudFront, Akamai and Fastly and applies allow, challenge or block policy through your existing CDN or edge, so your CDN or WAF stays in place. Verify the request path and logging in a pilot, as with any vendor.
Why isn't a crawler user agent enough to trust a request?
A user agent is a claim the client makes about itself. Centinel Analytica's published research found that on a typical news site, 84% of requests claiming to be GPTBot were fake. Verify crawler identity with more than the header, and keep an unknown state for requests you cannot confirm.