You send the site owner a screenshot. The page says Access Denied, with a reference string near the bottom. Your message says the automation was blocked. Their engineer opens Akamai Control Center and has no exact time window, request role, method, or safe route label to search.
That screenshot is useful context, but it is not an incident record. Before changing the browser, proxy route, session, rate, or headers, preserve one occurrence well enough that the owner can find the same request in systems you cannot see.
One clean incident beats ten retries whose settings changed along the way.
The short answer
Record the raw 403 and its UTC time first. RFC 9110 defines 403 (opens in a new tab) as a response from a server that understood the request and refuses to fulfill it. The specification also says a client should not automatically repeat the same request with the same credentials. A retry can be a later, agreed test. It should not erase the evidence from the first incident.
Send the owner a narrow, redacted packet while the event is still recent. Ask which layer produced the response and what rule or policy was active at that time. Until they answer, keep the cause unclassified.
What the 403 proves
A recorded 403 proves that your client received an HTTP response for that request. It does not identify the component that wrote the response. An edge property rule, a security control, or origin application logic can each refuse a request. The same hostname can use several of those layers.
Akamai documents ordinary access control in