BOT protection challenge - Move from traditional REST API to a Supergraph

The context: Currently using Akamai Bot Manager in front of REST APIs, where bot protection benefits from having one distinct path per endpoint — Akamai can learn a separate traffic baseline for each. Moving to a Supergraph collapses that into a single URL (POST /graphql), and that’s where the challenge starts.

The specific problem: With every operation, from every region, funneling through one endpoint, Akamai only sees the aggregate traffic against that single path — not individual operations. Legitimate multi-region traffic that’s individually well within normal bounds gets summed together, and when that combined pattern doesn’t match what Akamai learned as “normal” for the endpoint as a whole, it flags as anomalous. High false-positive rate, even though nothing is actually behaving badly.

What we’ve found so far (Akamai-side): Bot Manager can be configured to key on the operationName field in the GraphQL POST body, giving per-operation protection instead of one blanket rule — but it requires Bot Manager Premier or Account Protector (not standard Bot Manager), depends on clients consistently sending operationName, and Akamai documents a 200-operations-per-API-resource limit — since a Supergraph is one path, it’s one resource, so that’s a hard ceiling across the whole graph, not per team. Docs:

The ask: Has anyone here run a Supergraph behind Akamai (or another WAF/Bot Manager) at scale, and if so — how have you handled bot detection and false positives when multi-region traffic sits behind that single endpoint? Any patterns (regional segmentation , Persisted Query Safelisting , Graph Contracts to split traffic across endpoints, or something else) that have actually worked at scale would be hugely useful to hear about.