What is the x-casco-request-id header?

It's a unique identifier Casco attaches to every network request its agents send during testing. You can filter your network logs by this header to separate Casco's testing traffic from production user traffic, and each finding lists the request IDs used to prove the exploit so you can trace them through your own systems.

How do I identify Casco traffic in my network logs?

Filter for the x-casco-request-id header. All requests from Casco's agents carry it, which separates security testing traffic from production user traffic.

How do I tell security testing traffic apart from a real attack?

Casco's traffic comes from a known, stable set of IP addresses and carries the x-casco-request-id header. Traffic that resembles an attack but originates from a different IP is worth investigating as a real anomaly. This keeps planned pentest activity from drowning out genuine incidents in your monitoring.

How do I verify a request actually came from Casco?

Check the source IP against Casco's published IP addresses. Because Casco tests from a fixed set of IPs, the source is authoritative: a copied x-casco-request-id header on traffic from another address can't impersonate a real Casco request.

Can I trace how an exploit worked through my own systems?

Yes. Open the finding, go to the Network requests tab, and you'll see every x-casco-request-id used to prove the exploit. Search those IDs in your application, gateway, or SIEM logs to follow the exact requests through your infrastructure.

How does Casco prevent its agents from testing out-of-scope systems?

Every asset is marked in-scope or out-of-scope. Out-of-scope assets are blocked at the network level, at the proxy, below the agent's reasoning, so the agent cannot decide its way past them no matter what objective it's pursuing. In-scope assets are the testing targets.

How is this different from the OpenAI Hugging Face incident?

That incident involved AI models with no deterministic network-level safeguards reasoning their way out of a sandbox to the open internet. Casco's out-of-scope blocks are enforced at the network layer, outside the agent, so they can't be reasoned around. Network observability then lets you independently trace Casco's traffic in your own logs to confirm it stayed within the scope you set.

Should Casco traffic trigger my security alerts?

Initially, yes; testing that resembles an attack tripping your detection means your detection works. Once you've identified Casco's traffic by its source IPs and the x-casco-request-id header, classify it as internal testing so your team isn't repeatedly triaging planned activity as an incident.

Introducing Casco’s Improved Network Observability

Written by Rene Brandel on Fri Jul 31 2026

Casco's improved network observability lets you see exactly what our agents did to your application. Every request is identifiable by source IP and an x-casco-request-id header, and every finding links back to the specific requests that proved it, so testing traffic is never a mystery in your logs and remediation starts from what actually happened.

Launch Week 1, Day 5: identify pentest traffic with Casco network observability and trace every request through your infrastructure.

The question everyone is asking AI security vendors right now

Earlier this month, OpenAI disclosed that a combination of its models escaped a sandboxed testing environment during an internal cyber-capabilities evaluation, gained internet access through a zero-day, and compromised Hugging Face's infrastructure. Hugging Face, which published a full technical timeline, called the incident unique because it was "driven, end to end, by an autonomous AI agent system."

We were asked: how does Casco prevent something like this from happening?

It's the right question. Our scope controls have always enforced the boundary. What's new today is that you can see and verify it yourself, in your own logs, instead of taking our word for it.

Scope is enforced below the agent, not requested of it

The failure mode in agentic systems is treating instructions as guardrails. Telling an agent "only test these targets" is a request, and a sufficiently capable agent under a sufficiently aggressive objective will route around requests. Guardrails that live only in the prompt are guardrails the agent can reason its way past.

Casco's strongest boundary doesn't depend on the agent's judgment at all. In the console, every asset is either in-scope or out-of-scope:

In-scope. A target. This is what Casco tests.

Out-of-scope. Blocked at the network level. The agent's traffic to that asset is stopped at the proxy, regardless of what the agent decides. It cannot reason its way past a dropped packet.

The block isn't an instruction the agent agrees to follow; it's enforced below the agent, in infrastructure the agent doesn't control. The difference between an agent that is asked to behave and an agent that is physically unable to misbehave is the difference between a request and a dropped packet.

See exactly what Casco did

Scope controls answer what the agent can touch. Observability answers what it actually did, in your logs, on your terms. Three things come out of it.

Separate Casco from everyone else. Casco tests from a known, stable set of IP addresses and tags every request with an x-casco-request-id header. Filter your logs on either and you can cleanly split testing traffic from production, classify it correctly in your own systems, and stop triaging your own pentest as an incident. The IPs make it authoritative: a copied header from some other address can't impersonate a Casco request.

Trace any finding to the exact requests. Open a finding, switch to the Network requests tab, and you get every x-casco-request-id used to validate that exploit, each with a capture timestamp, copyable one at a time or all at once. Search those IDs in your application, gateway, or SIEM logs to follow the real requests through your infrastructure.

Fix from the inside, not from a description. Because you can trace the exact requests, remediation starts from what actually happened in your systems rather than from our write-up of it. You see the vulnerability the way the exploit did.

The bigger picture

Our mission at Casco is to make all software effortlessly secure, and autonomous agents are how we get there. Running capable agents against your systems only works if the boundaries are real and you can see them holding. Every launch this week has been a version of the same commitment: the tuning is visible, the findings travel to you, and now the traffic itself is traceable. If an AI agent is testing your application, you should be able to watch exactly what it does.

Get year-round security with autonomous security testing. Get started at https://casco.com

Quick answers

Frequently asked questions

What to know before connecting Casco to your coding agent.