A bot-manager cookie that rewrites itself on every response should never enter a shared cache key or be stored as a reusable Set-Cookie at the edge. Prefer stripping _abck and its siblings from the cache key, forwarding Set-Cookie without making the document object vary on it, and treating the sensor sequence as the freshness signal rather than the cookie name alone. If a cache or proxy holds a previous _abck value and replays it to another client, challenge pass-rate and session continuity both drift even when origin bodies are identical.

Ops prove-out after a cache-rule or header change: hit the same path from two clean clients and confirm each receives a distinct _abck while the document itself can still HIT, then replay a stale cookie on a third request and confirm the edge or bot manager rewrites or challenges it instead of accepting the copy. Watch Set-Cookie presence, cache HIT ratio, and challenge rate for one rule window — a falling HIT ratio with stable traffic usually means the cookie is still in the key, and a spike in challenges with a high HIT ratio often means a shared cookie leaked across clients. Keep sensor paths uncacheable so a purge of document shells cannot flatten the bot-manager cookie namespace.