Network observability
Trace every Casco request.
Casco tags every request with x-casco-request-id and sends testing traffic from known, stable source IPs. Identify it in your logs, verify its origin, and trace every finding to the requests that proved it.
FINDINGREQUESTSERVICE
Identify. Verify. Trace.
Know which traffic is Casco.
The request header connects traffic to finding evidence. The source IP verifies where it came from. Together, they let responders separate planned testing from production traffic without trusting a spoofable header alone.
Finding to service log
One request. One trail.
The evidence stays with the finding.
The finding keeps every network request Casco used to validate the exploit, including when it was captured.
Times recordedTimes recorded
RECORDED IN CASCOTimes recorded
PLAYING IN FULLNetwork-enforced scope
Define what Casco can test.
Targets are either in scope or blocked at the network layer before a request can reach them.
Allowed by policy.
Casco can test the system within the operation’s configured controls.
REQUEST ALLOWEDKnown source. Traceable request.
Find the header. Check the source.
Filter for x-casco-request-id, then check the source against Casco’s published IP addresses. The header links the request to finding evidence. The source IP verifies its origin.
e629339b-152c-4420-91cf-63e829e4b555REQUEST HEADERSOURCE IP: MATCHPUBLISHED IP SETHEADER + SOURCE ALIGNEDINTERNAL TESTINGClassify the planned activity without masking other traffic.
Network observability FAQ
Questions about Casco traffic.
Clear answers about source IPs, request headers, exploit tracing, traffic classification, and network scope controls.
01What is x-casco-request-id?
x-casco-request-id is a unique correlation value Casco adds to every network request its agents send during testing. Each finding records the values and capture timestamps used to prove the exploit so you can trace the requests through your own systems.
02How can I identify Casco traffic in our internal logs?
Filter for x-casco-request-id or Casco’s published source IPs. Use the header to connect a request with finding evidence and the source IP to verify where the traffic came from.
03How do I tell Casco testing traffic from a real attack?
Casco testing traffic comes from a known set of source IPs and carries x-casco-request-id. Traffic that resembles a test but originates from another address should be investigated as a separate anomaly.
04How do I verify a request actually came from Casco?
Check the source IP against Casco’s published IP addresses. The header connects the request to a finding, but the header alone is not proof of origin because request headers can be copied or spoofed.
05Can I trace how an exploit worked through our systems?
Yes. Open the finding and go to Network requests to see every x-casco-request-id and capture timestamp used to prove the exploit. Copy one ID or all of them, then search your gateway, application, or SIEM logs.
06How does Casco enforce out-of-scope boundaries?
Targets marked out of scope are blocked by network policy before a request can reach them. The control is enforced at the proxy, outside the agent reasoning loop.
07How does Casco separate testing traffic from production traffic?
Use Casco’s published source IPs and x-casco-request-id together to classify planned security testing as internal test traffic while leaving production user traffic in its normal monitoring path.
08Should Casco traffic trigger our security alerts?
Initially, yes. Testing that triggers detection shows the control is working. After identifying the source IP and request header, classify the planned activity as internal testing so responders do not repeatedly triage the same pentest traffic.
Network observability in Casco
Identify the traffic. Trace the request. Resolve the finding.
See how source IPs and request IDs make Casco traffic attributable, link findings to your own logs, and keep testing inside scope.
Book a technical demo